Following changing the Service Account on a sql install, SCCM (System Center Configuration Manager) could no longer see it's database (fortunately, its not live yet).
The SQL log rapidly started recording these entries >
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. [CLIENT: 172.27.0.9] Error: 18456, Severity: 14, State: 11.
State 11 means ' Valid login but server access failure '. Hardly helpful.
http://technet2.microsoft.com/windowsserver/en/library/579246c8-2e32-4282-bce7-3209d1ea8bf11033.mspx?mfr=true
Ignoring (for now) the fact that the we are using windows authentication for SCCM to connect to SQL.
Multiple posts on the web suggest investigating SPNs if faced with authentication issues.
By changing the service account, SQL has attempted to register a new SPN to associate the service, machine name (FQDN form) and port number together.
To check SPNs present use >
setspn -L servername
Due to the foresight of network admins, the new service account does have rights to register an SPN. The problem now is that there are 2 SPNs for the service on the server, each using different accounts. In a nutshell, AD connections wont know which to use.
Basically, we need to remove the original SPN >
setspn -D ServiceClass/Host:Port AccountName
What I've learnt >
Changing the Service Account on a SQL box? Delete the old SPN...
No comments:
Post a Comment