Felet "Det går inte att generera SSPI-kontext" när du använder Windows-autentisering för att ansluta SQL Server

Gäller för: SQL Server
Original-KB-nummer: 811889

När du använder Windows-autentisering för att fjärransluta en SQL Server-instans får du följande felmeddelande:

Målets huvudnamn är felaktigt. Det går inte att generera SSPI-kontext

Vanliga frågor och svar

Vad är SSPI?

SSPI (Security Support Provider Interface) är en uppsättning Windows-API:er som tillåter delegering och ömsesidig autentisering över alla allmänna datatransportlager, till exempel TCP/IP-uttag. En eller flera programvarumoduler tillhandahåller de faktiska autentiseringsfunktionerna. Varje modul kallas för en SSP (Security Support Provider) och implementeras som ett DLL-bibliotek (Dynamic Link Library).

Vad är Kerberos?

Kerberos v5-protokollet är ett branschstandardsäkerhetspaket och är ett av de tre säkerhetspaketen i Windows-operativsystem. Mer information finns i Security Support Providers (SSP:er).

Vad betyder felet "Det går inte att generera SSPI-kontext"?

Det här felet innebär att SSPI försöker men inte kan använda Kerberos-autentisering för att delegera klientautentiseringsuppgifter via TCP/IP eller namngivna pipes till SQL Server. I de flesta fall orsakar ett felkonfigurerat tjänsthuvudnamn (SPN) det här felet.

Vad är SPN?

SPN (Service Principal Names) är en unik identifierare för en tjänstinstans. SPN:er används av Kerberos-autentisering för att associera en tjänstinstans med ett tjänstinloggningskonto. Med den här associationsprocessen kan ett klientprogram begära att tjänsten autentiserar ett konto, även om klienten inte har något kontonamn.

Till exempel är en typisk SPN för en server som kör en instans av SQL Server följande:

MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433

Formatet för ett SPN för en standardinstans är samma som ett SPN för en namngiven instans. Portnumret är det som binder SPN till en viss instans. Mer information om hur du registrerar SQL Server service-SPN:er finns i Registrera ett tjänsthuvudnamn för Kerberos-anslutningar.

Varför använder SSPI NTLM- eller Kerberos-autentisering?

Windows-autentisering är den bästa metoden för användare att autentisera till SQL Server. Klienter som använder Windows-autentisering autentiseras med hjälp av NTLM eller Kerberos.

När en SQL Server-klient använder integrerad säkerhet via TCP/IP-uttag till en fjärrserver som kör SQL Server använder SQL Server klientnätverksbibliotek SSPI-API:et för att utföra säkerhetsdelegering. SQL Server-nätverksklienten gör ett anrop till funktionen AcquireCredentialsHandle och skickar "negotiate" för parametern pszPackage. Den här processen meddelar den underliggande säkerhetsleverantören att förhandla delegering. I det här sammanhanget innebär "negotiate" att prova Kerberos- eller NTLM-autentisering på Windows-baserade datorer. Windows använder med andra ord Kerberos-delegering om måldatorn som kör SQL Server har ett associerat och korrekt konfigurerat SPN. Annars använder Windows NTLM-delegering. Om SQL Server-klienten ansluter lokalt på samma dator där SQL Server finns används alltid NTLM.

Varför redundansväxlar inte anslutningen till NTLM efter problem med Kerberos?

SQL Server-drivrutinskoden på klienten använder WinSock-nätverks-API:et för att matcha serverns fullständigt kvalificerade DNS när drivrutinen använder Windows-autentisering för att ansluta till SQL Server. För att utföra den här åtgärden anropar drivrutinskoden WinSock-API:erna gethostbyname och gethostbyaddr. Om integrerad säkerhet används försöker drivrutinen matcha serverns fullständigt kvalificerade DNS, även om en IP-adress eller ett värdnamn skickas som namnet på servern.

När SQL Server-drivrutinen på klienten matchar serverns fullständigt kvalificerade DNS används motsvarande DNS för att bilda SPN för servern. Därför kan problem med att matcha IP-adressen eller värdnamnet till en fullständigt kvalificerad DNS från WinSock orsaka att SQL Server-drivrutinen skapar ett ogiltigt SPN för servern.

Till exempel kan drivrutinen för SQL Server på klientsidan användas som en fullständigt kvalificerad DNS för att matcha ogiltiga SPN:er på följande sätt:

