Dela via

Konsekventa autentiseringsproblem i SQL Server

  • Artikel

Gäller för: SQL Server

Kommentar

De kommandon som anges i den här artikeln gäller endast för Windows-system.

Konsekventa autentiseringsproblem som uppstår i Microsoft SQL Server är vanligtvis relaterade till autentisering och auktorisering av användare eller program som försöker komma åt SQL Server-databasen. De här problemen kan vara autentiseringsfel, nekad åtkomst eller andra säkerhetsrelaterade problem.

Nyckeln till att effektivt lösa konsekventa autentiseringsproblem är att förstå de olika feltyperna och vad varje felmeddelande innebär. Vissa fel kan visas i mer än ett autentiseringsproblem. Du kan använda felsökningsinformationen som nämns i avsnittet Typer av fel för att lösa felet.

Förutsättningar

Innan du börjar felsöka bör du gå igenom förutsättningarnas checklista för att få följande information klar:

Feltyper

I det här avsnittet beskrivs feltyper och relaterad information.

  • Katalogtjänstfel: Om SQL Server-felloggfilen innehåller något av eller båda av följande meddelanden är det här felet relaterat till Active Directory-domän Services (AD DS). Det här felet kan också inträffa om Windows på den SQL Server-baserade datorn inte kan kontakta domänkontrollanten (DC) eller om LSASS (Local Security Authority Subsystem Service) upplever ett problem.

    Error -2146893039 (0x80090311): No authority could be contacted for authentication.
Error -2146893052 (0x80090304): The Local Security Authority cannot be contacted.

  • Misslyckade inloggningsfel: När du felsöker felet "Inloggningen misslyckades" ger SQL Server-felloggen ytterligare insikter om felkoden 18456, inklusive ett specifikt tillståndsvärde som ger mer kontext om felet. Mer information finns i SQL Server-felloggfilen i SQL-tillståndsvärdet. Du kan försöka åtgärda problemet enligt beskrivningen av tillståndsvärdet.

    I följande tabell visas några specifika felmeddelanden om misslyckade inloggningar och möjliga orsaker och lösningar.

    Felmeddelande Mer information
    "Ett transportnivåfel har uppstått när begäran skickades till servern." Kontrollera om mappningen av det länkade serverkontot är korrekt. Mer information finns i sp_addlinkedsrvlogin.
    "Det går inte att generera SSPI-kontext"
    "Det går inte att öppna databastestet <> som begärdes vid inloggningen. Inloggningen misslyckades.” Databasen kan vara offline eller så räcker det inte med behörigheterna. Mer information finns i Databasen är offline i MSSQLSERVER_18456.
    Kontrollera också om databasnamnet i anslutningssträng är korrekt.
    "Inloggningen misslyckades för användarens <användarnamn>." Det här felet kan inträffa om proxykontot inte autentiseras korrekt.
    "Inloggningen misslyckades för användaren: 'NT AUTHORITY\ANONYMOUS LOGON'" Det här felet kan inträffa om SPN saknas, SPN dupliceras eller om SPN är på fel konto.
    "Inloggningen misslyckades för användarens <användarnamn>."
    "Inloggningen misslyckades för användaren '<database\username>'
    		 Kontrollera om en anslutningssträng innehåller ett felaktigt servernamn. Kontrollera också om användaren tillhör en lokal grupp som används för att bevilja åtkomst till servern. Fler orsaker finns i NT AUTHORITY\ANONYMOUS LOGON (NT AUTHORITY\ANONYMOUS LOGON).
    "Inloggningen misslyckades för användarens< användarnamn>. Orsak: Lösenordet matchade inte det för den angivna inloggningen." Det här felet kan inträffa om ett felaktigt lösenord används. Mer information finns i Inloggningen misslyckades för användarens< användarnamn> eller inloggningen misslyckades för användarens domänanvändarnamn<><>.
    "SQL Server finns inte eller åtkomst nekas." Namngivna pipes-anslutningar misslyckas eftersom användaren inte har behörighet att logga in på Windows.
    "Inloggningen kommer från en domän som inte är betrodd och kan inte användas med Windows-autentisering." Det här felet kan vara relaterat till problem med det lokala säkerhetsundersystemet .
    "Användarkontot tillåts inte som nätverksinloggningstyp." Du kanske inte kan logga in på nätverket.

