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" <[log in to unmask]>
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
>
>
|
