Not sure if anyone has already discussed this / investigated, but we had to enable DCERPC inspection on our Cisco FWSM when we started locking down communications to the Domain Controllers. Perhaps, there is some epmap port-hopping going on. If this is the case, you could place the DCs behind a firewall, enable the DCERPC application inspection on the firewall, and then permit ALL TRAFFIC to the DCs at the NAC appliance.

Full disclosure: We haven't deployed to our academic campus yet, so this is just mere speculation.

Thoughts?


-Tim

Tim Riegert
Towson University
Network Engineer



-----Original Message-----
From: Cisco Clean Access Users and Administrators [mailto:[log in to unmask]] On Behalf Of Daniel Sichel
Sent: Monday, April 27, 2009 11:43 AM
To: [log in to unmask]
Subject: Re: CLEANACCESS Digest - 23 Apr 2009 to 24 Apr 2009 (#2009-77)

>Does anyone have a list of TCP\UDP ports that need to be allowed for a
>PC to be part of a Windows domain.  The PCs are behind Clean Access and
>are filtered in a group.  The DC is not behind CA so we've created a
>rule to allow certain ports to be open to communicate back and forth
>with the DC's subnet.  Joining the domain has been remedied but we are
>not getting Group Policies and other domain functions to propagate
>properly.  Anyone who can shed some light would be much appreciated.


I believe the following is recommended
Port 88 tcp and udp
Port 389 tcp and udp
Port 445 tcp and udp
Port 135 tcp and udp
Port 139 tcp

Cisco also lists port 1025 TCP and 3268 tcp and udp, I  am not sure why.
I would also add ports 137 and 138 TCP and UDP, plus, as discussed
below, ICMP traffic to DCs.

You will not get group policies to propagate properly even using the
Cisco
provided checkbox to do a policy update (at least in version 4.5). The
only solution
that we have found is to allow all ip traffic to our DCs. I cannot find
what 
exactly Microsoft is doing even using packet traces, but I did see that
you MUST allow ICMP traffic to the DC
for group policy to happen. Heaven knows why. Also don't forget your
WSUS server. This all means you can't use
Cisco's solution for delaying login (which doesn't really work anyway,
so small loss there). I really wish that I 
Could also get a list of traffic GENUINELY REQUIRED for AD stuff to
work. My guess is that there is a bug in
Clean Access that is not really letting through traffic correctly when
specific ports are delineated, but that
Works fine with the wildcard. However there are not enough hours in the
day to do even more testing for Cisco. 

It is quite clear that their testing of Clean Access in an AD
environment is completely inadequate. Don't expect
That to change any time soon. 

Another thing I just found out (last week) is that netbios (even over
tcp/ip) takes a VERY long time to
Discover shares, so you have to allow a LONG time after the workstation
comes onto the access VLAN
For some shares to appear. This has caused us significant pain and on
top of that, many shortcuts, 
(especially in toolbars for some reason) seem to break.

I have been fighting this for three years, and only recently have I
finally got this working well enough 
To turn my users loose on it. If you use roaming profiles, you will have
even more headaches.

Cheers,

Dan Sichel