• MSSQLSvc/SQLSERVER1:1433
• MSSQLSvc/123.123.123.123:1433
• MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433
• MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433

När SQL Server-drivrutinen utgör ett ogiltigt SPN fungerar autentiseringen fortfarande, eftersom SSPI-gränssnittet försöker leta upp SPN i Active Directory-tjänsten. Om SSPI-gränssnittet inte hittar SPN utförs inte Kerberos-autentisering. Då växlar SSPI-lagret till NTLM-autentiseringsläge och inloggningen använder NTLM-autentisering och lyckas vanligtvis. Om SQL Server-drivrutinen utgör ett giltigt SPN som inte är tilldelat till lämplig container försöker drivrutinen med SPN men kan inte använda det. I det här fallet kan felet “Det går inte att generera SSPI-kontext” uppstå. Om startkontot för SQL Server är ett lokalt systemkonto är lämplig behållare datornamnet. För andra konton är lämplig behållare startkontot för SQL Server. Autentiseringen använder det första SPN som hittas, så se till att inga SPN tilldelas till felaktiga behållare. Med andra ord får varje SPN endast tilldelas till en behållare.

Hur verifierar jag anslutningens autentiseringsmetod?

Kör följande fråga för att fastställa autentiseringsmetoden för en anslutning:

SELECT net_transport, auth_scheme   
FROM sys.dm_exec_connections   
WHERE session_id = @@SPID;  

Mer information finns i Avgöra om jag är ansluten till SQL Server med Kerberos-autentisering.

Hur skapar jag SPN för SQL Server?

När en instans av SQL Server-databasmotorn startar försöker SQL Server automatiskt registrera SPN för SQL Server-tjänsten med hjälp av API:et DsWriteAccountSpn. Det här anropet lyckas om SQL Server-tjänstkontot har läs- servicePrincipalName och skrivbehörighet servicePrincipalName i Active Directory. Annars behöver du Active Directory-administratören för att manuellt registrera rätt SPN med hjälp av Microsoft Kerberos Manager för SQL Server eller det inbyggda verktyget Setspn. Mer information om hur du hanterar SPN för SQL Server finns i Registrera tjänstens huvudnamn för Kerberos-anslutningar.

Åtgärda felet med Kerberos Configuration Manager (rekommenderas)

Det finns olika orsaker till att Kerberos-anslutningar misslyckas, till exempel felkonfigurerade SPN:er, problem med namnmatchning eller otillräcklig behörighet för startkonton för SQL Server-tjänst. Microsoft Kerberos Configuration Manager (KCM) är ett verktyg som kan hjälpa dig att kontrollera orsakerna till felet. KCM tillhandahåller också alternativ för att åtgärda eventuella identifierade problem i processen.

Följ dessa steg för att åtgärda felet med hjälp av KCM.

1. På den dator där du har anslutningsproblem hämtar du och installerar Kerberos Configuration Manager.

2. Starta KerberosConfigMgr.exe från mappen %SystemDrive%:\Program\Microsoft\Kerberos Configuration Manager. Använd sedan ett domänkonto som har behörighet att ansluta till SQL Server-datorn som du inte kan ansluta till.

3. Välj Anslut och lämna servernamnet och annan information om ditt scenario tomt om du kör KCM på den SQL Server-datorn. Välj Anslut för att utföra analysen. När KCM har hämtat nödvändig information växlar den automatiskt till fliken SPN och visar som standard information för SQL Server, SQL Server Reporting Services, Analysis Services och AG-lyssnare. Om du vill felsöka det här felet avmarkerar du allt utom SQL Server.

