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.
DonKwizoteAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Shaun VermaakTechnical Specialist/DeveloperCommented:
If temporary, add a Firewall block Any -> Faulty DC in the Windows Firewall configuration
1
Cliff GaliherCommented:
If the DC is truly faulty, take it our of commission. Trying to "fix" this on the client side is a fool's errand.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
DonKwizoteAuthor Commented:
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
0
Challenges in Government Cyber Security

Has cyber security been a challenge in your government organization? Are you looking to improve your government's network security? Learn more about how to improve your government organization's security by viewing our on-demand webinar!

Shaun VermaakTechnical Specialist/DeveloperCommented:
You need to use the Advanced Firewall section
0
SilverwolfSenior Server EngineerCommented:
One option would be to set up another site, and set the faulty DC in that site.
0
MaheshArchitectCommented:
why can't you demote 2008 R2 Dc and promote it again with new hostname?

if you unable to demote, shut it down, take out of network and do meta data cleanup and promote new DC with new hostname

3. Edited the SRV entry (_keberos and _ldap) in DNS on the DC's and restarted the netlogon service and the dns service
This is the wrong way of altering srv records

if you are trying to set registry on DCs, they should be able to replicate with each other the changes in SRV, else it won't work
0
Brian MurphyIT ArchitectCommented:
What about the LDAPSrvWeight?  You mentioned the priority but if memory serves you must change both.

Or in this case you might have to actually create the DWORD values first under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters

The defaults 0 and 100

So you would change Priority to 100 and Weight of 0

Just flip the two #'s

Then restart Netlogon
1
DonKwizoteAuthor Commented:
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.
0
Brian MurphyIT ArchitectCommented:
Also, those are client side settings not domain controller...

Forgot to mention that
0
Brian MurphyIT ArchitectCommented:
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
0
DonKwizoteAuthor Commented:
Thanks again Brian, But on the client? Everywhere I've read says to do it on the DC's.
0
DonKwizoteAuthor Commented:
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
0
Brian MurphyIT ArchitectCommented:
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.
1
Brian MurphyIT ArchitectCommented:
I found this which explains better.  The reason you make the change on the client and the Netlogon service on that client is the only place that change would matter.  Netlogon does a lookup to find a DC and that is a client side function.  All this change does is override the default values set by the DC's.  

http://www.miru.ch/how-to-control-and-prioritize-client-authentication-and-logon-requests-on-domain-controllers/
1
DonKwizoteAuthor Commented:
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.
0
Brian MurphyIT ArchitectCommented:
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.
0
Brian MurphyIT ArchitectCommented:
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.
0
MaheshArchitectCommented:
The priority / weight whatever settings you are doing it on domain controller side and not with client side

If you understand client auth process in domain, client will ask DNS server for srv records, according to your srv priority / weight servicing DC is allocated to clients

Also you either set weight or priority, not the both, by setting both conditions you are forcing DC to evaluate both conditions

DC with high weight value will receive maximum requests
OR
DC with low priority value will get maximum requests

I suspect, the changes you made in srv weight or priority are not getting replicated to all DCs and hence its not working, because DCs in same site should have updated values for SRV for all servers in that site to make decision

Mahesh.
1
Cliff GaliherCommented:
Mahesh is correct, and that was actually my point earlier. If a DC itself is misbehaving, it'll give bad data to clients authenticating to it, and clients have no reason to look at another DC, and won't see the workarounds you are trying to implement. The *only* reliable fix is to get the DC and its bad data off the domain.

To be blunt, removing a DC, cleaning up metadata, and setting up a new DC could've been done already with the time invested here writing about bad workarounds. The whole affair is a half-hour of work.
0
DonKwizoteAuthor Commented:
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.
0
DonKwizoteAuthor Commented:
Thanks everyone! I learnt a lot from this experience.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
DNS

From novice to tech pro — start learning today.