Link to home
Create AccountLog in
Avatar of DonKwizote
DonKwizoteFlag for United Kingdom of Great Britain and Northern Ireland

asked on

Force Windows clients to authenticate to a specific domain controller

Hi Everyone,
I have already found tons of information on how to do this but none of them work. I need our PC's to authenticate to a specific domain controller because the DC that some clients are connecting to, does not work properly.

Good DC - Windows 2003 (Yes, I know it is old)
Faulty DC - Windows 2008 R2.

This is what have I tried
1. Added SiteName (preferred domain controller) to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters on the PC
2. Added <ipadress> <preferred DC> #PRE #DOM:<domain name> to LMHOSTS file on PC
3. Edited the SRV entry (_keberos and _ldap) in DNS on the DC's and restarted the netlogon service and the dns service
4. Added the PC's subnet to AD Sites and Services
5. Edited the registry on the domain controllers. Edited LdapSrvPriority and set to 0 on the preferred DC and 200 for the faulty DC

Yet despite all of these, a PC still points to the faulty PC.
SOLUTION
Avatar of Shaun Vermaak
Shaun Vermaak
Flag of Australia image

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
ASKER CERTIFIED SOLUTION
Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
Avatar of DonKwizote

ASKER

Shaun, that's an interesting idea. I'm looking through the Windows firewall but I don't see a way to block a specific ip address or computername
You need to use the Advanced Firewall section
SOLUTION
Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
SOLUTION
Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
SOLUTION
Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
Thanks Everyone
Brian, I read that the Priority takes precedence over the weight. The weight applies only if they have the same priority. I'll take another look.
Also, those are client side settings not domain controller...

Forgot to mention that
No really.  And the setting is on the client not AD Controller.

If you want to assure it does not use that controller you flip the #'s

The priority works by lower # better

The weight is opposite.

If you leave the defaults then it is the combination of the two combined.  

If you have two DC's and both have priority of 10 and weight of 100 and change one to priority 0 there are many scenarios from FSMO roles to Global Catalog and other things that could cause you to hit that server.

The only way I am aware of taking it out of the equation is Priority 100 and Weight 0.

On the clients/workstations.

So if you have a lot of clients you would push this change out to all of them
Thanks again Brian, But on the client? Everywhere I've read says to do it on the DC's.
I went for the maximum and minimum values possible to make sure the PC selected DC1 but it doesn't

DC1 -  LDAPSrvPriorityt is 0, LDAPSrvWeight is 0
DC2 - LDAPSrvPriority is 65335 and LDAPSrvWeight is 65335

So the PC should select DC1, right? It still selects DC2
I don't recall the ranges allowed but if you keep it simple and just change priority to 100 and weight to 0  - I know that worked for me which was a long time back but I remember others attempting playing around with those #'s and all it took was flipping the defaults

100 and Zero

Restart Netlogon

There might be other steps I'm missing to flush out existing but I would start with that and then logoff and log back on.

And I would remove any changes you made prior.  Like lmosts or anything so we give this a fair chance.

If this doesn't work then it we need to look at nltest and other CMD tools to give us more information.
SOLUTION
Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
Higher value means a lower preference
In the registry of the DC that I DON'T want to be authenticated on, I have set the LDAPSrvPriority to 100 and LDAPSrvWeight to 100.
In the registry of the DC that I DO want to be authenticated on, I have set the LDAPSrvPriority to 0 and LDAPSrvWeight to 0.

The client still points to the DC I don't want to be authenticated on.
Confirm that changes are applying at this point.

nslookup
set q=SRV
_ldap._tcp.dc._msdcs.<AD_DS_domain_name>

You should see the DC names and the priority and weights

If not, you might need NLTest for that version of OS but basically you enable Netlogon debug which writes to a netlogon.log file.

You cannot modify the DNS records manually but you can modify the netlogon.dns file manually.

The Netlogon.dns file is located at %systemroot%\System32\Config\Netlogon.dns.

I know this works but have not tried it with this scenario where you have 2003 DC and 2008 DC, either way you are running 2003 domain and forest functional level.

Authentication is either Netlogon and DNS or legacy WINS.
Setting both values is not recommended.  You don't have to change any value other than the one for the DC you don't want to be used.

Set the Priority to 100, and Weight to 0

Whether by registry or netlogon.dns file

Restart Netlogon

Validate

nslookup
set q=SRV
_ldap._tcp.dc._msdcs.<AD_DS_domain_name>

All your doing is updating the SRV record by making a registry change by way of Netlogon to DNS.

This might require in some cases deleting those records from the msdcs zone first, then make the registry change.

At this point we need to validate that what your doing is taking effect.  

If the SRV records don't reflect the change then simply turning on debug for netlogon should show where this failure is happening when you restart netlogon.  Or, you might just need to delete the default value.  You can change it manually but it won't stay that way.
SOLUTION
Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
SOLUTION
Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
Thanks EVERYONE!
It was a battle trying to accomplish my original aim. I couldn't get it working in a production environment but it worked in a lab environment. After many stressful hours, we decided to throw in the towel and installed a new domain controller for the production side as staff were being affected. I'll assign points to all solutions that helped in my lab environment.
Thanks everyone! I learnt a lot from this experience.