Clients unable to logon to the domain
Today was a tough issue (from a time perspective). I am kicking myself for having taken soooo long to fix this issue. Ok, clients cannot logon to the domain. Basically if the clients were able to "logon", it was with cached credentials. New users on computers they have never logged onto would get an error about not being able to contact the domain controller (note to self...get exact errors so I can post them and potential readers can search them). The network layout was SBS and clients on Subnet A and remote clients on Subnet B. The problem was occurring on both subnets. The "subnets" were actually a site-to-site VPN using a hardware VPN device. The "change" that predicated this problem is that the firmware was upgraded on the firewall/routers. Note it was not a simple cause and effect (update firmware --> no one can logon) as a couple of weeks had passed since the firmware upgrade. Ok, handle these all the time, usually DNS related. Here is what I did:
1. NSLookup from a client. Worked absolutely perfectly. Able to connect to the sbs box. SRV records present and accounted for.
2. Tons of Userenv errors and Netlogon errors on the client. All saying some variation of "can't talk to the domain". Errors like the one's documented here: http://support.microsoft.com/?id=891559
3. DCDiag and NETDiag on the server were absolutely clean. They were run in "verbose" mode. Dcdiag -v > c:\dcdiag.txt and netdiag -v > c:\netdiag.txt
4. As a test, disjoined a machine from the domain, renamed the machine, re-join the domain. It took a LONG time to "join" and after the reboot and logon attempt, it hung indefinitely.
5. During the logon attempt, we took a netmon capture from the server. We saw the RPCBind with the UUID. We then saw a Ack Fin from the server after a 15 second delay. Nothing much useful...
6. On a whim, implemented the steps in http://support.microsoft.com/?id=244474 to force Kerberos to use TCP rather than UDP. BINGO!!! Note these steps are performed on the clients.
Note that the article talks about domain validation across a VPN connection and fragmented UDP packets. The scenario I worked on had clients on the local subnet that were failing (if my IP routing knowledge is correct, we should not be hitting the gateway). When I get a case where clients have almost any problem across a VPN connection, I will implement these steps. In retrospect, this was a switched network with 2 "un-manged switches". I may broaden my use of this article to include "switched" networks.
Cheers!
Petergal
