Wired 802.1X with ISE | Some computers cannot be authenticated

[lap]

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

[Tarik Admani]

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*

[andreassb]

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.

[andreassb]

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!

[justinhao]

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