It comes in handy at times to connect with my network at home through a secure VPN connection. I typically use this connection to access files that have been backed up or archived. Prior to upgrading my notebook PC from Windows XP Professional to Windows 7, there were no issues. A problem surfaced, however, just after the upgrade. Within seconds after establishing the VPN connection, my AD user account at work became locked. The reason for the lock: Incorrect password entered more than five times. But how could this be since all I did was establish a VPN connection? How did the upgrade to Windows 7 cause this?

Follow up:

Here's the configuration:

A notebook PC running Windows 7 that is a member of the Windows Server 2003 domain at work.
The VPN client on the notebook is provided by Windows 7.
The endpoint of the VPN is a Cisco PIX 501 Firewall and the connection type being used is L2TP.
The network at home is a Windows Server 2003 domain.

By examining the domain controller at work, I discovered that Kerberos is involved. Immediately after establishing the VPN connection with the home network, the notebook PC sends a request for a ticket granting ticket to the DC. Using Wireshark, I was able to see that the DC responds with a KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED packet. The notebook PC then sends another AS-REQ packet with additional information. The DC responds with a KRB Error: KRB5KDC_ERR_PREAUTH_FAILED packet. These exchanges take place five times until eventually several KRB Error: KRB5KDC_ERR_CLIENT_REVOKED NT Status: STATUS_ACCOUNT_LOCKED_OUT packets are seen. Why would the notebook PC need to request a Kerberos ticket granting ticket from the DC at work immediately after connecting with the remote network via VPN? Maybe someone more familiar with Kerberos and Microsoft Windows 7 could answer this.

I then decided to see what traffic is exchanged between the notebook PC and the domain controller at home after the VPN connection is established. The first connection was initiated by the notebook PC to tcp port 445 on the DC. The second connection was initiated by the notebook PC to tcp port 135 on the DC. What would happen if this traffic was blocked?

When a Cisco PIX firewall config contains the line "sysopt connection permit-ipsec", all traffic is allowed to flow from a VPN client to the inside network of the PIX. By removing this line from the config with "no sysopt connection permit-ipsec", all traffic is blocked unless explicitly allowed through an access control list (ACL) on the outside interface for inbound traffic. I began by removing the sysopt connection permit-ipsec line. This worked! The AD user account at the office was no longer being locked out. But I had a useless connection at this point since no traffic was allowed to flow.

Through experimentation of gradually adding ports via an access-list on the outside interface, I discovered that by opening tcp port 445 or tcp port 139 the lockout problem returned. Unfortunately, this prevents me from establishing a drive mapping across the VPN but I can use Remote Desktop (RDP) or pcAnywhere to access the files.

An excellent resource for determining important ports required by various Windows Services can be found at: Service overview and network port requirements for the Windows Server system

So it turns out that the Windows 7 upgrade caused me some grief for a while but I was able to come up with a workaround.