I have NAC configured and running in an OOB deployment using Window SSO. Most users authenticate into their computers and then NAC does the login and posture assessment using SSO and those credentials.
We have a few users that have the Clean Access Agent pop up and ask them to enter a username, password and role. They can successfully log in using the same username and password that was used to log into the computer and domain. I have not been able to figure out why SSO does not work for them.
I have one user specifically that has the above problem, but can log in through SSO on another system without a problem. Other users can also log in successfully using SSO on the same PC that this user has problems with.
I am wondering if anybody has an idea what is causing this behavoir? I suspect that something is cached in that users temp files that is causing the problem, but I have not found anything.
We are running:
NAC OOB Clean Access Server version 4.6.1
NAC Agent version 22.214.171.124
This sort of failure is sometimes due to necessary traffic being blocked in the unauth role. Can you verify whether the IP FRAGMENTS are open for all your DCs in the unauth role?
No, IP fragments are not enabled by any of the rules.
This brings up two questions:
Answer lies in GPOs. Most of the times we see this is when GPOs are enabled, and sometimes with GPOs the packets get large enough that fragmentation occurs. In that situation if IP FRAGMENTS policy is not defined for the DCs in the unauth role, SSO fails.
Enabling IP FRAGMENTS is part and parcel of ports setup on CCA for AD SSO. More documentation on that linked here: http://tinyurl.com/yf2ue3z
I enabled IP fragments but those users are still having the same issue. As I said in an earlier post, there is one user that can logon to other systems and have SSO work, but on his primary system he has to enter his credentials again when the CCA agent runs. Other users on the same system can logon and have SSO work without any issues.
Please let me know if you have any more ideas.
Check the time on that machine and make sure it's within 5 minutes (ideally should be pointing to NTP) of the DC and CAS/CAM
Our machines are all supposed to get their time from the Windows DC, which in turn gets it from the company's NTP servers. The CAM and CAS systems all get time directly from the company's NTS servers.
I will have the client check the time to verify, but if that were the issue then others using that same system should have the problem also.
From the agent logs: [func=SSPClient::SSP_InitializeSecurityContext]: Call to Initialize failed with code 0x80090311
This still looks like an AD reachability issue to me. Please verify that the required ports and traffic flows are open to ALL your DCs in the unauthenticated role. Details on that: http://tinyurl.com/yf2ue3z
If that still doesn't fly, please open a TAC case so an engineer can work with you.
I have verified that all of the ports listed in the document are open, but the user is still having the same problem.
As you suggested, I will open a case with TAC. Thanks for your effort.