- Disable strict name checking with PowerShell - Mon, Sep 1 2014
- ManageEngine Exchange Reporter Plus review - Wed, Aug 20 2014
- EventSentry – Full-spectrum monitoring - Thu, Jul 17 2014
Unfortunately, this security enhancement can cause issues when replacing servers during an upgrade or a disaster recovery situation. For one, it can cause old shortcuts to break and SQL server instances to become unresponsive. It’s not enough to just create a CNAME on your DNS server. You must disable strict name checking to allow the server to respond using a different name.
Errors and symptoms
Strict name checking affects every server platform since Windows Server 2000. You may receive a few different error messages that can help you determine if strict name checking is actually causing your issues.
The first and most obvious problem will be that you can’t connect to the CNAME alias for things such as file services. You will be able to ping and even RDP into the machine; after all, you only need the IP address to perform these functions.
Other error messages may include:
- Access Denied
- System error 52 has occurred. A duplicate name exists on the network.
- No network provider accepted the given network path.
How to disable strict name checking
The process of disabling strict name checking and allowing the server to respond using a different name is fairly straightforward. However, to get things working 100 percent, several steps must be performed.
Add the CNAME record to your DNS server
First, you will need to create a CNAME record with the alias of the server you would like to respond to the name. For example, if the new server name is SRVFILES02 and you want the server to also respond using the old computer name FILESERVER, you will need to create a CNAME record that points FILESERVER to SRVFILES02.
Enable Local security authority for NTLM authentication requests
The next step we need to take is to add the host names so they can respond to NTLM authentication requests. To accomplish this, do the following:
- Navigate to HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
- Under Lsa, add New->DWORD.
- Name the new entry “DisableLoopbackCheck” and set the value to 1.
- Go to HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0.
- Right-click MSV1_0 and select New->Multi-String Value.
- Type “BackConnectionHostNames” as the name and press Enter.
- Right-click the newly created entry and select Modify.
- Add the alias and FQDN to the entry, one per line, and click OK.
Add the alias and FQDN, one per line, in BackConnectionHostNames.
Note: If the registry key already exists, delete it and re-create it as outlined above.
Add the SPN records for Kerberos authentication
Just as we allowed NTLM authentication for the new alias, we will also need to add the SPN records. Do the following:
- Open a command prompt with administrative privileges.
- Type “setspn -A host/<old_server_name> <new_server_name>” and press Enter.
setspn -A command
Provide browsing capabilities for multiple NetBIOS names
Now, we must add another registry entry to allow NetBIOS browsing of the alias name, as follows:
- Navigate to HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters.
- Right-click Parameters and select New->Multi-String Value.
- Name the new entry “OptionalNames.”
- Add only the alias name, not the FQDN, to the new entry and click OK.
OptionalNames registry dialog box
Disable strict name checking
Finally, we will move on to the last step and the most important piece of this puzzle: disabling strict name checking. Do the following:
- In your registry editor, go to HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters.
- Right-click and add the DWORD entry “DisableStrictNameChecking” and set the value to 1.
- Right-click again and add the DWORD entry “DnsOnWire” with a value of 1.
- Restart the server.
DisableStrictNameChecking and DnsOnWire registry entries
Automated PowerShell script
To quickly accomplish this task, I have put together a small PowerShell script that will perform all of the actions above. Change the “<old_host_name>” parameter to the alias name you would like to use, and then just copy and paste it into a PowerShell prompt running with admin privileges.
$altNames = @("<old_host_name>","<old_host_name>.domain.local") $hostName = hostname New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Name DisableLoopbackCheck -PropertyType DWord -Value 1 New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 -Name BackConnectionHostNames -PropertyType MultiString -Value $altNames New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters -Name OptionalNames -PropertyType MultiString -Value $altNames New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters -Name DisableStrictNameChecking -PropertyType DWord -Value 1 New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters -Name DnsOnWire -PropertyType DWord -Value 1 setspn -A host/$altNames $hostname
After a reboot, your new server will respond as the server it replaced.
Being able to have a new server respond using the name of the old one it replaced is invaluable in today’s ever-changing landscape. Doing so affords us, as administrators, more time to update shortcuts and services and slows the onslaught of user issues resulting from the upgrade. Armed with this information and the short script, you can easily replace your old servers without the headaches that come with changing server names.
Join the 4sysops PowerShell group!
Your question was not answered? Ask in the PowerShell forum!
I suppose that this approach can also be used when changing a server’s name when maintaining connectivity to the old name is needed?
Yes. This will allow the server to keep responding as its old name also.
I think the DnsonWire registry key is supposed to go under HKLM\SYSTEM\CurrentControlSet\Control\Print and not under Lanman\Parameters.
Hi Nick. Thanks for reading and thanks for the input! However, the DnsOnWire entry needs to be in HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters with the DisableStrictNameChecking and OptionalNames entries. This is where all of the LAN Management parameters are stored.
Just wanted to say, “Thank you”. Migrated an SQL server which then caused SSPI errors and this resolved the issue since the new server wasn’t authenticating users correctly due to them connecting to it via the old server name.
According to https://support.microsoft.com/en-us/kb/979602, Nick is correct:
reg add HKLM\SYSTEM\CurrentControlSet\Control\Print /v DnsOnWire /t REG_DWORD /d 1
This article is wrong. You should be using BackConnectionHostNames or DisableLoopbackCheck, not both. If DisableLoopbackCheck is set to 1 BackConnectionHostNames is completely ignored and all hostnames are allowed to be used for loopback. Of the two, BackConnectionHostNames is the preferred method per Microsoft KB896861.
Does the old computer account name have to be deleted from AD for this to work?
This procedure worked great on old 2008R2 servers but wasn't working on 2012r2 until I deleted the old computer name from the active directory "computers" folder.
On the script replace:
setspn -A host/$altNames $hostname
setspn -A host/$($altNames) $hostname
As is it seems to expand the array causing the command to be:
setspn -A host/<old_server_name> <old_host_name>.domain.local <new_server_name>
Instead of the intent:
setspn -A host/<old_server_name> <new_server_name>
I would also add beyond the prerequisite to add a CNAME record you should also ensure that the old_server_name has been removed from the domain. Otherwise you will receive a "Duplicate SPN found" error. when trying to update the record. So either remove it or use ADSI edit on the old systems object to update it.
Thanks for putting this article/script together! I have just used it to retire an old SBS2011 box!
I guess I should I clean up any DNS records pointing to the old server after shutting it down, correct?
I can only agree to James. Not only reading but also understanding is such an important skill this days – and don't do security-related stuff in a hurry just to fix things.
You EITHER disable loopback checking (WORST) OR define the legitimate host names (BackConnectionHostNames).
And the CNAME stuff is the (legitimate) cause, not the solution; if you have to access your file server under a different name for whatever reason then CNAMEs ensure that Kerberos doesn't break. If you do this via A records then you also need to cater for the new SPNs which is not need for CNAMEs. And that's what the security feature is about, detecting access under a different name than the hostname which may indicate malicious activity.