04-16-2014 09:25 AM - edited 03-10-2019 09:38 PM
Hi,
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.
I kindly remain your comments...
-------------------------------------------------------------------------------------------------------------------------------
2169669: Apr 16 18:02:20.573 EEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/35, changed state to up
2169670: Apr 16 18:02:20.783 EEST: %DOT1X-5-FAIL: Authentication failed for client (0080.9f7d.3ddf) on Interface Gi1/0/34 AuditSessionID 0A114D0D0000D5E8855C01DE
2169671: Apr 16 18:02:20.791 EEST: %AUTHMGR-7-RESULT: Authentication result 'timeout' from 'dot1x' for client (0080.9f7d.3ddf) on Interface Gi1/0/34 AuditSessionID 0A114D0D0000D5E8855C01DE
S301#
2169672: Apr 16 18:02:20.992 EEST: %AUTHMGR-5-START: Starting 'dot1x' for client (0080.9f7d.3ddf) on Interface Gi1/0/34 AuditSessionID 0A114D0D0000D5F0855DE0EF
2169673: Apr 16 18:02:21.580 EEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/35, changed state to up
S301#
2169674: Apr 16 18:02:24.289 EEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/35, changed state to down
S301#
2169675: Apr 16 18:02:25.288 EEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/35, changed state to down
2169676: Apr 16 18:02:26.269 EEST: %AUTHMGR-5-START: Starting 'dot1x' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169677: Apr 16 18:02:26.294 EEST: %DOT1X-5-FAIL: Authentication failed for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169678: Apr 16 18:02:26.294 EEST: %AUTHMGR-7-RESULT: Authentication result 'fail' from 'dot1x' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169679: Apr 16 18:02:26.303 EEST: %DOT1X-5-FAIL: Authentication failed for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169680: Apr 16 18:02:26.303 EEST: %AUTHMGR-7-RESULT: Authentication result 'fail' from 'dot1x' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169681: Apr 16 18:02:26.319 EEST: %DOT1X-5-FAIL: Authentication failed for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169682: Apr 16 18:02:26.319 EEST: %AUTHMGR-7-RESULT: Authentication result 'fail' from 'dot1x' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169683: Apr 16 18:02:26.319 EEST: %AUTHMGR-7-FAILOVER: Failing over from 'dot1x' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169684: Apr 16 18:02:26.319 EEST: %AUTHMGR-5-START: Starting 'mab' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169685: Apr 16 18:02:26.328 EEST: %MAB-5-FAIL: Authentication failed for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169686: Apr 16 18:02:26.328 EEST: %AUTHMGR-7-RESULT: Authentication result 'no-response' from 'mab' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169687: Apr 16 18:02:26.328 EEST: %AUTHMGR-7-FAILOVER: Failing over from 'mab' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169688: Apr 16 18:02:26.328 EEST: %AUTHMGR-7-NOMOREMETHODS: Exhausted all authentication methods for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
S301#
2169689: Apr 16 18:02:26.336 EEST: %AUTHMGR-5-FAIL: Authorization failed or unapplied for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
S301#
2169690: Apr 16 18:02:27.737 EEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/35, changed state to up
2169691: Apr 16 18:02:28.744 EEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/35, changed state to up
-------------------------------------------------------------------------------------------------------------------------------------
Regards
T.C
04-18-2014 12:35 PM
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.
04-18-2014 03:11 PM
I'm not using authentication method with certificates for none end-devices
Workstations with the windows default authentication protocol EAP/MSCHAPv2
In front of them there are non Cisco IP-phones with auth. method EAP/MD5
Finally I also have some printers again with option EAP/MD5
For all of these devices I received the same behavior, after many hours finally the authenticated with ISE. But is this the expected behavior?
What I understand is that if the devices finally authenticated then it means that there isn’t anything wrong with the method.
The misunderstanding points are 3
So for my understanding there is an abnormal behavior and i cannot find the way /pattern to correct it or to understand the reason :)
---------------------
Port config
switchport access vlan xxx
switchport mode access
switchport voice vlan yyy
ip access-group ACL-ALLOW in
authentication event fail action next-method
authentication event server dead action reinitialize vlan xxx
authentication event server dead action authorize voice
authentication event server alive action reinitialize
authentication host-mode multi-domain
authentication open
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication violation restrict
mab
dot1x pae authenticator
no cdp enable
spanning-tree portfast
------------------------------------------------------
result template
Switch#sh auth sess int g1/0/46
Interface: GigabitEthernet1/0/46
MAC Address: xxxx.xxxx.xxxx
IP Address: xx.xxx.xx.xxx
User-Name: xxxxxxxxxxxx
Status: Authz Failed
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: multi-domain
Oper control dir: both
Session timeout: N/A
Idle timeout: N/A
Common Session ID: 0A114D0A00001972016208E1
Acct Session ID: 0x00001BB7
Handle: 0x6D0009B6
Runnable methods list:
Method State
dot1x Failed over
mab Failed over
04-22-2014 01:12 PM
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.
Here are some helpful resources:
http://www.cisco.com/en/US/docs/security/ise/1.2/user_guide/ise_ug.pdf
http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/TrustSec_2.0/trustsec_2.0_dig.pdf
04-23-2014 01:41 AM
That's right otherwise if I had removed the open auth. I could be in serious problems in my company J
I reviewed the docs that you send me and I didn't see anything to have omitted in my implementation.
In my implementation I worked with 802.1x native Supplicants without certs
What I realized following your comments and what I checked from the docs is that it’s better to connect the end-devices with the following ways
IP-Phones, Printers = MAB
Laptops, Worksations = Cisco anyconnect
Otherwise if someone don’t follow this set could be in a continuously loops with incompatibility matters between vendors.
I cannot see anything else to my problem my devices at least these that works fine at the moment authenticated - authorized perfectly. that means that my general configuration works fine.
My problem is the instability that appears, the same devices could not authenticated while identical devices successful authenticated.
Maybe i need to move on closed mode for some devices 10-20 (a convenient number) and start observing the behaviors of these lucky - unlucky users.
04-23-2014 08:35 AM
I may have misread but from what I saw was:
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: