Wired Domain Computer/User login taking to long to get to dot1x authentication success status.

[laurathaqi]

Dear community, 

I have configured Wired 802.1x EAP-TLS and configuration is giving successful AuthC and AuthZ, however the issue is with the time it is taking to Authenticate and Authorize the NIC Card of the supplicant. 

When log out and then login, it is taking to long to get authenticated/authorized.

Configuration of the switch port is as following: 

!
switchport access vlan 10
switchport mode access
!
authentication event fail action next-method
authentication event server dead action authorize vlan 10
authentication event server alive action reinitializes
authentication host-mode multi-auth
authentication open
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication timer inactivity 180
authentication timer restart 3600
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout tx-period 10
spanning-tree portfast
spanning-tree bpduguard enable

!

Meanwhile the configuration in ISE is standard EAP-TLS Rules, including DACL for domain Users and different DACL for domain Computers. 

Do you have any idea what could be causing the delay of around 60 seconds of Logging in a Windows supplicant? It is happening all the time I logout and login again. 

Any thoughts or ideas of what could be causing this issue would be highly appreciated. 

Thank you,

Laura

[Arne Bier]

Hello @laurathaqi 

Did you find the root cause of this?  Withouth knowing too much more, I'd start with a tcpdump on the ISE PSN node that is handling the requests and analyse in Wireshark to get an idea of the packet exchange and timing of events. If the TLS happens very quickly (once it happens) then the issue might be on the clients. Are you using the Windows native supplicant or perhaps Cisco AnyConnect installed?

There might also be some wacky config setting in the supplicant.

[hslai]

Adding to what Arne said...

I would suggest to verify whether (A) 802.1X or (B) windows logon taking time. If former, then check ISE auth details reports and the auth policy sets for optimization. If (B), then it could be due to the access list is too restrictive, etc.

[laurathaqi]

Hi @hslai Hi @Arne Bier 

We did do tests via RDP and some other times via direct user authentication on the computer. 

The resulting reason for the authentication taking to long was in fact the Windows native supplicant not supporting identity user authentication via RDP.

This caused lots of issue for us on implementing ISE because the solution TAC suggested was AnyConnect NAM. And our NADs do not support URL Redirection thus making it impossible for us to do any kind of user authentication.  

What got me into surprise and I still wonder how literature did not mention this issue in the beginning even thought ISE is usually integrated with Windows Supplicants! The issue is only to  be found after you search specifically for it on forums with people facing the issue.

I knew that devices did not support url redirect thus I knew I would not be able to use Anyconnect, however not being able to utilize identity user authentication is critical thus leaving quite a gap on security architecture overall. 

So in short: request was doing machine authentication, then proceeding to user authentication and then going through timeouts. Did 'ip any any' at the computer level authC and the process succeeded without delay via RDP. Live logs showed only machine authentication. 

Meanwhile direct authentication on the machine, without any remote software, works fine on both user and machine authentication.

Thank you for the support and interest to know more on the issue. 

Best regards,

Laura

[hslai · Accepted solution]

One possibility is to use Easy Connect in identifying the user login while keeping 802.1X for machine auth.

[Filip Po]

Hello.

At the first. You should go back to monitoring mode.

Change machine and user dACL to permit ip any any.

Check if the error persists.

Or even deeper is three options for troubleshooting:

- SPAN session, and wireshark check

- apply line at the end of dACL with deny ip any any log and watch the console output

- third option is to use debug aaa

I think this should have deal with not all necessary ports are available through ACL.

Do you also dynamically change the VLAN after the user successfully authC?