Machine authentication and new user

[dgaikwad]

Hi Experts,

We have this use case
Use case: Call center
Requirements: Any user can use any machine and log in with his credentials

Issue: When a user tries to login to a machine where he has not logged in earlier, he get an error message saying its unable to reach the domain
Configuration:
Have enabled user or machine auth in native Windows supplicant
Configured ISE policy to allow machine
I can see that the authorization profile get applied when only machine is connected
When a new user now tries to login, he gets errors of unable to reach domain
I have added permit ip any to AD servers in DACL and ACL on switch, yet this error persists? 

Not sure what I am missing here.. Any pointers?

[Arne Bier · Accepted solution]

Ok so the machine auth is working.  Are you using certs for the machine auth?

if yes, then each user who logs into the shared computer will need their own user cert to allow the user auth to work.  It won't perform an EAP-PEAP for the user auth, because Windows native supplicant does not support a mix and match of EAP-TLS and EAP-PEAP.  It's got to be the same EAP method for both machine and user auth.

Failing that, turn off the user auth on the supplicant.  Let the machine boot up and use machine auth to get onto the network. No need to further authenticate every user on the network, especially if the call center is 24/7 and the machine is wired.  

[dgaikwad]

There is this another work-around that I was able to test out, I created a policy for only domain computers, then applied this ACL in the Authorization Profile:
10 permit tcp any any eq 389
30 permit udp any eq bootps any eq bootpc
40 permit tcp any any eq domain
41 permit ip any host <ISE IP address>
50 deny ip any any
Using which I was successful, letting the new user in and its profile created on the machine.

I am thinking of pushing this via DACL, but not sure if this is safe enough...

[Colby LeMaire · Accepted solution]

Just my opinion, but if you are authenticating the machine, then there is no need to authenticate the user also UNLESS there is a requirement to differentiate access based on who the user is.  In most cases, machine authentication works great and achieves the intended goal of preventing unauthorized devices from accessing network resources.

Modify the GPO for the supplicant configuration to only do machine authentication.  If the machine authenticates successfully, then give it full access to the network.  For the users, let AD do its job of controlling access to the PC and server resources.

If you really have a requirement to authenticate the user with 802.1x and you do not want to give machines full access, then you will need to use a dACL to allow access to AD domain controllers.  You would need to allow more than just LDAP (389) and I would definitely try to limit the destinations to the known domain controller IP addresses.  Since you never know what DNS will return as the closest domain controller, you would want to add all domain controllers to the dACL.  Unless AD Sites and Services is configured properly.  Then, you could add the domain controllers for the site that the client PCs are in.

[dgaikwad]

Thanks for the confirmation!

I was looking not to include the domain controllers in the dACL or ACL, but then seems that if I want to authenticate the users via 802.1x then it will be mandatory to have those AD servers listed there...

[Colby LeMaire]

It isn't mandatory to list the domain controllers in the ACL; however, it is more secure to be specific about what the device can talk to.