Cannot generate SSPI context

  • Our data center was recently moved.  The development servers were moved to a virtualized environment using Ghost to copy the server from the old location to the new location.  Ever since the migration our virtualized development and test servers have been generating the error "Cannot generate SSPI context" when we try to connect using NT Authentication.  When I switch the client to Named Pipes instead of TCP\IP, as specified by a Microsoft workaround, the NT authentication works without problem.   Only the default instances are failing.  The named instances on these virtualized servers work as expected.

    Could this problem be related to VMWare or Ghost?  The consulting company who performed the migration said they verified the SPN does exist.  Any suggestions.

    Thanks,  Dave

  • Are you using the same IP addresses? Could be a DNS problem. Can you have the domain administrator re-register the server? Two years ago, I had to rename the SQL Servers to reflect new naming conventions for servers in our domain. The old DNS entries had remained for some reason, causing the "Cannot generate SSPI context" problem. After the admin cleanup up the DNS servers and Active Directory, the problem was solved.

  • I've had this problen quite frequently lately (ughh...)

    First thing you need to do is download the setspn utility (link below):

    http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/setspn-o.asp

    Install it on your computer (or server). Next you'll need a Domain Admin account to use (unless you are a Domain Admin you cannot use setspn for this type of AD updates). Open up a DOS command window change directory to C:\Program Files\Resource Kit (the setspn installation default directory).

    Then enter the following comand:

     setspn -L servername

    Your results may look something like this:

         MSSQLSvc/servername.xxx.organization.org:1433

         HOST/servername

         HOST/servername.xxx.organization.org

    Next enter the following commands:

     setspn -D MSSQLSvc/servername.xxx.organization.org servername

     setspn -D HOST/servername servername

     setspn -D HOST/servername.xxx.organization.org servername

    Now things shoud be OK.

    RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."

  • I ran into one of these two days ago and I don't think microsoft itself can pin point the cause without seeing the error code, based on what I read online. What I mean is there could be multiple possible causes.

    In my case, there was no domain at all. All servers are in a workgroup environment.

    I saw the following errors in OS event log when I got this error:

    MRXSMB: event 3034: the redirector was unable to initialize security context or query context

    LSASRV: evetn 5000: The security package Negotiate generated an exception. The package is now disabled. The exception information is the data.

    Reapplying W2K SP4 fixed all three problems on the client server (as opposed to the DB server).

  • Rudy-

    I am running MSDE on the server and clients are getting the SSPI message.

    Could it be caused by a vpn entry called the same as the server? Maybe this is causing the clients to get confused which server1 to connect to? i.e. server1.corpxyz.com has two ip address 1-NIC 2-VPN.

    Shouldn't there be at least ONE MSSQLSvc & HOST settings on the server? Or does this get re-created when sql server starts up again?

    Should ALL HOST entries be deleted??

    Results of the setspn -l

    Registered ServicePrincipalNames for CN=SERVER1,OU=Domain Controllers,DC=corpxyz,DC=com:

        MSSQLSvc/server1.corpxyz.com:56183

        SMTPSVC/SERVER1

        SMTPSVC/server1.corpxyz.com

        GC/server1.corpxyz.com/corpxyz.com

        HOST/server1.corpxyz.com/CORPXYZ

        HOST/SERVER1

        HOST/server1.corpxyz.com

        HOST/server1.corpxyz.com/corpxyz.com

        E3514235-4B06-11D1-AB04-00C04FC2DCD2/b2c19f14-969e-48f6-8134-e32043a38579/corpxyz.com

        LDAP/b2c19f14-969e-48f6-8134-e32043a38579._msdcs.corpxyz.com

        LDAP/server1.corpxyz.com/CORPXYZ

        LDAP/SERVER1

        LDAP/server1.corpxyz.com

        LDAP/server1.corpxyz.com/corpxyz.com

        NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/server1.corpxyz.com

        DNS/server1.corpxyz.com

  • I'm wondering if it was a dns issue or delegation issue. I found the dsl router installed two months ago was running dhcp. So I turned that off. Then added the www as a forward so we can use internal dns resolution on the server vs. pointing to our isp for dns resolution.

    I also read in one kb article about delegation & trust. All the laptops have local signon. So I also opened up the trust on two of the laptops to see if this helps the problem or if it is not necessary:

    AD>Computers>right click computerABC>properties> General TAB>check "Trust computer for delegation"

    Any comments on the setspn list above or some of my troubleshooting???

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply