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\
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.
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\
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You need to use the Advanced Firewall section
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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
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
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
ASKER
Thanks again Brian, But on the client? Everywhere I've read says to do it on the DC's.
ASKER
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
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.
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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_D
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\Conf
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.
nslookup
set q=SRV
_ldap._tcp.dc._msdcs.<AD_D
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\Conf
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_D
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.
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_D
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
ASKER
Thanks everyone! I learnt a lot from this experience.
ASKER