Hi Dan, We are not an academic institution but we use CCA in a OOB deployment using Microsoft AD and SSO. We experience similar issues with login scripts and currently there are few work arounds to this. We use Kix login scripts with a loop set to ping a DC and waits to completed until it can. This for now seems to work most of the time. You can configure your CAM/Cas to allow ALL IP access to the DC's under the unauthenticated role. We don't use roaming profiles so don't have any input for you on this. We use GPO's quite a bit, but since we allow ALL IP access to the DC's this eliminates that issue. Currently there is no easy way for integration with AD, and have had quite a few issues using SSO. Cisco has advised us that in the 3rd quarter they are going to have a new agent that will run as a service vs. the use which should eliminate most of these issues, and think it would help with your roaming profiles as well.
David Maas Sr. Security Engineer Merkle, Inc. http://www.merkleinc.com Enabling Knowledge to Improve Marketing Results -----Original Message----- From: Cisco Clean Access Users and Administrators [mailto:[email protected]] On Behalf Of Daniel Sichel Sent: Wednesday, April 08, 2009 12:56 PM To: [email protected] Subject: Desperate for help with Clean Access and Active Directory I apologize for this long post, but I am DESPERATE. I know most users on this list are Academic institutions and do not use Clean Access in an Active Directory environment. However, I am hoping to find at least one other enterprise user with an OOB virtual gateway deployment in a Microsoft Active Directory environment. I have several issues that I am struggling with on this and frankly, Cisco's response has been "if that doesn't work with Clean Access, than don't do that." So, here are a couple of problems. Problem one, we use roaming profiles. The only way to make them work with Clean Access is to grant complete file sharing and netbios access to the server that has the profiles stored on it to the authentication network. If unremediated users can access network shares, why have NAC? The only way around this that I can see is to somehow delay the profile synchronization process until AFTER Clean Access OKs the workstation and the vlan changes. Using the crude delay mechanism that Cisco documents to make your login scripts work does NOT delay the profile synchronization, and it fails. Every time. Does anyone know how to make it work? All I have been able to find is a vague reference to a program called userinit.exe that runs at startup and to paraphrase Microsoft, "...does some stuff with your user ID and settings that we prefer not to discuss, so let it run, but don't ask what it does." If I could identify the profile synchronization process, I have a script written in AutoIT3 that I could use to re-launch it after Clean Access. Any help would be welcome at this point. Problem two, getting group policy to work on a Clean Access enabled workstation. Group Policy, especially machine policies fail with Clean Access in place. As an act of desperation I allowed all TCP, all UDP, and all ICMP traffic to and from my domain controllers because group policies (especially machine policies) were failing at start up. Apparently when a workstation is on the authentication VLAN, it can't have the conversation with a DC at startup to implement group policy reliably. To fix it, I tried opening up all types of traffic. Guess what? It still failed (WTF?). The only thing that worked was to use the "all traffic" option in traffic management. Unfortunately, you cannot specify an 'all traffic' policy to a single IP or subnet. It is either allow it everywhere, or not at all. Heaven knows why. I have opened a TAC case on this one, but even if there is an answer, allowing free access to your DCs this way seems to totally negate the reason to have NAC in an enterprise environment. I am not wild about using a Read Only DC using Windows 2008 on the authentication vlan either, but this appears to be the best of some really bad choices. Checking the option to run gpupdate after Clean Access isn't cutting it either. The machine based policies just don't seem to happen. I am really hoping somebody out there can tell me a secure work around, I would like to think that I have been dense in my implementation of Clean Access rather than being dense in choosing it in the first place. I have been almost three years trying to implement this and would like to get it done. Thanks for wading through this, and for any help you might have. Cheers! Dan Sichel [email protected] Ponderosa Telephone
