08-29-2012 05:59 AM - edited 03-12-2019 05:40 PM
Hi,
We have a customer which is using ISE with 802.1X in order to authenticate computers. All the computers have their own certificate and most of them can be authenticated fine! The issue is that some computers cannot be authenticated.
The port configuration the authenticator (Cisco WS-C4510R+E IOS 151-1) are configured exactly the same:
interface GigabitEthernet2/19
switchport access vlan 999
switchport mode access
authentication event no-response action authorize vlan 111
authentication host-mode multi-domain
authentication port-control auto
mab
dot1x pae authenticator
dot1x timeout tx-period 5
!
But for some reason some PC cannot be authenticated. A wireshark capture on the computer not working shows that the computer receives a EAP Request Identity and also send a Response Identity to the switch but then nothing happens more:
So the process is stucked in the EAP-Response/identity. I attach a debug capture on the switch for one of the computer which cannot be authenticated.
It is really wired as most of the computer can be authenticated without any issues.
Thanks in advance for your help.
/Laurent
08-29-2012 08:12 PM
Hi,
It looks as if the client is sending the eap-response just as you said, and it looks like authmgr never processes it and then times out.
Can you get the debug radius authentication from this switch also and a capture off the wire?
I tried to check the bug toolkit but for some reason doesnt display anything.
See if you can do a bug scrub on dot1x on the bug toolkit.
Tarik Admani
*Please rate helpful posts*
08-30-2012 02:07 AM
I have attached Wireshark captures and debug output from 2 session: one that works, and one that does not work.
In the Wireshark capture, we can see that the PC is indeed sending the EAP response.
In the debug output, I notice that the a message like the following does NOT appear on the client that does not work:
Aug 30 08:49:51.256: dot1x-ev(Gi3/34): New client notification from AuthMgr for 0x51000DED - xxxx.xxxx.xxxx
(You can see this in the file "WORKS - debug eap event.txt")
That message SHOULD appear right after the following message:
Aug 30 08:40:48.419: dot1x-ev(Gi3/34): New client detected, issuing Start Request to AuthMgr
(In the file "DOES NOT WORK - debugs")
This indicates that the AuthMgr on the Cisco switch has an issue - but how can we troubleshoot this further to determine the cause?
It is absolutely consistens which clients fail and which suceeds, but I don't see anything special about the EAP Respons on the wire.
08-30-2012 02:33 AM
I continued the debugging with the following debugs:
debug dotx1 all
debug authentication events
And now I see the following interesting difference between the 2 clients:
This one works:
Aug 30 09:12:06.245: dot1x-ev(Gi3/34): New client detected, issuing Start Request to AuthMgr
Aug 30 09:12:06.245: AUTH-EVENT (Gi3/34) Received 'START_REQUEST', current method is dot1x (handle 0x00000003)
Aug 30 09:12:06.245: AUTH-EVENT (Gi3/34) Start request by method "dot1x" for bc5f.f439.21ca
Aug 30 09:12:06.245: AUTH-EVENT: auth_mgr_idc_insert_key_in_record: update mac bc5f.f439.21ca
Aug 30 09:12:06.245: AUTH-EVENT (Gi3/34) Sending NEW_MAC to dot1x (handle 0x5E0001D2)
!! output suppressed - results in success
This one does NOT work:
Aug 30 09:14:22.247: dot1x-ev(Gi3/34): New client detected, issuing Start Request to AuthMgr
Aug 30 09:14:22.247: AUTH-EVENT (Gi3/34) Received 'START_REQUEST', current method is dot1x (handle 0x00000003)
Aug 30 09:14:22.247: AUTH-EVENT (Gi3/34) Start request by method "dot1x" for 3860.775d.cf06
Aug 30 09:14:22.247: AUTH-EVENT (Gi3/34) MAC 3860.775d.cf06 moved from Gi1/2
Aug 30 09:14:22.247: AUTH-EVENT (Gi3/34) MAC move action is deny
!! output supressed - results in failure
Both clients are testet one at a time on interface Gi3/34.
The inteface that denies the MAC move action is Gi1/2. This is an interface connected to another network that both of the clients was previously connected to, before connecting them to the Dot1X network (In this case, interface Gi3/34)
So now the question is what the MAC move action tries to do, and why it is denied...
If i do a MAC-address table lookup of the affected address, it gives nothing! The MAC is not associated to interface Gi1/2 int the MAC table, even though this is where the auth-manager tries to move it from:
SW_3.sal#sh mac add add 3860.775d.cf06
No entries present.
If the MAC is not present in the address-table, how can it be associated to Gi1/2 ?
I found out that the following command clear "whatever state" is inconsistent:
clear authentication sessions mac xxxx.xxxx.xxxx
And now the client can access the network!
09-12-2012 08:49 AM
you're hitting a dot1x mac-move issue, the switch is detecting that the mac address has appeared on a previously authorized port, and is denying the auth for the second appearance. Try adding the following configuration to all of the dot1x enabled ports on your switch.
authentication mac-move permit
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide