ISE 1.2 Authentication Failures at First time Connection
I have a trouble with ISE 1.2 when trying to authenticate for first time an end-device, this device might be either a Workstation or IP Phone or Printer,etc. it fails or staying in running mode. The result is the same it can not access the network. hopefully I'm still in open mode :)
As i described in the beginning everything has status Running or Authz Failed. and after a time of period usually one day finally succeeds.
This happens mostly for workstations and printers, but in case of phones does not have the same behavior. I unplug plug the phones or I shut/ no shut the ports in order to trigger it to succeed. For some phones worked but other obstinately declined.
The phones which are not Cisco phones authenticated with MD5 (a simple username and pass ) i think the problem should not related with the auth protocol.
Below are some logs from one phone. For me coming to a short conclusion this must be related with the switches which are 3750e (15.02 SE 4 IOS)
or with the same the ISE, why because i have almost the same behavior for all end-devices.
You'd need to take a look at your authentication profile and maybe provide a bit more with regards to what you're trying to accomplish.
Both 802.1x and MAB authentication is failing for these clients according to the logs you've provided. I would be interested to know what protocols you're using with your 802.1x deployment. I'd also be curious to how you're referencing clients with MAB.
There a number of things it could be, but I would check to make sure that my root certificates are trusted both on the client and server.
As for the MAB failover what you could do is just make sure the endpoint is in whatever database you're referencing. Then you'd have to make sure you have an Authorization profile that includes this device.
Either way in my opinion there's too many variables out there still. You should, if possible, post your port config, authentication and authorization profiles.
First thing is it looks like you're running your ports in "open" mode which means that even if everything fails it's going to still pass traffic based on whatever ACL you've applied to the port. My assumption is if you pulled that command from your port configuration everything would fail.
That is my understanding of the process anyways.
From what you've posted authentication appears to be failing across the board.
I would verify your workstation supplicant settings: make sure the PSN has a cert that is trusted by the workstation, services is started, verify the authentication parameters under your network adapter.
You should also verify you active directory settings.
Workstations with the windows default authentication protocol EAP/MSCHAPv2
When I saw this I assumed:
Simplified supplicant configuration. For example, Microsoft Windows supplicant with PEAP-MSCHAPv2 and server certificate trust enabled requires that you specify each of the server certificate to trust, or the user may be prompted to trust each PSN certificate when the client connects using a different PSN. With wildcard certificates, a single server certificate can be trusted rather than individual certificates from each PSN.
You could always have an authorization policy that attempts to use 802.1x as the primary method and then failover to an internal database.
What I did early in deployment was setup a switch on my desk and then grab as many device types as I could. One by one I created my authorization policies for the devices and then tested them in closed mode. When I was able to successfully authenticate each type then I gradually deployed out to larger groups.
Windows supplicants have the option to validate server certificate, if you disable this then your workstations will authenticate off of anything that offers. I wouldn't recommend it as a production deployment type, but it could make troubleshooting pretty simple.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...