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:
Scenario 1: When
cifs setupwas run on the storage controller, the value defined in
options dns.domainnamedid not match the FQDN of the domain that was
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
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, OU=Alpharetta,DC=CompanyDomain,DC=Net: nfs/netapp-san2.companydomain.net nfs/netapp-san2 HOST/netapp-san2.companydomain.net HOST/netapp-san2
2 — Add a record, taking that name the error message on the controller was referencing:
setspn -a cifs/fas3020node01.companydomain.net netapp-san2 Registering ServicePrincipalNames for CN=netapp-SAN2,OU=San Nodes,OU=Computers ,OU=Alpharetta,DC=companydomain,DC=Net cifs/fas3020node01.companydomain.net Updated object
3 — Verify:
setspn -l walrus-san2 Registered ServicePrincipalNames for CN=WALRUS-SAN2,OU=San Nodes,OU=Computers ,OU=Alpharetta,DC=TheNetworkInc,DC=Net: cifs/fas3020node01.thenetworkinc.net nfs/walrus-san2.thenetworkinc.net nfs/walrus-san2 HOST/walrus-san2.thenetworkinc.net HOST/walrus-san2
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.