none
Not able to connect to SQL Server - SPN Issue

    Question

  • I am getting the following same error meessage

     

    "The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies."

     

    I am using Windows 2008 server with SQL Server 2008. I tried to run the SQL Server service with local account that doesnt work. Then i made that account to local admin, doesnt work either. Then i use the domain user, doesnt work. Then i thought of removing this server from the domain, delete the entry for this server from the AD and then join the server back into the domain. This is make sure that AD issue is not there. this also doesnt solve the prob.

     

    I got couple of links on the different blogs on this error and none of them have specific answers to this problem. If anyone from the MS can also reply on this, would be greatly appreciated.

     

     

    Regards

    Prashant Thakwani

     

    Monday, December 08, 2008 3:57 PM

Answers

  • This is resolved. Thanks to all who responded.

    In my reseach, i got to know that this failure often is caused by a system or domain policy removing the SeDebugPrivelege security privilege from the administrator account running setup. Verify that the account running has this privilege.

    The AccessChk tool will print all privleges for an account (http://technet.microsoft.com/en-us/sysinternals/bb664922.aspx) by running:
    accesschk.exe -a <Domain>\<Account> *

    Alternatively, we can check this through your group policy editor as mentioned below:

    Open Group Policy...
     Start | Run | Type: gpedit.msc | OK |
    Navigate to
     Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Debug programs

    The account through which we are trying to run the setup should be here ( besides the local admin on that machine). I included that here, restarted the server ( this is mandatory, gpupdate /force will not work) and ran the setup and it was successful this time.

    SQL Server 2008 setup needs this privilege to start up the SQL Server process and listen to an event that signals back to setup that SQL Server successfully started.

    Thursday, December 18, 2008 8:36 PM

All replies

  • Have a look at the following blog posts by Kendal Van Dyke and see if it helps solve your problem:

    Saturday, December 13, 2008 5:45 AM
  • That message is technically a warning, not an error.  It is only warning you Kerberos/delegation is not setup.

    Are you actually have a problem connecting to the SQL Server?
    Monday, December 15, 2008 3:27 PM
  • I think you might have to set SPN for the SQL service account (not local system) using setspn.exe utility. The below post might help you,
    http://blogs.msdn.com/sql_protocols/archive/2005/10/15/481297.aspx

    - Deepak

    Deepak | Mark the answers if it helps to solve your problem |
    Monday, December 15, 2008 4:23 PM
  • Thanks Deepak. But i tried to setup SPN for the SQL Service account but still the problem persists. I am still expecting the answer to get this corrected.

    Regards
    Prashant Thakwani
    Wednesday, December 17, 2008 6:12 PM
  •  Yes Tom. I am not able to connect to SQL Server. I tried to see the multiple Logs and found this into the SQL Server ErrorLog. 

    As mentioned in my last post, i have tried setting the SPN for the account through which i am running the SQL Server, but no luck. I am still looking for an answer on this.


    Regards
    Prashant Thakwani
    Wednesday, December 17, 2008 6:15 PM
  • Jon, Pls see my reply to Tom and Deepak.

    Regards,
    Prashant Thakwani

    Wednesday, December 17, 2008 6:16 PM
  • Again, this warning is a generic warning meaning delegation/Kerberos is not setup properly.  It may not be related to the SPN.  The SPN is created automatically when the service starts, you normally do not need to do anything.

    Are you running on multiple domains?  Are you a sysadmin of the SQL Server and Domain Admin of all domains?


    Setting up delegation can be tricky.  The link above http://kendalvandyke.blogspot.com/2008/11/delegation-what-it-is-and-how-to-set-it.html gives information on how to set it up.  You will also need to use a domain login for the SQL service.
    Thursday, December 18, 2008 2:35 PM
  • This is resolved. Thanks to all who responded.

    In my reseach, i got to know that this failure often is caused by a system or domain policy removing the SeDebugPrivelege security privilege from the administrator account running setup. Verify that the account running has this privilege.

    The AccessChk tool will print all privleges for an account (http://technet.microsoft.com/en-us/sysinternals/bb664922.aspx) by running:
    accesschk.exe -a <Domain>\<Account> *

    Alternatively, we can check this through your group policy editor as mentioned below:

    Open Group Policy...
     Start | Run | Type: gpedit.msc | OK |
    Navigate to
     Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Debug programs

    The account through which we are trying to run the setup should be here ( besides the local admin on that machine). I included that here, restarted the server ( this is mandatory, gpupdate /force will not work) and ran the setup and it was successful this time.

    SQL Server 2008 setup needs this privilege to start up the SQL Server process and listen to an event that signals back to setup that SQL Server successfully started.

    Thursday, December 18, 2008 8:36 PM
  • Prashant,

    I am having a simular possible issue.  I am getting the message:

    Message
    The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0xd, state: 13. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.

    This message seems to indicate some kinde of problem.  However I can connect to the server from remote clients using KERBEROS.  The below query returns KERBEROS auth.

    select auth_scheme from sys.dm_exec_connections where session_id=@@spid


    The error message says it MAY cause authentication to fail back to NTLM.  In my case at least, it does not appear to be falling back to NTLM.  I just want to make sure this is not going to cause some kind of problem down the road.  Is there any way to get more info on this?

     

    -scott

    Wednesday, June 08, 2011 1:57 PM
  • Oh, one more thing. Its in a cluster.  A simple reinstall is not really an option.  Is there there any way to fix without reinstall?

     

    -scott

    Wednesday, June 08, 2011 1:58 PM
  • I want to clarify:

    SELECT
    s.login_name , c.protocol_type , c.auth_scheme , s.HOST_NAME, s.program_name
    FROM sys.dm_exec_sessions s
    JOIN sys.dm_exec_connections c
    ON s.session_id = c.session_id

    produces:

    NT AUTHORITY\SYSTEM TSQL NTLM NODE10 Microsoft® Windows® Operating System
    Domain\user TSQL NTLM NODE10 Microsoft SQL Server Management Studio
    Domain\user TSQL NTLM NODE10 Microsoft SQL Server Management Studio - Query
    Domain\user TSQL NTLM NODE10 Microsoft SQL Server Management Studio - Query
    Domain\SQLServiceAccount TSQL NTLM CLUSTERSQLHOST SQLAgent - Job invocation engine
    Domain\SQLServiceAccount TSQL NTLM CLUSTERSQLHOST SQLAgent - Generic Refresher
    Domain\user TSQL KERBEROS CLIENT Microsoft SQL Server Management Studio
    Domain\user TSQL KERBEROS CLIENT Microsoft SQL Server Management Studio
    Domain\user TSQL KERBEROS CLIENT Microsoft SQL Server Management Studio - Query 

    Node10 is cluster node with the SQL resources.

    Any ideas?

    -scott

    Wednesday, June 08, 2011 2:12 PM
  • This message is a "warning" indicating the SQL Server service account is not able to create the SPN automatically.  This is not normally an issue.  You can still create the SPN manually, or it may already exist if you ran the installation as a "domain admin" user.

    This, by itself, does not indicate an problem.  Are you having a problem?

    Wednesday, June 08, 2011 3:49 PM
  • I am guided to this from a Access 2008 application using SQL Native Client 10

    The Microsoft SQL Server DSN Configuration on my other SQL Servers 2008 R2 allwo me to select the SQLServerName fom the list box and make a connection.

    One SQL Server will not connect. If the servr name is manually selected to  ServerName\SqLServerName - then the ODBC connection will work.

    The Microsoft MS Access 2010 application uses a programmed DSN-Less connection string for the SQL Native Client 10

    The application runs from any Windows 7 desktop just fine - launching the same exact file located on our Citrix Server. Makes a connection first time.

    But, on the Windows 2008 Citrix Server - the first time - times out. If the user immediately loggs off of the ODBC timeout error, and re-launches Citrix - it connects. If the user waits 15 seconds and then launches a 2nd time, it times out like the first time.

    Web links keep pointing back to the SPN - a warning error in SQL.


    Rx

    Monday, May 07, 2012 5:54 PM