Join the club. I had to go through all the same stuff. One big thing to look into is you gpo setting for running scripts synchronously or asynchronously. Additionally, I have not found a way to access profiles without opening it up to the unauthenticated role. I realize the threat associated and take it with understanding that we have introduced l3oob nac as another layer on what was already over exposed.
This kind of confused me: ---> I am going to explore using the internal VLAN as the authentication VLAN (currently, we're using our guest VLAN as the authentication VLAN, moving users to the internal VLAN only if they can authenticate as an appropriate AD group member.) ---> In our implementation we have a separate VLAN for authentication. If authentication fails (either with no agent or no valid credentials) they go into a guest VLAN. The get access to the guest vlan they must register credentials (guest server coming soon). All else fails they black hole at the firewall. -j Dave, I am sending the image separately. ---- -----Original Message----- From: Cisco Clean Access Users and Administrators [mailto:[EMAIL PROTECTED] On Behalf Of Stempien, Dave Sent: Wednesday, May 21, 2008 10:23 AM To: [email protected] Subject: Re: AD SSO - required open ports? Thanks to everyone who responded with very useful tips. I my oversight was in not providing UDP *and* TCP access to port 88 (kerberos) in my unauthenticated role policy. Apparently, our AD infrastructure requires both. AD SSO is now working properly. However, now I have additional challenges... First, most of our user profiles are configured to map the user's home directory to a network share. This requires opening access to that share from the unauthenticated role; else, there is a *long* delay in the login sequence. Second, this authentication method will primarily be used in our wired OOB deployment. In this setup, there is an appreciable lag in moving the user from the IB authentication VLAN to the OOB user VLAN (10-15 seconds while the switch port VLAN is repainted and bounced and the machine obtains the new IP address via DHCP.) I have the agent configured to refresh group policy after authentication; however, our group policy launches a login script to mount other network resources -- and this is failing to occur due to the delay in switching from OOB to IB. I am going to explore using the internal VLAN as the authentication VLAN (currently, we're using our guest VLAN as the authentication VLAN, moving users to the internal VLAN only if they can authenticate as an appropriate AD group member.) Additionally, there are user experience considerations I need to address. For example, the agent says, "You are successfully logged into the network" while at the same time the network icon in the task bar says the network is disconnected (due to the activity described in the above paragraph.) I'm slowly getting AD SSO and OOB working. However, it's beginning to feel like toothpicks and duct tape as opposed to concrete and steel. Much of this can be attributed to the complex nature of a Microsoft AD infrastructure, although I would really like to see Cisco place the agent in pre-login mode on Windows machines, ala the Cisco VPN client, and then use the CCA credentials as SSO for AD sign-on. All of this is in opposition to our wireless deployment with RADIUS SSO which is working well enough. Comments welcome... -- Dave Stempien, Network Security Engineer University of Rochester Medical Center Information Systems Division (585) 784-2427 On 5/20/08 12:29 PM, "Stempien, Dave" <[EMAIL PROTECTED]> wrote: > Does anyone have a definitive list of the ports required to be open in the > > unauthenticated role for AD SSO to work? I've opened the following ports to > > our DCs per the suggestion of the Cisco documentation: > > > > TCP 88 - Kerberos > > TCP 135 - RPC > > TCP 389 - LDAP > > TCP 1025 - RPC > > TCP 1026 - RPC > > > > After doing some sniffing, I discovered that our DCs are also using UDP for > > kerberos and LDAP, so I opened the following: > > > > UDP 88 - UDP-Kerberos > > UDP 389 - UDP-LDAP > > > > Also, per a previous suggestion by Cisco TAC, I also opened: > > > > TCP 445 - SMB > > > > Finally, ICMP and DNS is also allowed. > > > > Currently, my test machine won't even completely log into the domain let > > alone perform SSO. It's stuck at "Applying computer settings..." If I > > completely disable my unauthenticated policy (except for ICMP and DNS), I > > can log into my test machine using cached credentials. > > > > Has anyone else beaten this beast and care to share your experiences? > > > > Thanks! > > > > -- > > Dave Stempien, Network Security Engineer > > University of Rochester Medical Center > > Information Systems Division > > (585) 784-2427 > >
