We are encountering several problems with regards to the NAC Agent. We are deploying AD SSO and for some reason, on the same switch other hosts are performing SSO correctly and others are being prompted for a user name and password by the NAC agent even though the hosts are all logging in the same domain. Do you guys have any idea on how to go about this problem?
Check for IP FRAGMENTS to your domain controllers and make sure that IP FRAGMENTS are allowed in the unauthenticated and temporary roles to all your domain controllers.
SSO failures generally happen when some critical traffic that is supposed to be allowed isn't. What do your unauthenticated and temporary role traffic policies look like?
This is Joel from Bermuda and I am running into the same problem as these guys. What you explain with thepolicy that is correct and one thing I have seen where its corrected is the client 4.7.2 version that seems to fix the probelm when I ahve them installed on clients machine. I am thinknig about upgrading from 4.7.1 to 4.7.2 to see if this wil lcorrect any of the problems so let me know what you think.
What I was trying to explain is pretty simple. SSO will fail if there's some required traffic that is being blocked. Here's the list of things that need to be open in the unauthenticated role to ALL DCs in your AD: http://bit.ly/9IvwaC
Another thing to watch for is to ensure that your AD health is good. I've seen in multiple instances where the DCs would register their unused NICs 169.254 IP addresses in the DNS. CAS does a nslookup and if it tries to use that IP address SSOs will fail.
We have experienced what sounds like a similar issue on our recently activated NAC deployment. disclaimer: I'm a NAC newbie so please forgive me for dragging this conversation down to my level...
I found that, for us, the machines that have the Agent pop-up and ask for an ID and password instead of using SSO are usually laptops that were put into Sleep or Hibernate, then undocked and taken home, the next day the user comes back, redocks and awakens the PC. Or maybe they were shutdown cleanly, but were powered up offsite, then put to sleep and later Docked while in Sleep or Hibernate mode.
A reboot seems to set things aright although I have had to "Bounce" the port from the NAM once or twice. (we are using "Control Method: Mac-notification")
Is there some setting that will correct this behaviour? Telling the User to reboot is not winning me any popularity contests.
There might be a few things at play here. First's the fact that AD SSO works when your machine is "live" on the network and boots up from that. This is for the kerberos tickets etc, so in situations where you boot up somewhere else than your network, it might be using cached credentials, and hence SSO fails asking you for credentials.
On your port profile too depends how the CCA acts when it sees a client which it finds in the Certified Device List. Look at the options for those closely to see how it's supposed to behave and if there's deviation from that, please let us know.
For those who are also experiencing this problem, you might also want to check the user pc's system time. If it deviates for more than 5 minutes from the
system time of the AD, the NAC agent will pop up asking for a username and password even though ADSSO is configured correctly. Another issue is expired passwords on the AD.