Dela via


Tillfälliga eller periodiska autentiseringsproblem i SQL Server

Kommentar

Innan du börjar felsöka rekommenderar vi att du kontrollerar förutsättningarna och går igenom checklistan. Mer information finns i Självhjälpsartiklar.

Den här artikeln beskriver vanliga orsaker till tillfälliga autentiseringsproblem i SQL Server-anslutning och tillhandahåller lösningar.

Symptom

Tillfälliga eller periodiska autentiseringsproblem i SQL Server-anslutningen uppstår när användare eller program har sporadiska problem med att autentisera med SQL Server-databasen. Detta orsakar störningar i dataåtkomst och programfunktioner.

De vanligaste felmeddelandena

  • Det går inte att generera SSPI-kontext

  • Inloggningen misslyckades för användaren

    • Inloggning misslyckades för användaren ''
    • Inloggningen misslyckades för användaren NT AUTHORITY\ANONYMOUS LOGON
    • Inloggningen misslyckades för användaren "<UserName>"
    • Inloggningen misslyckades för användaren "<Domain>\<UserName>"
    • Det gick inte att logga in. Inloggningen kommer från en domän som inte är betrodd och kan inte användas med Windows-autentisering.

Orsak

De vanligaste problemen orsakas av SQL Server-prestanda eller långsamma domänkontrollantsvar. Om du använder NT LAN Manager (NTLM) har LSASS (Local Security Authority Subsystem Service) en flaskhals och begränsar hur många nya anslutningar som kan bearbetas samtidigt. Andra begäranden säkerhetskopieras och kan överskrida tidsgränsen. Vissa orsaker, till exempel antivirusprogram, kan vara svåra att bevisa, men är fortfarande vanliga och bör undersökas även utan hårda bevis om andra undersökningsvägar är ineffektiva.

Felsökningsprocess

Eftersom problemet är tillfälligt är det troligt att konfigurationen, till exempel Kerberos Service Principal Names (SPN), är korrekt. Lös problemet genom att prova följande felsökningssteg:

Skillnad i svarstid mellan flera domäner eller datacenter

Om flera domäner eller datacenter är inblandade kontrollerar du om användarna i den lokala domänen eller datacentret inte upplever problemet medan användare i andra domäner eller datacenter gör det. I så fall kan det tyda på en kommunikationssvarstid mellan datacenter eller domänkontrollanter. Använd följande kommandon för att undersöka problemet:

  • Om du vill kontrollera nätverksfördröjningen använder du ping. Till exempel:

    1. Kör kommandot: ping <DatabaseServer>.

    2. Titta på tidskolumnen och jämför den tiden med den i den andra domänen eller datacentret:

      Pinging <DatabaseServer> [10.10.10.3] with 32 bytes of data:
      Reply from 10.10.10.3: bytes=32 time=68ms TTL=116
      Reply from 10.10.10.3: bytes=32 time=67ms TTL=116
      Reply from 10.10.10.3: bytes=32 time=67ms TTL=116
      
  • Om du vill testa problem med svarstid för validering av autentiseringsuppgifter använder du Runas med olika användare. Till exempel:

    1. Kör runas /user:<DomainName>\<UserAccountName> cmd.exe.
    2. Ange lösenordet för användaren när en kommandotolk visas.

Om problemet kvarstår även efter testning med dessa kommandon är problemet inte med SQL Server utan med nätverksinfrastrukturen eller domänkontrollantens prestanda.

Leta efter prestandaproblem i SQL Server-felloggen

SQL Server-felloggen kan visa prestandaproblem på SQL Server, till exempel poster som anger att I/O tar längre tid än 15 sekunder. SQL-prestandateamet har PSSDIAG för att köra och analysera. Du kan behöva göra detta om en nätverksspårning visar fördröjningar i SQL Server-svar.

Felloggen kan även innehålla andra domänrelaterade fel, till exempel följande fellogg som indikerar vissa Problem med Active Directory-prestanda:

