Windows Supplicant Single Sign On and user or machine authentication issue

[dgaikwad]

Hi Experts,
Use case: Support center, allow multiple users to use same computer as per their shifts
Issue: When a user does not have a profile present on the computer, he cannot login.
Current workaround: Login as administrator , then run one of the application (e.g. Chrome as the required user) then log off as administrator and login as the user.
This causes a lot of calls to be logged in thus overall increasing the ticket count.
Current solution that I have implemented is using the user or machine authentication on the native supplicant setting and creating a policy that allows domain computes to communicate to AD when the user has logged off the computer.
So, when the user enters his credentials even if his profile is not present on the computer, it gets created.
Now the issue that I am seeing is that, when I have single sign on turned on the Windows Supplicant setting, even though when posture is completed and reported as compliant, the endpoint gets stuck in limited access VLAN and does not get the full access VLAN.
But, if I remove the single sign on setting from supplicant, the posture goes through and endpoints gets the full access VLAN when reported as compliant. The final config on supplicant looks something like this:

We also do not want to remove the single sign on, since 80% applications that we are using on Windows are configured to pick up logged in user credentials.
The question is that is this an expected behavior? Or are there any additional settings that I am missing out?

[Colby LeMaire · Accepted solution]

Do you apply different policies based on who the user is?  Or is every user treated the same at the network level?  These are very important questions to clear up because the setting of "Machine or User Authentication" opens a hole in your security that will allow a non-corporate computer to gain access to the network.  With that setting and using the Windows supplicant, there really is no good way to ensure that the machine connecting is a corporate asset.  You could plug your personal laptop in and use your AD credentials to gain access.  And to me, the first priority/concern is ensuring that the machine is supposed to be allowed on the network and is a managed device.  Because personal devices can bring malicious code into the network.  User authentication for 802.1x is a secondary thing is optional.  It is only necessary if you want to differentiate access based on who the user is.  The other side benefit or reason to do it is for visibility as to who is on what machine.  But to do that securely, you need to do EAP-Chaining which requires the use of Anyconnect NAM.  Adds a lot more complexity and cost for little benefit if you aren't differentiating access based on the user.

So the first recommendation is to change that to "Machine Authentication".  If the machine authenticates successfully, then give it full access.  It would be able to communicate with AD so the users can login without cached credentials.  If you care more about the user authentication, then you would need to have a pre-auth ACL that allows connectivity to the AD domain controllers for those users without cached credentials on a particular machine.

[Jason Kunst]

There are many posts that already cover this in detail . I did a google search and some of the top answers were good

https://www.google.com/search?q=ise+differentiate+machine+user&oq=ise+differentiate+machine+user&aqs=chrome..69i57j69i64.5629j1j7&sourceid=chrome&ie=UTF-8


https://www.networkworld.com/article/2940463/machine-authentication-and-user-authentication.html

Microsoft is looking at support TEAP I believe in the next 6 months or so
https://www.google.com/search?q=microsoft+teap+support&oq=microsoft+teap+support&aqs=chrome..69i57j0l5.3771j1j7&sourceid=chrome&ie=UTF-8

[dgaikwad]

Thanks for pointing me towards them, they are really great answers, but they do not cover the difficulty that I am running into, thus the help from forum.
I have done all the configuration as described in the forums or the documentation and have made sure that when machine is authenticated then it has as less access as possible.
The thing is that when user initiates a login with his credentials, then he does get logged in and posture run and reported as complaint, and ISE applied the authz profile of full access, which contains a VLAN change to full access VLAN.
And that is where I found the issue that VLAN change does not occur to full access VLAN.
Where as, if unchecked the single sign on option form the Windows Supplicant, the VLAN change happens and the compliant computer gets VLAN changed to full access...
So, the question still remains that is this a default behavior of Windows Supplicant, or is there any further configuration that is needed from my end?

[dgaikwad]

Yes, all the users are being provided separate access based on its type.
Secondly, the authorization policy checks if the machine is a domain machine, by checking domain computers on AD.
Then this policy is applied with authorization profile that restricts the machine to only ISE server and AD server over udp/389, so I I think, this way also the machine has very limited access to the network and the risk is reduced.
Thirdly, the complete authentication will be provided when the user authenticates using his credentials post the posture check is completed and at each level, we are checking if the machine is a domain computer and user is also same AD domain.

So, now going back to my issue, is when I enable single sing on setting as seen on the Windows supplicant, the posture status of compliant is sent, but the VLAN change never happens to full access... Is this an issue with the supplicant or something more needs to be done, as we are not planning on moving to NAM due to added complexity....

[Colby LeMaire]

I still have a couple of concerns about your configuration.  You are using the Microsoft supplicant which can do either machine or user authentication.  Not both at the same time.  So yes, when no one is logged into the machine, the computer will be in "machine state" and will present its machine credentials.  That can be checked against AD for Domain Computers.  Now when a user logs into the machine, the computer will switch to the "user state" and will only present user credentials.  You can check the username against a group in AD.  The problem is that there is no way to check both the machine and user in the same rule when using the Microsoft supplicant.  If you have a computer that is already logged into by a user and it plugs into the network, ISE will never see the machine credentials for that device.  Which also means that you can have a personal laptop and login using AD credentials and it will be allowed on the network.  That is a bad thing in my eyes.  Sure, you can do Machine Access Restrictions (MAR); however, it isn't very reliable since it relies on a cache that times out.  And also doesn't help in the case where a machine is always logged into by a user.  The only real secure way to do both machine and user authentication is by using EAP-Chaining today.

The next concern is doing a VLAN change for Windows machines.  When Windows is booting up and logging in, there are GPO's, login scripts, drive mappings, etc that happen.  If you switch VLANs, the IP address changes and potentially breaks GPO assignment, login scripts, and drive mappings.  The recommendation would be to use a common data VLAN and then apply dACL's based on what that device/user should have access to.

The single sign on option should not be needed.  That is only for network authentication, not SSO for applications or anything like that.  It is primarily used when the network credentials are different from what the user is using to authenticate to the computer/domain.  It can present a login prompt (for the network) before the actual computer/domain login prompt.  Have you tried disabling single sign on and try your situation that way?