cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
835
Views
1
Helpful
2
Replies

ISE 2.3 - Native Supplication Sporadic Behaviour

kaachary
Cisco Employee
Cisco Employee

With one of our ISE deployments, we are using the native supplicant in Windows 7 and doing a Machine+User auth (with PEAP).  Machine auth works fine. Now, If a new user logs into the machine where the login profile needs to be loaded from the domain, we get a message “There are currently no logon servers available....”. User authentication however is successful on ISE and user gets the correct AuthZ policy. For locally present profile (cached) it works fine, however takes a long time to log in.


On ISE we sometime see it performing machine auth again after a successful user auth!! It also seems as if DHCP release/renew is taking time after the VLAN switchover and hence connectivity to domain controller fails. The output from the switch for "show auth sessions inte gigXX detail" shows it using the same IP address as machine VLAN. As a test, we have allowed everything in the DACL for machine auth, but that did not resolve the issue.


We disabled "Fast Reconnect" on the supplicant, and so far tested 2-3 machines, and it seems to work ok.

We also see improvement in time taken for windows login. Not sure if "Fast Reconnect" setting also applies or messes with a new session? Hence, We want to understand the recommended settings for native supplicant for User+Machine auth?


Your help is highly appreciated.

1 Accepted Solution

Accepted Solutions

paul
Level 10
Level 10

A couple things here. It sounds like you may have single sign-on enabled in the supplicant which I usually don't enable:

Capture.JPG

Also, you have to be very careful when you allow a transition to PEAP User mode.  You are opening up a security risk by doing this unless you put some insurance in place that the User is still logged into a corporate computer, i.e. MAR cache, AD profiling, EAP chaining with AnyConnect NAM.

The Windows supplicant is not User AND Computer it is User OR Computer.  So when you allow it to transition to User mode the Computer part is lost in the 802.1x  authentication.  If you don't put safeguards in place to ensure the user is still on a domain computer then anyone can bring in any device and put their AD credentials into the supplicant and get on the network.  Customers are usually trying to avoid just that.

My standard is PEAP Computer only.  If the customer has requirements for User information at the network layer I look at certificates.  If there is only requirements for User information for pxGrid clients you can leverage Passive ID.

View solution in original post

2 Replies 2

paul
Level 10
Level 10

A couple things here. It sounds like you may have single sign-on enabled in the supplicant which I usually don't enable:

Capture.JPG

Also, you have to be very careful when you allow a transition to PEAP User mode.  You are opening up a security risk by doing this unless you put some insurance in place that the User is still logged into a corporate computer, i.e. MAR cache, AD profiling, EAP chaining with AnyConnect NAM.

The Windows supplicant is not User AND Computer it is User OR Computer.  So when you allow it to transition to User mode the Computer part is lost in the 802.1x  authentication.  If you don't put safeguards in place to ensure the user is still on a domain computer then anyone can bring in any device and put their AD credentials into the supplicant and get on the network.  Customers are usually trying to avoid just that.

My standard is PEAP Computer only.  If the customer has requirements for User information at the network layer I look at certificates.  If there is only requirements for User information for pxGrid clients you can leverage Passive ID.

What you are talking about Paul is trusted users on trusted devices

You can also look into

Machine auth plus CWA (CWA Chaining)

AnyConnect eap chaining (future TEAP)