4. Granska diagnosen från verktyget med hjälp av kolumnen Status och följ relevanta steg för att lösa problemet:

   Status	Mer information	Åtgärd
   Bra	Det markerade objektet är korrekt konfigurerat. Du kan fortsätta till nästa objekt i utdata.	Ingen åtgärd krävs
   Obligatoriskt SPN saknas	Den här statusen rapporteras när SPN som identifieras i kolumnen Obligatoriskt SPN saknas för startkontot för SQL Server i Active Directory.	1. Välj Åtgärda för att granska informationen i dialogrutan Varning. 2. Välj Ja om du vill lägga till det saknade SPN:et i Active Directory. 3. Om ditt domänkonto har de behörigheter som krävs för att uppdatera Active Directory läggs det spn som krävs till i Active Directory. 4. Om ditt domänkonto inte har nödvändiga behörigheter för att uppdatera Active Directory använder du Generera eller Generera alla för att generera skriptet som hjälper Active Directory-administratören att lägga till de saknade SPN:erna. 5. När SPN:erna har lagts till kör du Kerberos Configuration Manager igen för att kontrollera att SPN-problemen är lösta. 6. Dessutom kan du använda följande kommandon: – Använd SETSPN -Q spnName för att hitta SPN och dess aktuella konton. – Använd SETSPN -D för att ta bort SPN från det felaktiga kontot.
   TCP måste vara aktiverat för att använda Kerberos-konfiguration	Detta inträffar när TCP inte är aktiverat på klientdatorn.	Så här aktiverar du TCP/IP-protokoll för SQL Server-instansen: 1. I Konfigurationshanteraren för SQL Server går du till konsolfönstret och expanderar Nätverkskonfiguration för SQL Server. 2. I konsolfönstret väljer du Protokoll som <instansnamn>. 3. Högerklicka på TCP/IP i informationsfönstret och välj sedan Aktivera. 4. I konsolfönstret väljer du SQL Server-tjänster. 5. Högerklicka på SQL Server (<instansnamn>) i informationsfönstret och välj sedan Starta om för att stoppa och starta om SQL Server-tjänsten. Mer information finns i Aktivera eller inaktivera ett servernätverksprotokoll.
   Dynamisk port	Det här meddelandet visas för namngivna instanser som använder dynamiska portar (standardkonfiguration). I miljöer där du behöver använda Kerberos för att ansluta till SQL Server bör du ställa in den namngivna instansen på en statisk port och använda den porten när du registrerar SPN.	Så här konfigurerar du din SQL Server-instans för att använda en statisk port: 1. I Konfigurationshanteraren för SQL Server i konsolfönstret expanderar du SQL Server Nätverkskonfiguration, expanderar Protokoll för <instansnamn> och dubbelklickar sedan på TCP/IP. 2. I dialogrutan TCP/IP-egenskaper granskar du inställningen Lyssna alla på fliken Protokoll. 3. Om inställningen Lyssna alla är inställd på Ja växlar du till fliken IP-adresser och bläddrar längst ned i Windows för att hitta inställningen IPAll. Ta bort det aktuella värdet som finns i de dynamiska TCP-portarna och ange önskat värde i fältet TCP-port. Välj OK och starta om SQL Server-instansen för att inställningarna ska börja gälla. 4. Om inställningen Lyssna alla är inställd på Nej växlar du till fliken IP-adresser och kontrollerar var och en av de IP-adresser som visas i IP1, IP2. För aktiverade IP-adresser tar du bort det aktuella värdet i fältet Dynamiska TCP-portar och anger önskat värde i fältet TCP-port. Välj OK och starta om SQL Server-instansen för att inställningarna ska börja gälla. Mer information finns i Konfigurera en server att lyssna på en specifik TCP-port.
   Duplicera SPN	Du kan stöta på situationen när samma SPN registreras under olika konton i Active Directory.	1. Välj knappen Korrigera, visa informationen i dialogrutan Varning och välj Ja om du kan lägga till det saknade SPN:et i Active Directory. 2. Om ditt domänkonto har de behörigheter som krävs för att uppdatera Active Directory tas det felaktiga SPN:et bort. 3. Om ditt domänkonto inte har nödvändiga behörigheter för att uppdatera Active Directory använder du knappen Generera eller Generera alla för att generera det nödvändiga skriptet som du kan lämna över till Active Directory-administratören för att ta bort de duplicerade SPN:erna. När SPN:erna har tagits bort kör du KCM igen för att kontrollera att SPN-problemen är lösta.

   Obs!

   Om domänkontot som startar KCM inte har behörighet att ändra SPN i Active Directory kan du använda den motsvarande knappen Generera eller knappen Generera alla under kolumnen SPN-skript för att generera de kommandon som krävs och arbeta med Active Directory-administratören för att åtgärda de problem som identifieras av KCM.

5. När du har åtgärdat alla problem som identifierats i KCM kör du verktyget igen. Kontrollera att inga andra problem rapporteras och försök sedan ansluta igen. Om verktyget fortfarande rapporterar problem upprepar du föregående procedur.

Åtgärda felet utan Kerberos Configuration Manager

Om du inte kan använda KCM följer du dessa steg:

Steg 1: Kontrollera namnmatchningen med pingkommandot