Typer av konsekventa autentiseringsproblem

I det här avsnittet beskrivs vanliga orsaker till konsekventa autentiseringsproblem tillsammans med deras respektive lösningar. Välj problemtyp för att se relevanta problem, orsaker och lösningar.

Anslutningssträng

I det här avsnittet visas de problem som rör konfigurationsinställningar som används av program för att ansluta till en databas.

Databas

I det här avsnittet visas de problem som är specifika för olika aspekter av SQL Server:

  • Databasen är offline – refererar till ett scenario där en SQL Server-databas försöker återansluta till en SQL Server-instans som är konfigurerad för Windows-autentiseringsläge.

    Lösning: Mer information finns i MSSQLSERVER_18456.

  • Databasbehörigheter – Avser aktivering eller begränsning av åtkomst till en SQL Server-databas.

    Lösning: Mer information finns i MSSQLSERVER_18456.

  • Anslutningsfel för länkad server i SQL Server – Du upplever ett autentiseringsprocessproblem som påverkar länkade servrar i kontexten för SQL Server.

    Lösning: Information om hur du löser det här problemet finns i Anslutningsfel för länkad server i SQL Server.

  • Metadata för den länkade servern är inkonsekventa – Refererar till ett problem där metadata för den länkade servern är inkonsekventa eller inte matchar förväntade metadata.

    En vy eller en lagrad procedur frågar tabellerna eller vyerna på den länkade servern men får inloggningsfel även om en distribuerad SELECT instruktion som kopieras från proceduren inte gör det.

    Det här problemet kan inträffa om vyn skapades och den länkade servern återskapades, eller om en fjärrtabell ändrades utan att vyn återskapades.

    Lösning: Uppdatera metadata för den länkade servern genom att köra den sp_refreshview lagrade proceduren.

  • Proxykontot har inte behörighet – Ett SQL Server Integration Service-jobb (SSIS) som körs av SQL Agent kan kräva andra behörigheter än de som SQL Agent-tjänstkontot kan tillhandahålla.

    Lösning: Information om hur du löser det här problemet finns i SSIS-paketet körs inte när det anropas från ett SQL Server Agent-jobbsteg.

  • Det går inte att logga in på SQL Server-databasen – Det går inte att logga in kan orsaka fel i autentiseringen.

    Lösning: Information om hur du löser det här problemet finns i MSSQLSERVER_18456.

Katalogtjänster

