Dan, We are an educational institution running AD with Clean Access IB and OOB and I've run into the exact same problems that you have.
At this time the only fix we have is to allow "ALL IP" access to our DC's and the file server that holds our roaming student profile in the Unauthenticated Role. In the traffic policies you can specify Category "IP" and choose the Protocol "CUSTOM", this allows you to give full IP access to a single IP address or subnet. As you've stated, using one of the documented delay scripts doesn't work with roaming profiles, although I have used the ping script to delay drive mapping. If you are using the Agent, you can use it to run GPO updates after login. (From at least 4.1.3 and up). At this time there doesn't seem to be a secure way to integrate AD and Windows domain functions with Clean Access. We are planning on a new implementation where we build a hardened DC/Profile server, put it in a DMZ and make it the only server available in the Unauthenticated Role. DOUGLAS R. COOPER Systems Administrator, CCNA Information Technology Services Trinity University 210-999-7437 (w) 210-643-8811 (m) [email protected] http://www.trinity.edu/ -----Original Message----- From: Cisco Clean Access Users and Administrators [mailto:[email protected]] On Behalf Of Daniel Sichel Sent: 2009-04-08 11:56 To: [email protected] Subject: Desperate for help with Clean Access and Active Directory 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
