Fixing a Broken CIFS/NetBIOS Alias

After shifting CIFS duties off a Windows server and onto our NetApp SAN, we wanted to take over the name of the Windows Server and have those requests hit the SAN instead. We kept our directory structure intact, hoping that users wouldn’t need to make any changes, in order for their usual paths to still work.

Well, one alias worked just fine, and the other didn’t.

Every time I attempted to hit the broken alias via Windows Explorer on my machine, I’d see the following error on the console of my NetApp controller:

 [NetApp-SAN2:krb.kt.princ.notfound.mem:warning]: Kerberos: Did not find 
principal cifs/fas3020node01@COMPANYDOMAIN.NET in keytab. 
This is a CIFS problem.

Strange. A teammate of mine had a similar issue dealing with Kerberos, said he’d been down this path (specifically, concerning a noSQL product), and suggested checking out the “SPN”.

I also contacted NetApp Support, who suggested re-running cifs setup. Problem is, that restarts the CIFS service, and I’ve already got a lot hitting this controller via CIFS.

Then I found this KnowledgeBase article:

How to set the correct SPN for a storage controller

Scenario 1: When cifs setup was run on the storage controller, the value defined in

options dns.domainname did not match the FQDN of the domain that was

being joined.

This sounds like the path that Support is trying to pursue; but reviewing the output of the suggested commands options dns.domainname and cifs domaininfo, it appeared everything was correctly configured.

Scenario 2: When clients attempt to access the storage controller, they are using a

NetBIOS alias.

That sounds like me.

So the solution came down to using Microsoft’s SetSPN utility (now built in to Windows 2008 and beyond).

1 — Review the current configuration using setspn.exe:

setspn -l NetApp-san2
Registered ServicePrincipalNames for CN=NETAPP-SAN2,OU=San Nodes,OU=Computers,

2 — Add a record, taking that name the error message on the controller was referencing:

setspn -a cifs/ netapp-san2
Registering ServicePrincipalNames for CN=netapp-SAN2,OU=San Nodes,OU=Computers
Updated object

3 — Verify:

setspn -l walrus-san2
Registered ServicePrincipalNames for CN=WALRUS-SAN2,OU=San Nodes,OU=Computers

Then test from a Windows machine — the alias is now working!

The Microsoft SetSPN page has a lot of great, detailed information on what the ServerPrincipalName attribute in ActiveDirectory does, how it’s used, and how to administer it. This was my first time interacting with it, and using setSPN got me out of a jam, and let me use the NetBIOS Alias and AD CNAME we’d planned for decommissioning a server and taking over its name.


What would you like to say?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s