I det här avsnittet visas de problem som rör katalogtjänster och servrar.

  • Ett konto är inaktiverat – Du kan uppleva det här scenariot om användarkontot har inaktiverats av en administratör eller av en användare. I det här fallet kan du inte logga in med det här kontot eller så kan du inte använda det här kontot för att starta en tjänst. Detta kan orsaka konsekventa autentiseringsproblem eftersom det kan hindra dig från att komma åt resurser eller utföra åtgärder som kräver autentisering.

    Lösning: En domänadministratör kan åtgärda detta genom att återaktivera kontot. När ett konto är inaktiverat beror det vanligtvis på att en användare antingen försökte logga in med fel lösenord för många gånger eller på att ett program eller en tjänst försöker använda ett gammalt lösenord.

  • Ett konto finns inte i gruppen – Det här problemet kan inträffa om en användare försöker komma åt en resurs som är begränsad till en viss grupp.

    Lösning: Kontrollera SQL-inloggningarna för att räkna upp tillåtna grupper och se till att användaren tillhör någon av grupperna.

  • Kontomigrering misslyckades – Om gamla användarkonton inte kan ansluta till servern men nyligen skapade konton kan det hända att kontomigreringen inte är korrekt. Det här problemet gäller AD DS.

    Lösning: Mer information finns i Överföra inloggningar och lösenord mellan instanser av SQL Server.

  • Domänkontrollant är offline – refererar till ett problem där domänkontrollanten inte är tillgänglig.

    Lösning: Använd nltest kommandot för att tvinga datorn att växla till en annan domänkontrollant. Mer information finns i Active Directory-replikeringshändelse-ID 2087: DNS-sökningsfel gjorde att replikeringen misslyckades.

  • Brandväggen blockerar domänkontrollanten – Du kan få problem när du hanterar användarens åtkomst till resurser.

    Lösning: Kontrollera att domänkontrollanten är tillgänglig från klienten eller servern. Använd kommandot för nltest /SC_QUERY:CONTOSO att göra detta.

  • Inloggningen kommer från en domän som inte är betrodd – Det här problemet gäller förtroendenivån mellan domäner. Du kan se följande felmeddelande: "Inloggningen misslyckades. Inloggningen kommer från en domän som inte är betrodd och kan inte användas med Windows-autentisering. (18452)."

    Fel 18452 anger att inloggningen använder Windows-autentisering men att inloggningen är ett okänt Windows-huvudnamn. Ett okänt Windows-huvudnamn anger att inloggningen inte kan verifieras av Windows. Detta kan inträffa eftersom Windows-inloggningen kommer från en domän som inte är betrodd. Förtroendenivån mellan domäner kan orsaka fel i kontoautentiseringen eller synligheten för tjänstleverantörsnamn (SPN).

    Lösning: Information om hur du löser det här problemet finns i MSSQLSERVER_18452.

  • Inga behörigheter för korsdomängrupper – Användare från fjärrdomänen ska tillhöra en grupp i SQL Server-domänen. Det kan uppstå ett problem om du försöker använda en domänlokal grupp för att ansluta till en SQL Server-instans från en annan domän.

    Lösning: Om domänerna saknar rätt förtroende kan det hindra servern från att räkna upp gruppens medlemskap genom att lägga till användarna i en grupp i fjärrdomänen.

  • Selektiv autentisering är inaktiverad – Refererar till en funktion i domänförtroenden som gör att domänadministratören kan begränsa vilka användare som har åtkomst till resurser i fjärrdomänen. Om selektiv autentisering inte är aktiverat kan alla användare i den betrodda domänen få åtkomst till fjärrdomänen.

    Lösning: Lös problemet genom att aktivera selektiv autentisering för att se till att användarna inte tillåts autentisera i fjärrdomänen.

Kerberos-autentisering

