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:[email protected]] On Behalf Of Daniel Sichel Sent: Monday, April 27, 2009 11:43 AM To: [email protected] 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
