Home Forums SQL Server 2012 SQL 2012 - General Connection Failed:: The target principal name is incorrect. Cannot generate SSPI context RE: Connection Failed:: The target principal name is incorrect. Cannot generate SSPI context

  • hurricaneDBA - Wednesday, May 31, 2017 5:22 AM

    Dear MVPs
    I migrated a database from SQL Server 2008 running on windows 2008 R2 to a new SQL Server 2012 running on Windows 2012
    At first everything was working fine and when we tried to connect from SSMS on a client machine we got the error:

    Connection Failed:: The target principal name is incorrect.Cannot generate SSPI context

    The error in the SQL Server logs was:

    The SQL Server Network Interface library could not registerthe Service Principal Name (SPN) [ MSSQLSvc/SDOADP06.dolphin.co:1433 ] for theSQL Server service. Windows return code: 0x21c7, state: 15. Failure to registera SPN might cause integrated authentication to use NTLM instead of Kerberos.This is an informational message. Further action is only required if Kerberosauthentication is required by authentication policies and if the SPN has notbeen manually registered.

    Now i did lots of research and people mentioned checking for Duplicate SPNs and creating a UDL file and checking also and finally what worked for me was below.
    1. Choose the domain account user you want to use using Configuration manager and start all services you want to utilize using this account
    2. Grant them AUTH-LogAs-Service and AUTH-LogAs-Batch
    3. remove the machine from the Domain and add it again to the Domain

    Now i tried changing the service account to another domain account and the problem returned so i recommend you keep that original user unless you really have to change it then modify the user and then rejoin to the domain then it should work fine

    Have a great day
    KY

    You don't need to remove and add machines to and from the domain when changing the service account. The error you got usually is for duplicate SPNs - and often you need to clean up the duplicates for the machine itself not just the service account. And then verify the permissions so that the service can read, create SPNs - Read servicePrincipalName and Write servicePrincipalName
    If you use configuration manager to change account, the permissions are handled and you won't give permissions that aren't needed. In addition, Windows rights should be granted to the per-service SID, not the domain account. You can find those documented here in the Windows Privileges and Rights section:
    Configure Windows Service Accounts and Permissions

    Sue