I det här avsnittet visas de problem som är relaterade till Kerberos-autentiseringen:

  • Ett felaktigt DNS-suffix läggs till i NetBIOS-namnet – Det här problemet kan inträffa om du bara använder NetBIOS-namnet (till exempel SQLPROD01) i stället för det fullständigt kvalificerade domännamnet (FQDN) (till exempel SQLPROD01.CONTOSO.COM). När detta inträffar kan fel DNS-suffix läggas till.

    Lösning: Kontrollera nätverksinställningarna för standardsuffixen för att se till att de är korrekta eller använd FQDN för att undvika problem.

  • Klockans skevhet är för hög – Det här problemet kan inträffa om flera enheter i ett nätverk inte synkroniseras. För att Kerberos-autentiseringen ska fungera kan klockorna mellan enheter inte stängas av i mer än fem minuter, eller så kan konsekventa autentiseringsfel inträffa.

    Lösning: Konfigurera datorerna så att de regelbundet synkroniserar sina klockor med en central tidstjänst.

  • Delegera känsliga konton till andra tjänster – Vissa konton kan markeras som Sensitive i AD DS. Dessa konton kan inte delegeras till en annan tjänst i ett dubbelhoppsscenario. Känsliga konton är viktiga för att tillhandahålla säkerhet, men de kan påverka autentiseringen.

    Lösning: Information om hur du löser det här problemet finns i Inloggningen misslyckades för användaren NT AUTHORITY\ANONYM INLOGGNING.

  • Delegera till en filresurs – Refererar till en situation där en användare eller ett program delegerar sina autentiseringsuppgifter för att få åtkomst till en filresurs. Utan lämpliga begränsningar kan delegering av autentiseringsuppgifter till en filresurs skapa säkerhetsrisker.

    Lösning: Lös den här typen av problem genom att se till att du använder begränsad delegering.

  • Disjoint DNS-namnområde – Refererar till ett konsekvent autentiseringsproblem som kan uppstå om DNS-suffixet inte matchar mellan domänmedlemmen och DNS. Du kan uppleva autentiseringsproblem om du använder ett osammanhängande namnområde. Om organisationshierarkin i AD DS och i DNS inte matchar kan fel SPN genereras om du använder NETBIOS-namnet i databasprogrammet anslutningssträng. I det här fallet hittas inte SPN och autentiseringsuppgifterna för New Technology LAN Manager (NTLM) används i stället för Kerberos-autentiseringsuppgifter.

    Lösning: Du kan åtgärda problemet genom att använda serverns fullständiga domännamn eller ange SPN-namnet i anslutningssträng. Information om FQDN finns i Datornamngivning.

  • Duplicerat SPN – refererar till en situation där två eller flera SPN är identiska inom en domän. SPN används för att unikt identifiera tjänster som körs på servrar i en Windows-domän. Duplicerade SPN kan orsaka autentiseringsproblem.

    Lösning: Information om hur du löser det här problemet finns i Åtgärda felet med Kerberos Configuration Manager (rekommenderas)..

  • Aktivera HTTP-portar på SPN:er – Vanligtvis använder HTTP-SPN:er inte portnummer (till exempel http/web01.contoso.com).

    Lösning: Du kan lösa det här problemet genom att använda principen på klienterna. SPN måste då vara i formatet http/web01.contoso.com:88 för att Kerberos ska fungera korrekt. Annars används NTLM-autentiseringsuppgifter.

    NTLM-autentiseringsuppgifter rekommenderas inte eftersom de kan göra det svårt att diagnostisera problemet. Den här situationen kan också generera överdrivna administrativa kostnader.

  • Utgångna biljetter – refererar till Kerberos-biljetter. Användning av Kerberos-biljetter som har upphört att gälla kan orsaka autentiseringsproblem.

    Lösning: Information om hur du löser det här problemet finns i Förfallna biljetter.

  • HOSTS-filen är felaktig – HOSTS-filen kan störa DNS-sökningar och generera ett oväntat SPN-namn. Den här situationen gör att NTLM-autentiseringsuppgifter används. Om en oväntad IP-adress finns i HOSTS-filen kanske det SPN som genereras inte matchar serverdelsservern som pekas på.

    Lösning: Granska HOSTS-filen och ta bort posterna för servern. HOSTS-filposter visas i SQLCHECK-rapporten.

  • Problem med behörigheter för säkerhetsidentifierare per tjänst (SID) – Per tjänst-SID är en säkerhetsfunktion i SQL Server som begränsar lokala anslutningar till att använda NTLM och inte Kerberos som autentiseringsmetod. Tjänsten kan göra ett enda hopp till en annan server med NTLM-autentiseringsuppgifter, men den kan inte delegeras ytterligare utan att använda den begränsade delegeringen. Mer information finns i Inloggningen misslyckades för användaren NT AUTHORITY\ANONYMOUS LOGON.

    Lösning: För att lösa det här problemet måste domänadministratören konfigurera begränsad delegering.

  • Autentisering i kernelläge – SPN på apppoolkontot krävs vanligtvis för webbservrar. Men när kernellägesautentisering används används datorns VÄRD-SPN för autentisering. Den här åtgärden utförs i kerneln. Den här inställningen kan användas om servern är värd för många olika webbplatser som använder samma url för värdhuvud, olika apppoolkonton och Windows-autentisering.

    Lösning: Ta bort HTTP-SPN:erna om autentisering i kernelläge är aktiverat.

  • Begränsa delegeringsrättigheterna till Access- eller Excel-leverantörerna (JET) och Access Connectivity Engine (ACE) liknar något av filsystemen. Du måste använda begränsad delegering för att SQL Server ska kunna läsa filer som finns på en annan dator. I allmänhet bör ACE-providern inte användas på en länkad server eftersom detta uttryckligen inte stöds. JET-providern är inaktuell och är endast tillgänglig på 32-bitarsdatorer.

    Kommentar

    När SQL Server 2014, den senaste versionen som har stöd för 32-bitarsinstallationer, inte längre stöds kommer JET-scenariot inte längre att stödjas.

  • SPN saknas – Det här problemet kan inträffa om ett SPN som är relaterat till en SQL Sever-instans saknas.

    Lösning: Mer information finns i Åtgärda felet med Kerberos Configuration Manager (rekommenderas).

  • Inte ett begränsat mål – Om begränsad delegering är aktiverad för ett visst tjänstkonto misslyckas Kerberos om målserverns SPN inte finns med i listan över mål för begränsad delegering.

    Lösning: För att lösa det här problemet måste en domänadministratör lägga till målserverns SPN i mål-SPN:erna för tjänstkontot på mellannivå.

  • NTLM och begränsad delegering – Om målet är en filresurs måste delegeringstypen för tjänstkontot på mellannivå vara Begränsad-Alla och inte Begränsad-Kerberos. Om delegeringstypen är inställd på Constrained-Kerberos kan mittnivåkontot endast allokera till specifika tjänster, men Begränsad-Any gör att tjänstkontot kan delegera till alla tjänster.

    Lösning: Information om hur du löser det här problemet finns i Inloggningen misslyckades för användaren NT AUTHORITY\ANONYM INLOGGNING.

  • Det går inte att lita på tjänstkontot för delegering i AD – I ett dubbelhoppsscenario måste tjänstkontot för mellannivåtjänsten vara betrott för delegering i AD DS. Om tjänstkontot inte är betrott för delegering kan Kerberos-autentiseringen misslyckas.

    Lösning: Om du är administratör aktiverar du alternativet Betrodd för delegering .

  • Vissa äldre leverantörer stöder inte Kerberos via namngivna pipes – den äldre OLE DB-providern (SQLOLEDB) och ODBC-providern (SQL Server) som paketeras med Windows erbjuder inte stöd för Kerberos-autentisering via namngivna pipes. I stället stöder de endast NTLM-autentisering.

    Lösning: Använd en TCP-anslutning för att tillåta Kerberos-autentisering. Du kan också använda en nyare drivrutin, till exempel MSOLEDBSQL eller ODBC Driver 17. Men TCP föredras fortfarande framför Namngivna pipes, oavsett vilken version av drivrutinen som används.

  • SPN är associerat med ett fel konto – Det här problemet kan inträffa om ett SPN är associerat med fel konto i AD DS. Mer information finns i Åtgärda felet med Kerberos Configuration Manager (rekommenderas).

    Du kan få ett felmeddelande om ditt SPN har konfigurerats på fel konto i AD DS.

    Lösning: Lös felet genom att följa dessa steg:

    1. Använd SETSPN -Q spnName för att hitta SPN och dess aktuella konto.
    2. Använd SETSPN -D för att ta bort befintliga SPN:er.
    3. SETSPN -S Använd för att migrera SPN till rätt konto.

  • SQL Alias kanske inte fungerar korrekt – Ett SQL Server-alias kan orsaka att ett oväntat SPN genereras. Detta gör att NTLM-autentiseringsuppgifter misslyckas om SPN inte hittas eller ett SSPI-fel om det oavsiktligt matchar SPN för en annan server.

    Lösning: SQL-alias visas i SQLCHECK-rapporten. Lös problemet genom att identifiera och korrigera felaktiga eller felkonfigurerade SQL-alias så att de pekar på rätt SQL Server.

  • Användaren tillhör många grupper – Om en användare tillhör flera grupper kan autentiseringsproblem uppstå i Kerberos. Om du använder Kerberos via UDP måste hela säkerhetstoken passa in i ett enda paket. Användare som tillhör många grupper har en större säkerhetstoken än användare som tillhör färre grupper.

    Lösning: Om du använder Kerberos via TCP kan du öka inställningen [MaxTokenSize]. Mer information finns i MaxTokenSize och Kerberos Token Bloat.

  • Använd webbplatsvärdrubrik – HTTP-värdhuvudet spelar en mycket viktig roll i HTTP-protokollet för åtkomst till webbsidor.

    Lösning: Om webbplatsen har ett värdhuvudnamn kan inte VÄRD-SPN användas. Ett explicit HTTP SPN måste användas. Om webbplatsen inte har något värdhuvudnamn används NTLM. NTLM kan inte delegeras till en SQL Server-instans på serversidan eller till en annan tjänst.

