1

I have a login script that uses the LOGONSERVER environment variable. I have several remote offices. There is one file server/DC in each office and each office is their own site. So when a user logs in to an office they should authenticate with that domain controller.

The problem I have been seeing is that some computers in an office (not all) will authenticate with a random DC from another office some days, but some days it will be fine. So for example, a guy logs in to office 16, he should authenticate with SERVER16, however he authenticated with SERVER13. When I checked event viewer on his computer, I can see that the time synchronized with the correct server (SERVER16) however his drives mapped to SERVER13 and when running set from a command prompt it shows his LOGONSERVER as SERVER13.

So how can a computer sync time with the proper DC for it's site, but still authenticate with a server in a different site? I have checked AD Sites and Services and DNS. Each site only has one DC, the correct one, and the DNS site records for each site are correct. By all logic there is no reason why this should happen, unless I'm missing something. Also, we are running mixed 2003/2008 Windows environment and it doesn't matter what the platform of the server is.

2 Answers2

1

This is actually more common than you may think. Check the following to see if it helps:

How to force machines in an AD site to authenticate against a GC in their own site

Community
  • 1
Greg Askew
  • 35,880
  • 5
  • 54
  • 82
  • The last guy who managed AD set this up, but no one really knows why. I have site links setup from my central site to each remote site with a cost of 100. Then I also have a site link that has all other sites in it with a cost of 10. So would this mean all sites can talk to each other with a cost of 10? Essentially allowing a computer to authenticate with any DC they want if their local is unavailable. Is this a good way to go, or a bad way. As I said, no one knows why this is setup, but by all logic it makes sense that this could be the cause. Have you ever heard of this configuration? –  Mar 09 '10 at 22:48
  • Sorry for the late reply. I'm not sure. I know that between any two points, AD prefers a link with a lower cost. What this means in your topology, I don't know. Why someone would manually create these two links...? We usually stick with automatic site links, there is no way we could manage a strategy of individual one-offs based on certain criteria. You may try adjusting the RegisterDNSARecords so that a remote site would prefer the central DC if the local DC is unavailable. You may want to perform packet captures before and after any changes to confirm the results of your changes. – Greg Askew Mar 09 '10 at 23:35
0

We have seen this for a couple of different reasons:

  1. DNS/WINS is not set correctly on the clients. Make sure that they don't have a secondary DNS/WINS server that isn't on their local network.
  2. Make sure the cost across the links is set higher than default in AD Sites and Services. If it isn't and the local DC is busy, the remote DCs might answer sooner because the cost across the link is set low enough that thinks it should respond as the nearest DC.
Scott Lundberg
  • 2,364
  • 2
  • 14
  • 22