Windows 7 AD behavior

[deanwebb]

This is pertinent to me because I manage firewalls...

I've seen that when Windows 7 tries to get on the network and contact a domain controller, it will try to contact not just one domain controller and not just root domain controllers or controllers for its domain. For devices that need a login that are part of a physically segmented network, I have to permit login traffic to all the enterprise domain controllers. Being a big multinational, that's a lot of domain controllers. Looking at the firewall rules, pretty much every DC has taken some hits over time, and that just blows my mind.

1. Is there a way to control Win7 clients to force them to only use particular DCs?
2. Does Windows 8 or 10 do the same thing? (XP didn't, much better behaved in that it only hit local or root for domain, that's that.)
3. Could this also be a Server 2008 thing that gets corrected in Server 2012?

[javentre]

How is your AD configured/sliced up regarding AD Sites?  Do you have subnets associated with a site?

[deanwebb]

Subnets are associated with sites, yes. But that only seems to work for the XP boxes (long live XP!). Those guys hit the local DC and, if it's too busy, go up the line to get one of the root DCs. Windows 7 boxes will just reach out on port 135 to any number of DCs, maybe 40-50 per login. It's random which ones they reach out to: a client in Texas tried to contact non-root DCs outside of its domain in places like Greece, Colombia, Australia, Japan, Germany, Brazil, and points beyond.

[javentre]

http://blogs.technet.com/b/arnaud_jumelet/archive/2010/07/11/domain-controller-locator-in-depth.aspx

It notes, at the bottom, some of the differences with newer OSs.

[RickG]

we had this problem-- the issue was in DNS. are you getting long logon times? I cleaned up our DNS and the problem went away. We had a few bad entries. Check you name server records. I have a former intern that can help out as well. he deleted the entire DNS database.

[Barlo]

Start by looking at your NETLogon.log on the DCs. Look for NO_CLIENT_SITE, just to be sure sites/clients are correct. Maybe something is off base with the site definitions or DHCP pools?

Then try: DCDiag.exe

Maybe the client is having issues talking to the local DC, and it moves on to the next available.
Can the client browse to \\YourLocalDC\ ?

Event logs on Local DC?

[JH Blunt]

From this site:  http://serverfault.com/questions/318707/force-windows-server-to-use-specific-domain-controller
"Configuring sites is of course a good start. However you should still be aware that you cannot "force" the usage of a specific DC using Sites and Services. This is by design. For example, if the DC in your site is down, Windows should try a DC in another site.

If you have a topology with a main location (such as HQ or datacenter) and remote "spoke" sites with DC's that only need to perform local authentication and other DC functions, the remote DC's can be configured to not advertise certain services by using the DnsAvoidRegisterRecords registry setting.

Also note that you can influence preference order by using the Priority and Weight of the SRV DNS records in the _msdcs subdomain, but that should only be done after a thorough analysis. Clients attempt to contact the server with the lowest priority. Weight is a load-balancing mechanism that is used when selecting a target host from those that have the same priority. Clients randomly choose SRV records that specify target hosts to be contacted, with probability proportional to the weight."

More information:

How to optimize the location of a domain controller or global catalog that resides outside of a client's site
http://support.microsoft.com/kb/306602

SRV Resource Records
http://technet.microsoft.com/en-us/library/cc961719.aspx

[JH Blunt]

Configuring Priority on a DC:
Configure the LdapSrvPriority registry setting on your domain controllers so that DC3 has the highest priority. For more info about this setting, see here:

http://technet.microsoft.com/library/cc957290

In addition you can configure the LdapSrvWeight registry setting on domain controllers to assign a weighted priority for each one:

http://technet.microsoft.com/en-us/library/cc957291

Of course, this will mean that all client computers (not just SNOOPY) will prefer DC3 for logons, and it doesn't actually guarantee DC3 will be used because if DC3 is unavailable then domain controllers with lower weighted priority will be tried in order.

[deanwebb]

Thanks for the help, gents. I'm going to do some reading, methinks... Because it's totally ridiculous to have 400+ entries in every segmentation firewall just for the domain controllers in our enterprise.