NT LAN Manager (NTLM)

I det här avsnittet visas problem som är specifika för NTLM (NT LAN Manager):

  • Åtkomst nekas för NTLM-peerinloggningar – refererar till ett problem som är relaterat till NTLM-peerinloggningar.

    Lösning: När du kommunicerar mellan datorer som finns i antingen arbetsstationer eller domäner som inte litar på varandra kan du konfigurera identiska konton på båda datorerna och använda NTLM-peerautentisering.

    Inloggningar fungerar bara om både användarkontot och lösenordet matchar på båda datorerna. NTLM-autentisering kan vara inaktiverat eller stöds inte på klient- eller serversidan. Den här situationen kan orsaka autentiseringsfel. Mer information finns i MSSQLSERVER_18456.

  • Scenarier med dubbelhopp på flera datorer – En dubbelhoppsprocess misslyckas om NTLM-autentiseringsuppgifter används. Kerberos-autentiseringsuppgifter krävs.

    Lösning: Information om hur du löser det här problemet finns i Inloggningen misslyckades för användaren NT AUTHORITY\ANONYM INLOGGNING.

  • Loopback-skydd är inte korrekt inställt – Loopback Protect är utformat för att förhindra att program anropar andra tjänster på samma dator. Om loopback protect inte har konfigurerats korrekt, eller om det uppstår fel, kan den här situationen indirekt orsaka autentiseringsproblem.

    Lösning: Information om hur du löser det här problemet finns i MSSQLSERVER_18456.

  • Loopback-skyddet misslyckas när du ansluter till lyssnaren always-on – Det här problemet är relaterat till loopback-skydd. När du ansluter till Lyssnaren alltid på från den primära noden använder anslutningen NTLM-autentisering.

    Lösning: Mer information finns i MSSQLSERVER_18456.

  • Problem som påverkar LANMAN-kompatibilitetsnivån – LAN Manager-autentiseringsproblemet (LANMAN) uppstår vanligtvis om det finns ett matchningsfel i de autentiseringsprotokoll som används av äldre (före Windows Server 2008) och nyare datorer. När du anger kompatibilitetsnivån till 5 tillåts inte NTLMv2.

    Lösning: Om du byter till Kerberos undviker du det här problemet eftersom Kerberos är säkrare. Mer information finns i Inloggningen misslyckades för användaren NT AUTHORITY\ANONYMOUS LOGON.

