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 > >
