SMB shares and DNS CNAME aliases

Every corporate Active Directory (or dare I say NT...) network, even most home networks, have Microsoft Windows SMB shares lurking somewhere. SMB (Server Message Block), re branded as CIFS (Common Internet File System), is the application level protocol used primarily with file shares, but also used for print shares.

Recently I was required to move an SMB share to another server, but needed to keep the original server name the same. Seems pretty straightforward, right?

1. Create and permission the share on the new server
2. Migrate the data
3. Shutdown the old server
4. Remove the DNS host record for the old server
5. Remove (or disable) the old server object from Active Directory
7. Create a DNS CNAME alias for the old server to point to the new server
8. Test the share

After performing these steps I tried connecting to the share, and received the following obscure message:

System error 52 has occurred
A duplicate name exists on the network

Weird. I triple checked DNS records, looked for IP conflicts, file share permissions, but everything checked out. What next? Time to ask Google...

After about 15 minutes or so of research, the issue was apparent. Windows Server 2003 Service Pack 1 removed the ability to access SMB/CIFS shares via DNS CNAME aliases. By adding this 'feature', the LanmanServer service does not answer requests other then those to its NetBIOS name. So any SMB requests to its CNAME alias will be ignored and the user will receive the error message above. Microsoft have, however, made available a workaround to enable SMB/CIFS access via CNAME aliases. The following registry key must be added:

HKLM\SYSTEM\CurrentControlSet
\Services\LanmanServer\Parameters

Value name: DisableStrictNameChecking
Data type: REG_DWORD
Base: Decimal
Value data: 1

Once I applied this registry key I was able to successfully attach to the share and access the data.

I've not really found out why Microsoft introduced this with SP1 as I can't find any obvious security implications with it. If anyone has an ideas on this then please comment on this post or email me directly. Good practice, however, is to make sure your share permissions are tight. By default the Everyone group has Read access to shares as they are created, so I recommend removing this and explicitly adding the group(s) who will be accessing the share.

For more information on this, read the following Microsoft knowledgebase article:

http://support.microsoft.com/kb/281308

***NOTE: I accept no responsibility for your systems upon making any changes ***