SQL-inloggning

Det här avsnittet innehåller problem som rör autentiseringsuppgifter:

  • Felaktigt lösenord – refererar till ett inloggningsrelaterat problem.

    Lösning: Information om hur du löser det här problemet finns i MSSQLSERVER_18456.

  • Ogiltigt användarnamn – Refererar till ett inloggningsrelaterat problem.

    Lösning: Information om hur du löser det här problemet finns i MSSQLSERVER_18456.

  • SQL Server-inloggningar är inte aktiverade – Refererar till ett scenario där du försöker ansluta till en Microsoft SQL Server-instans med hjälp av SQL Server-autentisering, men inloggningen som är associerad med kontot är inaktiverad.

    Lösning: Information om hur du löser det här problemet finns i MSSQLSERVER_18456.

  • Namngivna Pipes-anslutningar misslyckas eftersom användaren inte har behörighet att logga in på Windows – refererar till ett behörighetsproblem i Windows.

    Lösning: Information om hur du löser det här problemet finns i Problem med namngivna pipes-anslutningar i SQL Server.

Windows-behörigheter

Det här avsnittet innehåller problem som är specifika för Windows-behörigheter eller principinställningar:

  • Åtkomst beviljas via lokala grupper – Om användaren inte tillhör en lokal grupp som används för att bevilja åtkomst till servern visar providern felmeddelandet "Inloggningen misslyckades för användaren 'contoso/user1'".

    Lösning: Databasadministratören kan kontrollera den här situationen genom att undersöka mappen Säkerhetsinloggningar> i SQL Server Management Studio (SSMS). Om databasen är en innesluten databas kontrollerar du under databasename. Mer information finns i Inloggningen misslyckades för användarens< användarnamn> eller inloggningen misslyckades för användaren "<domän>\<användarnamn>".

  • Credential Guard är aktiverat – Det här scenariot anger att credential Guard-funktionen är aktiverad i ett Windows-system och används för att skapa en säker miljö för att lagra känslig information. I vissa situationer kan den här funktionen dock orsaka autentiseringsproblem.

    Lösning: Lös problemet genom att be en domänadministratör att konfigurera begränsad delegering. Mer information finns i Överväganden och kända problem när du använder Credential Guard.

  • Fel i lokala säkerhetsundersystem – När du får fel i det lokala säkerhetsundersystemet, särskilt de som är länkade till att LSASS inte svarar, kan det tyda på underliggande problem som påverkar autentiseringen.

    Lösning: Information om hur du löser dessa fel finns i Lokala säkerhetsundersystemfel i SQL Server.

  • Nätverksinloggning tillåts inte – Det här scenariot inträffar när du försöker logga in på ett nätverk men din inloggningsbegäran nekas av vissa skäl.

    Lösning: Information om hur du löser det här problemet finns i Användaren har inte behörighet att logga in på nätverket.

  • Endast administratörer kan logga in – Det här problemet uppstår om säkerhetsloggen på en dator är full och inte har tillräckligt med utrymme för att fylla händelser. Säkerhetsfunktionen CrashOnAuditFail används av systemadministratörer för att kontrollera alla säkerhetshändelser. Giltiga värden för CrashOnAuditFail är 0, 1 och 2. Om nyckeln för CrashOnAuditFail är inställd på 2 innebär det att säkerhetsloggen är full och felmeddelandet "Endast administratörer kan logga in" visas.

    Lösning: Lös problemet genom att följa dessa steg:

    1. Starta Registereditorn.
    2. Leta upp och kontrollera undernyckeln HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa!crashonauditfail för att se om värdet är inställt på 2. Det här värdet anger att säkerhetsloggen kräver manuell rensning.
    3. Ange värdet till 0 och starta sedan om servern. Du kanske också vill ändra säkerhetsloggen så att händelser kan rullas över. Mer information om hur inställningen påverkar alla tjänster som SQL, IIS, filresurs och inloggning finns i Användare kan inte komma åt webbplatser när säkerhetshändelseloggen är full.

    Kommentar

    Det här problemet påverkar endast integrerade inloggningar. En anslutning med namngivna pipes påverkas också i en SQL Server-inloggning eftersom Namngivna pipes först loggar in på Windows Admin Pipe innan den ansluter till SQL Server.

  • Tjänstkontot är inte betrott för delegering – Den här typen av problem uppstår vanligtvis om ett tjänstkonto inte tillåts tilldela autentiseringsuppgifter till andra servrar. Det här problemet kan påverka tjänster som kräver delegering.

    Lösning: Om ett delegeringsscenario inte är aktiverat kontrollerar du SQL Server secpol.msc för att avgöra om SQL Server-tjänstkontot visas under Tilldelning av användarrättigheter > för lokala principer > Personifiera en klient efter autentiseringens säkerhetsprincipinställningar. Mer information finns i Aktivera att dator- och användarkonton är betrodda för delegering.

  • Windows-användarprofilen kan inte läsas in i SQL Server – refererar till windows-användarprofilproblemet.

    Lösning: Mer information om hur du felsöker skadade användarprofiler finns i Windows-användarprofilen kan inte läsas in i SQL Server.

