Hello- At the risk of sounding obnoxious, Clean Access is really intended for Anonymous connections to machines (as viewed by Active Directory). We've used it in the residence halls mainly because there is no way to gracefully bring student operating systems in and out of the Domain.
At the risk of being more obnoxious, I suggest looking hard at 802.1X. I think the Microsoft NAC product might have the ability to use a supplicant to detect domain membership or maybe a flag that you install when you bring a computer in to the domain, and then you can just dump the machine into a trusted VLAN at connect time. Dave -----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