SSPI handshake failed with error code 0x80090311 while establishing a connection with integrated security; the connection has been closed.
SSPI handshake failed with error code 0x80090304 while establishing a connection with integrated security; the connection has been closed.

Följande felkoder för operativsystemet anger orsaken till felet:

  • Fel -2146893039 (0x80090311): Det gick inte att kontakta någon utfärdare för autentisering.

  • Fel -2146893052 (0x80090304): Det går inte att kontakta den lokala säkerhetsmyndigheten.

Granska händelseloggar i klientsystemet för nätverksfel

Systemhändelseloggen har olika händelser, till exempel Kerberos,Local Security Authority (LSA) och Netlogon-händelser. Dessa händelser indikerar att datorn inte kan ansluta till domänkontrollanten på ett tag. För att göra dem enklare att hitta filtrerar du endast fel-, varnings- och kritiska händelser. Händelsetiden måste ligga runt tidpunkten för avbrottet. Om det finns en matchning kan det vara ett Active Directory-problem.

I vissa fall kan det här problemet inträffa på SQL Server. Kontrollera loggarna på datorn också.

Source: NETLOGON
Date: <DateTime>
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: SQLPROD01
Description:
This computer was not able to set up a secure session with a domain controller in domain CONTOSO due to the following: The remote procedure call was cancelled. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

I händelseloggen för säkerhet filtrerar du händelse-ID 4625. Den här händelsen visar detaljerad information om inloggningsfelet.

Samla in och granska SQL-anslutningsringsbufferten

Ringbufferten är en historisk logg över anslutningshändelser på SQL Server, vilket innebär att den kan tas efter ett avbrott. Många händelser inkluderar inloggningstimers som anger var tiden spenderas:

  • Tiden som spenderas på nätverket indikerar en möjlig nätverks- eller klientfördröjning.
  • Tiden som ägnas åt SSL(Secure Sockets Layer) eller SSPI-API:er (Security Support Provider Interface) indikerar potentiella problem med Windows säkerhetsundersystem.
  • Enqueued time anger ett prestandaproblem för SQL Server.

Mer information finns i Samla in anslutningsringsbufferten.

Anslutningspooler

Bristen på anslutningspooler kan leda till tillfälliga inloggningsfel.

Kommentar

Bristen på anslutningspooler visar ett stort antal TIME_WAIT statuskoder i NETSTAT utdata jämfört med etablerade anslutningar.

Om anslutningspoolen inte är aktiverad kan klienten få slut på utgående portar och även överbelasta servern. Den här överlagringen kan leda till att servern avvisar inkommande anslutningsbegäranden eller översvämmar en domänkontrollant med dålig prestanda.

Det bästa är att låta programutvecklaren använda anslutningspooler i sina program. Anslutningspooler är på som standard i .NET- och IIS-program (Internet Information Services), men det kan ha inaktiverats av någon anledning.

Det rekommenderas starkt att program använder anpassad poolkod. Nästan alla anpassade poolimplementeringar som vi har stött på har haft problem. Det är bättre att använda den inbyggda mekanismen för anslutningspooler.

Att få slut på tillfälliga portar är en relativt vanlig orsak till tillfälliga tidsgränser för anslutningar.

Problem: Låg kernelminne på SQL Server-datorn.

Lösning: Justera maximalt serverminne (MB) i fönstret Egenskaper i SQL Server Management Studio. Det är bäst att ange maximalt serverminne (MB) till cirka 4 GB till 8 GB mindre än det fysiska minnet på datorn. Det här värdet bör vara mindre om det finns flera instanser, IIS eller några andra programservrar som körs på datorn. Rekommendationer om inställningen för maximalt serverminne (MB) finns i Konfigurationsalternativ för serverminne.

Kommentar

Standardvärdet är 2147483647 MB, vilket innebär att servern kan orsaka att operativsystemet (OS) får slut på minne.