Andra aspekter

I det här avsnittet visas problem som rör autentisering och åtkomstkontroll i en webbmiljö:

  • Integrerad autentisering är inte aktiverat – Refererar till ett konfigurationsproblem där integrerad Windows-autentisering (IWA) inte är korrekt konfigurerad.

    Lösning: Lös problemet genom att kontrollera att alternativet Integrerad Windows-autentisering är aktiverat i inställningarna för Internetalternativ .

  • IIS-autentisering tillåts inte – Det här problemet uppstår på grund av felkonfigurationer i IIS. Autentiseringsinställningarna som definieras i webbprogrammets Web.config-fil kan vara i konflikt med de inställningar som har konfigurerats i IIS. Den här situationen kan orsaka autentiseringsproblem.

    Lösning: Lös problemet genom att konfigurera webbplatsen för att aktivera Windows-autentisering och ange <identity impersonate="true"/> värdet i filen Web.config .

  • Fel Internetzon – Det här problemet kan inträffa om du försöker komma åt en webbplats som inte är i rätt Internetzon i Internet Explorer. Autentiseringsuppgifterna fungerar inte om webbplatsen finns i den lokala intranätzonen.

    Lösning: Lägg till webbservern i IE:s lokala intranätzon.

Ansvarsfriskrivning för information från tredje part

De produkter från andra tillverkare som diskuteras i denna artikel tillverkas oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.

Mer information

Samla in data för att felsöka anslutningsproblem med SQL Server