Before I log this out with Microsoft, would anyone happen to know whether use of SPN’s on named SQL Instances is bad practice from a Kerberos perspective?
We had a SCOM issue earlier today whereby all of our local & mgmt server consoles stopped working. We then discovred that the SQL application logs were full of this error: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: 172.xx.xx.xxx]
I then put my Sherlock cap on and discovered that one of my SPN's for the SQL Service had been deregistered: The SQL Server Network Interface library successfully deregistered the Service Principal Name (SPN) [ MSSQLSvc/DC1-SCOMDB.live.co-op.local:52809 ] for the SQL Server service.
After re-registering the SPN my environment sprung back into life.
I just read some comments in a TechNet article that suggest Kerberos does not like SPN’s associated with named SQL instances, and so it falls back to NTLM. So in summary......
We have question marks over this config:
MSSQLSVC/ServerName:InstanceName domain\account
MSSQLSVC/FQDN:InstanceName domain\account
And was wondering whether we should we be using a config similar to this instead:
MSSQLSVC/ServerName:PortNumber domain\account
MSSQLSVC/FQDN:PortNumber domain\account