Windows 10 (and 7) native supplicant issues

[pohjaton1]

We are moving our customer environment to low impact mode slowly and have been solving the different endpoint groups to authenticate those correctly before we take the action from open to low-impact mode.

However we have noticed that even though a Windows machines do authenticate correctly from the beginning, they fail to authenticate later on. We have been trying to search for best practise / working configuration from all around but no one seems to have posted such (or have not been able to find one.) Yes I know ISE is not responsible of the supplicants but for sure people has been struggling with these.

as far as we see there are some scenarios which might be the cause of the problem

• Interface power management. As far as we have understood, interface should never be allowed to be powered off by the OS
• Sleep - return from sleep. Some articles indicate that Windows would only do user auth and not machine auth. Of course if the above statement is true, then this should not be an issue I guess
• Hibernate - return from hibernate.
• Swap between wireless/wired while having both connected
• Re-authentication forced every 24 hours (for example)
• Windows timers vs ISE timers

Has anyone collected some working / best practises around the Windows native supplicant and ISE secure access deployment. Would be great if such common practises would be collected here as well.

Thanks

[Greg Gibbs]

It's hard to say for sure if this is a supplicant issue or switch/ISE configuration issue without more detail on the behaviour you're seeing, but there are two possible scenarios you should check.

1. If the Windows machine is first authenticating via 802.1x but subsequent re-authentications are using MAB, you might be running into a caveat with FlexAuth in the legacy IBNS switch configuration. Take a look at the following white paper on FlexAuth and pay particular attention to the caveat with the superscript at the bottom of the document. Flexible Authentication Order, Priority, and Failed Authentication - Cisco (Some platforms may support the Cisco AVPair attribute termination-action-modifier=1, which instructs the switch to retry only the last authentication method.) To resolve this, you can add this AV pair to the AuthZ Profile used for your 802.1x machines to resolve this issue.
2. If you're using MAR (was machine authenticated) as a matching condition, some of the scenarios you list are direct caveats for that legacy 'feature'. See the following document on the Pros and Cons of MAR. Machine Access Restriction Pros and Cons - Cisco

-Regards

Greg

[pohjaton1]

Thanks Gregory, I might actual face some of the issues in the first bullet, but while reading your response, I realised that I did not give much to work with when posting my question. So let me fill in some more information in case some more ideas would come out.

• We use machine authentication only and once that is successful, client has full access (Windows clients)
• Computer policies are sent through AD and GPO
• We have standardised environment with 3650 switches running code 3.6.5E
  • We are looking to upgrade to 16.x release due to some bugs on the current code which are affecting our environment
• We use legacy IBNS and not IBNS 2.0

and then the interface configuration is like this

description CLIENT_PORT

switchport access vlan xxx

switchport mode access

switchport voice vlan yyy

no logging event link-status

authentication event fail action next-method

authentication event server dead action authorize vlan xxx

authentication event server dead action authorize voice

authentication event no-response action authorize vlan xxx

authentication event server alive action reinitialize

authentication host-mode multi-auth

authentication open

authentication order dot1x mab

authentication priority dot1x mab

authentication port-control auto

authentication timer reauthenticate server

authentication timer restart 0

mab

no snmp trap link-status

dot1x pae authenticator

dot1x timeout tx-period 5

spanning-tree portfast

service-policy input MARK_TRAFFIC

service-policy output QUEUE

ip dhcp snooping limit rate 30

So based on that we would be hitting on the issue with the flex auth and next-method if I have understood correctly

[Greg Gibbs · Accepted solution]

It doesn't sound like you're using MAR, and the FlexAuth caveat I mentioned should only apply if you're using the following switch config:

authentication order mab dot1x

authentication priority dot1x mab

It's tough to say where the problem could lie without knowing more details about the specific symptom.

If you haven't done so already, you might just check the "Switch and Wireless LAN Controller Configuration Required to Support Cisco ISE Functions" chapter in the Reference section of the Admin Guide for your ISE version to see if there's anything you've missed.

Example from ISE 2.2 - Cisco Identity Services Engine Administrator Guide, Release 2.2 - Switch and Wireless LAN Controller Configuration Requ…

If you can duplicate the problem, you might need to start looking at packet captures, endpoint tracking, debugs (you might need TAC help with this), etc.

[o_mahieu]

Hello,
I have the same problem in a wired environment. Dot1x authentication and authorization succeeds. Client gets IP from DHCP server and Switch port gets it's correct Vlan from NPS server. Both switch and host know each other (Arp). Still I'm not able to ping from one to another... I've been searching now for several days, but can't find the answer. Do you have any ideas?
Thanks!

[Greg Gibbs · Accepted solution]

There are various reasons you could be seeing the symptom you're describing and there is not enough context or information in the show commands that you've provided to determine the cause.

If your Authorisation Policy is using a dACL, be aware that legacy switches require an IP ACL applied to the switchport to be able to apply a dACL sent by the RADIUS server to override it.

Have a look at the output from 'show authentication sessions interfaces fa0/3 details' to see if that indicates the dACL is applied.

Check your configuration against the document at the following link as a guideline. It's quite old, but still relevant for Wired 802.1x deployments using the legacy IBNS framework.

https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/TrustSec_1-99/Dot1X_Deployment/Dot1x_Dep_Guide.html

If all else fails, I suggest you open a TAC case to investigate further.

Cheers,

Greg

[o_mahieu]

Yes, i found out this was the reason. Thanks for your help anyway!

[o_mahieu]

Hello,

In using 802.1x -Windows AD - Cisco 2960 switch , everything works fine when using PEAP-MSCHAP.

When using PEAP-TLS , first authentication succeeds. After two minutes, the switch starts reauthenticating, with failure.

Do you have any idea what can cause this problem?

Thanks!

Olivier

[Greg Gibbs · Accepted solution]

Hi Olivier,

From the screenshot attached, the switch is reporting a 'timeout' which would mean that the supplicant stopped responding. There are multiple variables that could cause that scenario.

If you are able to replicate this issue easily, I would suggest opening a TAC case to investigate. TAC will likely need to get packet captures from the client and ISE as well as a number of debugs from the switch to investigate in more depth.

Cheers,

Greg

[pnowikow]

Community,

I have the same issue.  Windows native supplicant runs via "Wired AutoConfig" and for me restarting the service in Windows forces a reauth in ISE and thereby fixes the issue but only for a while.  The issue returns sometime later and restarting the service fixes it.  I'm trying to find a common denominator here.  We too are trying to move towards Low-Impact mode.

Thanks,

Pete