Nyckelfaktorn som gör att Kerberos-autentiseringen fungerar är de giltiga DNS-funktionerna i nätverket. Du kan kontrollera den här funktionen på klienten och servern med hjälp av kommandotolken Ping. Kör följande kommando på klientdatorn för att hämta IP-adressen för den server som kör SQL Server (där namnet på datorn är SQLServer1):

ping sqlserver1

Kör följande kommando för att se om ping-verktyget löser den fullständigt kvalificerade DNS:en SQLServer1 för:

ping -a <IPAddress>

Till exempel:

C:\>ping SQLSERVER1

Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128

Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms 
C:\>ping -a 123.123.123.123

Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

C:\> 

När kommandot ping -a <IPAddress> matchas till rätt fullständigt kvalificerad DNS för den dator som kör SQL Server, lyckas även lösningen på klientsidan.

För detaljerad diagnostik använder du antingen cmdleten Test-NetConnection eller Test-Connection för att testa TCP-anslutningen enligt den PowerShell-version som är installerad på datorn. Mer information om denna PowerShell-cmdlet finns i Översikt över Cmdlet.

Kontrollera om det finns några alias för målet SQL Server i Konfigurationshanteraren för SQL Server och i verktyget SQL Server klientnätverk. Om det finns ett sådant alias kontrollerar du att det är korrekt konfigurerat genom att kontrollera servernamn, nätverksprotokoll, portnummer och så vidare. Ett SQL Server-alias kan orsaka att ett oväntat SPN genereras. Detta resulterar i NTLM-autentiseringsuppgifter om SPN inte hittas, eller ett SSPI-fel, om det oavsiktligt matchar SPN för en annan server.

Steg 2: Verifiera kommunikationen mellan domäner

Kontrollera att domänen som du loggar in på kan kommunicera med domänen för den server som kör SQL Server. Det måste också finnas rätt namnmatchning i domänen.

1. Se till att du kan logga in i Windows med samma domänkonto och lösenord som startkontot för SQL Server-tjänst. SSPI-felet kan till exempel inträffa i någon av följande situationer:

   • Domänkontot är utelåst.
   • Du startade inte om SQL Server-tjänsten efter att lösenordet för kontot ändrades.

2. Om din inloggningsdomän skiljer sig från domänen för den server som kör SQL Server kontrollerar du förtroenderelationen mellan domänerna.

3. Kontrollera om domänen som servern tillhör och domänkontot som du använder för att ansluta finns i samma skog. Det här steget krävs för att SSPI ska fungera.

Steg 3: Verifiera SQL Server SPN:er med hjälp av SQLCHECK- och Setspn-verktyg

Om du kan logga in lokalt på SQL Server dator och ha administratörsåtkomst använder du SQLCHECK. SQLCheck innehåller det mesta av den information som krävs för felsökning i en fil. Mer information om hur du använder verktyget och vilken information det samlar in finns på verktygets startsida. Du kan också kontrollera de rekommenderade förutsättningarna och checklistsidan. När du har genererat utdatafilen granskar du SPN-konfigurationen för din SQL Server-instans under avsnittet SQL Server Information i utdatafilen.

Exempel på utdata:

Suggested SPN                                               Exists  Status              

----------------------------------------------------------  ------  ------------------- 

MSSQLSvc/testsqlsvr.corp.com:2000                           True    Okay                

MSSQLSvc/testsqlsvr.corp.com                                True    Okay                

MSSQLSvc/testsqlsvr:2000                                    False   SPN does not exist. 

MSSQLSvc/testsqlsvr                                         False   SPN does not exist. 

Använd utdata ovan för att fastställa nästa steg (se exemplen nedan) och använd Setspn-verktyget för att vidta nödvändiga åtgärder för att åtgärda SPN-problem.

Steg 4: kontrollera kontobehörighet för SQL Servers startkonto på länkad server

Om du använder Personifiera som autentiseringsalternativ på sidan Säkerhet på den länkade servern krävs SQL Server för att skicka inkommande autentiseringsuppgifter till fjärr-SQL Server. Det SQL Server-startkonto där den länkade servern har definierats bör ha kontot betrott för delegeringsbehörighet som tilldelats till den i Active Directory. Mer information finns i Aktivera att dator- och användarkonton är betrodda för delegering.

Se även

• Felsöka anslutningsproblem i SQL Server
• Felsöka problem med konsekvent autentisering
• SSPI-klientverktyg
• Aktivera Kerberos-händelseloggning
• Så här tvingar du Kerberos att använda TCP i stället för UDP i Windows