While troubleshooting excessive client login times, we identified an issue where the clients in one site would authenticate with DCs on the other side of the country.
In our case a few of our sites are very well connected to our core site via high speed low latency links, so there are not any local DCs at site that users report slow logins.
Initial test were inconclusive as a well connected DC was selected by the client, but we got lucky and one of our test system started experiencing the slow login issue. After login set logonserver was run from the command line and a DC in the remote location with > 115ms latency was selected by this particular client PC. At this point we were pretty sure the issue was in the AD site configuration, but did a couple more tests to confirm the suspicion.
We then repeatedly ran the following command multiple times to confirm our suspisions:
nltest /dsgetdc:domainname /force
The nltest command with the dsgetdc uses the same API the client does to select a DC. In our case after multiple runs of the command DCs on the other side of the country were returned.
After notifying the directory services team of the issue it was determined that at the direction of an AD Consultant the site links between the core site and remote site were removed, and since no DCs were present on the site and the clients didn’t have enough information to determine the proper cost of a DC and were randomly selecting any DC in the environment.
The AD team recreated the site links and the nltest command now only returns DCs in the core site.