Cisco NAC and Slow Windows Startup in Domains

The Problem

A client makes extensive use of the The Cisco Network Access Control (NAC), a.k.a. Clean Access solution for their wi-fi enabled laptops. These systems are Active Directory domain members and prior to an AD upgrade, would boot and have a user logged in within 2-3 minutes.

After the domain controllers were upgrades to Windows 2008 R2, the bootup process went from 2-3 minutes to 10-20 minutes, with the delays showing up on the “applying computer settings” and “applying user settings” notices (Windows XP clients). Event logs would show errors indicating DNS resolution had failed and similar things.

The Solution

By default, the configuration for the Client Access Server (CAS) has a set of default traffic filters to allow untrusted clients just enough access to the domain controller. This would be the typical ports you’d expect, such at 88 (Kerberos), 135, 137-139, 389/636 (LDAP/LDAPS), etc. These rules are also mentioned in various Cisco technical guides for example, in this one, or from the 4.1 Install guide.

What I noticed was that the high TCP ports, 1025 and 1026, reflect the Windows 2003 start of the RPC port mapper range (1025-5000). In Windows 2008 (and R2), Microsoft changed this to the TCP port range of 49152 – 65535. After changing the filter from something like this:

to this:

things started working as expected with laptops booting, apply settings, and allowing a user to login within 2-3 minutes. The port range can be tied down even further by configuring registry settings on the domain controllers, as mentioned in this article: Restricting Active Directory replication traffic and client RPC traffic to a specific port.

Only after the user logs in does the Clean Access Agent pop up and allow the user to authenticate using the AD SSO, and thereby moving them from the untrusted to trusted VLAN.

I didn’t see any mention of the need for the port range for the RPC end-point mapper, so did this as a hopefully helpful tech tip.