Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för:
SQL Server
Detaljer
| Attribute | Värde |
|---|---|
| Produktnamn | SQL Server |
| Händelse-ID | 18456 |
| Händelsekälla | MSSQLSERVER |
| Komponent | SQLEngine |
| Symboliskt namn | LOGON_FAILED |
| Meddelandetext | Inloggning misslyckades för användarens '%.*ls'.%.*ls |
Explanation
Du får detta felmeddelande när ett anslutningsförsök avvisas på grund av ett autentiseringsfel. Användarinloggningar kan misslyckas av många anledningar, såsom ogiltiga inloggningsuppgifter, lösenordsutgång och att ha aktiverat fel autentiseringsläge. I många fall innehåller felkoder beskrivningar.
Användaråtgärd
Följande exempel är några av de vanligaste inloggningsfelen. Välj exakt det fel du upplever för att felsöka problemet:
Inloggning misslyckades för användarens '<användarnamn>' eller inloggningen misslyckades för användaren '<domain>\<username>'
Om domännamnet inte anges är problemet ett misslyckat försök med SQL Server-inloggning. Om domännamnet anges är problemet en felaktig inloggning till Windows-användarkontot. För möjliga orsaker och föreslagna lösningar, se:
| Potentiell orsak | Föreslagen lösning |
|---|---|
| Du försöker använda SQL Server-autentisering, men SQL Server-instansen är konfigurerad för Windows-autentiseringsläge. | Verifiera att SQL Server är konfigurerad att använda SQL Server och Windows-autentiseringsläge. Du kan granska och ändra autentiseringsläget för din SQL Server-instans på säkerhetssidan under Egenskaper för motsvarande instans i SQL Server Management Studio (SSMS). För mer information, se Byt server-autentiseringsläge. Alternativt kan du ändra din applikation till att använda Windows-autentiseringsläge för att ansluta till SQL Server. Notera: Du kan se ett meddelande liknande följande i SQL Server Error-loggen för detta scenario: Login failed for user '<UserName>'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. |
| Du försöker komma åt SQL Server via en grupp och ser ett felmeddelande. | Om du inte har nödvändiga behörigheter för att komma åt servern visar leverantören felmeddelandet "Inloggning misslyckades för användare 'contoso/user1'". Använd funktionen "Access via group" som hjälper dig att komma åt en server baserat på ditt gruppmedlemskap. När du kör den lagrade xp_logininfo 'contoso/user1' proceduren kan följande inträffa:- Om du ser ett fel kan SQL Server inte lösa användarnamnet alls. Det är troligt att ett namn inte finns i Active Directory (AD) eller så kan det finnas problem med att ansluta till domänkontrollern (DC). Prova med ett annat namn för att kontrollera om problemet är specifikt för ett specifikt konto. - Om du ansluter till en domänöverskridande server måste gruppen vara i SQL Server-domänen och inte användardomänen, så att dess medlemskap kan lösas. - När en databasfråga inte returnerar några rader betyder det att det inte finns någon grupp som ger tillgång till servern. När en fråga returnerar en eller flera rader betyder det att användaren tillhör en grupp som ger åtkomst. DBA:n kan dubbelkolla behörigheterna genom att kontrollera mappen Security\Logins i SQL Server Management Studio (SSMS). Security\Logins visar en lista över skapade inloggningar. Om det är en innesluten databas kan DBA:n kontrollera Security\Logins under databasnamnet för att kontrollera och hantera inloggningarna. För mer information, se Konfigurera användaråtkomstkontroll och behörigheter. |
| SQL-inloggningar är inte aktiverade | Databashanteringssystemet (DBMS) kan visa någon variation av meddelandet Login failed for user '<username>' . Du åtgärdar felet genom att följa dessa steg:1. Kontrollera om SQL Server-felloggen innehåller felmeddelandet "Inloggning misslyckades för användarens '<användarnamn>'. Anledning: Ett försök att logga in med SQL-autentisering misslyckades. Servern är konfigurerad för Windows-autentisering enbart." 2. Använd en av följande metoder för att lösa felet: - Använd en integrerad inloggning. Till exempel, för OLE DB-leverantörer, lägg till INTEGRATED SECURITY=SSPI i anslutningssträngen, och för ODBC-drivrutiner, lägg till TRUSTED_CONNECTION=YES. .NET-leverantören accepterar båda syntaxerna.Not: Detta kan leda till andra problem om de inte är korrekt konfigurerade för att tillåta integrerad autentisering, och behöver undersökas som ett separat ärende. - Aktivera SQL-inloggningar på servern: a. I SQL Server Management Studio, högerklicka på SQL Server-namnet i Object Explorer och välj Egenskaper. b) I säkerhetspanelen , välj SQL Server- och Windows-autentiseringsläget . c. Välj OK. d. Starta om SQL Server för att ändringen ska kunna ske. Not: Detta kan leda till andra problem, som att definiera en SQL-inloggning. - Försök ange ett lokalt Windows-konto eller ett domänkonto för användarnamnet. Endast SQL-inloggningar är tillåtna. Applikationen bör använda integrerad säkerhet. |
| Inloggning finns inte på SQL Server-instansen du försöker ansluta till. | Verifiera att SQL Server-inloggningen finns och att du har stavat det korrekt. Om inloggningen inte finns, skapa den. Om det finns där men stavas fel, rätta det i applikationsanslutningssträngen. SQL Server Errorlog kommer att innehålla ett av följande meddelanden: - Login failed for user 'username'. Reason: Could not find a login matching the name provided.- Login failed for user 'Domain\username'. Reason: Could not find a login matching the name provided.Detta kan vara ett vanligt problem om du distribuerar en applikation som använder en DEV- eller QA-server i produktion och du misslyckas med att uppdatera anslutningssträngen. För att lösa detta problem, kontrollera att du ansluter till rätt server. Om inte, korrigera anslutningssträngen. Om det är så, ge inloggningsbehörighet till din SQL Server. Eller om det är en Windows-inloggning, ge direkt åtkomst eller lägg till det i en lokal eller domängrupp som får ansluta till databasservern. För mer information, se Skapa en inloggning. |
| Du använder SQL Server-autentisering, men lösenordet du angav för SQL Server-inloggning är felaktigt. | Kontrollera SQL-felloggen för meddelanden som "Orsak: Lösenordet matchade inte det för den angava inloggningen" för att bekräfta orsaken. För att lösa problemet, använd rätt lösenord i din applikation eller ett annat konto om du inte minns lösenordet. Alternativt kan du samarbeta med din SQL Server-administratör för att återställa lösenordet till kontot. Om applikationen är SQL Server Integration Services (SSIS) kan det finnas flera nivåer av en konfigurationsfil för jobbet, vilket kan åsidosätta inställningarna i Connection Manager för paketet. Om applikationen är skriven av ditt företag och anslutningssträngen är programmatiskt genererad, engagera utvecklingsteamet för att lösa problemet. Som en tillfällig lösning, hårdkoda anslutningssträngen och testa. Använd en UDL-fil eller ett skript för att bevisa att en anslutning är möjlig med en hårdkodad anslutningssträng. |
| Anslutningssträngen har felaktig syntax, servernamn eller användaruppgifter. | För att lösa detta, följ dessa steg:
|
| Ingen inloggning | Kontrollera om SQL Server visar följande meddelanden:Logon Error: 18456, Severity: 14, State: 11.Logon Login failed for user 'CONTOSO\JohnDoe'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: ]Några av felen tillhör Anonymous Logon-kontot. Detta är relaterat till Kerberos-frågan. Det fanns en felaktig manuell post i HOSTS-filen, det vill säga fel servernamn gavs. De återstående frågorna kan falla in i följande kategorier:
|
| Du försöker ansluta med Windows-autentisering men är inloggad på fel domän. | Kontrollera att du är korrekt inloggad på rätt domän. Felmeddelandet visar vanligtvis domännamnet. |
| Kontrollera databasbehörigheter | Databasen visas inte offline i SQL Server Management Studio. Andra användare, till exempel DBA:n, kan ansluta till den. Det aktuella användarkontot måste beviljas explicit åtkomst till databasen eller läggas till i en SQL Server-roll eller en lokal Windows-grupp eller domängrupp som har tillgång till databasen. För mer information, se SKAPA ANVÄNDARE,ALTER ROLE och ALTER SERVER ROLE |
| Du kör inte din applikation (till exempel SSMS) som administratör. | Om du försöker ansluta med dina administratörsuppgifter, starta din applikation med alternativet Kör som administratör . När du är ansluten lägger du till din Windows-användare som individuell inloggning. |
| Inloggning raderas efter en migrering till en användare av en innehållen databas. | Om databasmotorn stödjer inneslutna databaser, bekräfta att inloggningen inte raderades efter migreringen till en innehållen databasanvändare. För mer information, se Innesluten databasautentisering: Introduktion. |
| Logins standarddatabas är offline eller på annat sätt inte tillgänglig. | Kontakta din SQL Server-administratör och lös problem relaterade till databastillgänglighet. Om inloggningen har behörigheter till andra databaser på servern och du inte behöver komma åt den för närvarande konfigurerade standarddatabasen i din applikation, använd ett av följande alternativ: - Be administratören ändra standarddatabasen för inloggningen med hjälp av ALTER LOGIN-satsen eller SSMS. - Specificera explicit en annan databas i din applikations anslutningssträng. Eller om du använder SSMS, byt till fliken Anslutningsegenskaper för att ange en databas som för närvarande är tillgänglig.Applikationer som SSMS kan visa ett felmeddelande som följande: Cannot open user default database. Login failed.Login failed for user <user name>. (Microsoft SQL Server, Error: 4064)SQL Server Errorlog kommer att ha ett felmeddelande som följande: Login failed for user '<user name>'. Reason: Failed to open the database '<dbname>' specified in the login properties [CLIENT: <ip address>]För mer information, se MSSQLSERVER_4064. |
| Databasen som uttryckligen anges i anslutningssträngen eller i SSMS är felaktigt stavad, offline eller på annat sätt inte tillgänglig. | - Fixera databasnamnet i anslutningssträngen. Var uppmärksam på kasuskänslighet om du använder en kasuskänslig sortering på servern. - Om databasnamnet är korrekt, kontrollera med din SQL Server-administratör och lös problem relaterade till databasens tillgänglighet. Kontrollera om databasen är offline, inte återställd, och så vidare. - Om inloggningen har mappats till användare med behörigheter till andra databaser på servern och du inte behöver komma åt den för närvarande konfigurerade databasen i din applikation, ange då en annan databas i din anslutningssträng. Eller om du ansluter till SSMS, använd fliken Anslutningsegenskaper för att ange en databas som är tillgänglig just nu. SQL Server Errorlog kommer att ha ett felmeddelande som följande: Login failed for user <UserName>. Reason: Failed to open the explicitly specified database 'dbname'. [CLIENT: <ip address>]Observera: Om inloggningens standarddatabas är tillgänglig tillåter SQL Server att anslutningen lyckas. För mer information, se MSSQLSERVER_4064. |
| Användaren har inga behörigheter till den begärda databasen. | - Försök ansluta som en annan användare med sysadmin-rättigheter för att se om anslutning kan upprättas. - Bevilja inloggningsåtkomst till databasen genom att skapa motsvarande användare (till exempel, CREATE USER [<UserName>] FOR LOGIN [UserName]) |
Kolla också den omfattande listan med felkoder under Felsökningsfel 18456.
För mer felsökningshjälp, se Felsökning av SQL Client / Server Connectivity Issues.
Inloggning misslyckades för användaren NT AUTHORITY\ANONYMOUS LOGON
Det finns minst fyra scenarier för detta nummer. I följande tabell, undersök varje tillämplig potentiell orsak och använd lämplig lösning: Se noten nedanför tabellen för en förklaring av termen dubbelhopp.
| Möjliga orsaker | Föreslagna resolutioner |
|---|---|
| Du försöker skicka NT LAN Manager (NTLM)-uppgifter från en tjänst till en annan tjänst på samma dator (till exempel från IIS till SQL Server), men ett fel uppstår i processen. | Lägg till registreringsposterna DisableLoopbackCheck eller BackConnectionHostNames . |
| Det finns dubbelhopp (begränsningsdelegering) scenarier över flera datorer. Felet kan uppstå om Kerberos-anslutningen misslyckas på grund av problem med Service Principal Names (SPN). | Kör SQLCheck på varje SQL-server och webbservern. Använd felsökningsguiderna: 0600 Credential Delegation Issue och 0650 SQL Server Linked Server Delegation Issues. |
| Om ingen dubbelhopp (begränsningsdelegering) är involverad, finns det troligen dubbletter av SPN, och klienten körs som ett LocalSystem- eller ett annat maskinkonto som får NTLM-uppgifter istället för Kerberos-uppgifter. | Använd SQLCheck eller Setspn.exe för att diagnostisera och åtgärda eventuella SPN-relaterade problem. Gå även igenom Översikt av Kerberos Configuration Manager för SQL Server. |
| Windows Local Security-policy kan ha konfigurerats för att förhindra användning av maskinkontot för fjärrautentiseringsförfrågningar. | Gå till Lokal säkerhetspolicy>Lokala policyer>Säkerhetsalternativ>Nätverkssäkerhet: Låt det lokala systemet använda datoridentitet för NTLM, välj alternativet Aktiverat om inställningen är inaktiverad och välj sedan OK. Notera: Som beskrivs på fliken Förklara är denna policy aktiverad i Windows 7 och senare versioner som standard. |
| Intermittent förekomst av detta problem vid användning av begränsad delegering kan indikera att ett utgånget ärende finns som inte kan förnyas av mellannivån. Detta är ett förväntat beteende antingen i länkade serverscenarier eller i alla applikationer som håller en inloggningssession i mer än 10 timmar. | Ändra delegeringsinställningar på din mellannivåserver från Lita på denna dator för delegering till endast angivna tjänster – Använd endast Kerberos för att lita på denna dator för delegering till angivna tjänster endast – Använd vilket protokoll som helst. För mer information, se Intermittent ANONYMOUS LOGON of SQL Server linked server double hop. |
| NTLM Peer Login | Detta fel är relaterat till NTLM-autentiseringsprotokollet som används av Microsoft Windows OS. När du kommunicerar mellan datorer som antingen är i arbetsstationer eller i domäner som inte litar på varandra, kan du skapa identiska konton på båda maskinerna och använda NTLM peer-autentisering NTLM Peer Login. Inloggningar fungerar bara om både användarkontot och lösenordet matchar på båda datorerna. |
| Loopback-skydd | Loopback-skydd är utformat för att förhindra att applikationer anropar andra tjänster på samma maskin. Du kan antingen ställa in DisableLoopbackCheck registreringsnycklar eller BackConnectionHostNames (föredragna) registernycklar för att tillåta detta. För mer information, se Felmeddelande när du försöker komma åt en server lokalt genom att använda dess FQDN eller dess CNAME-alias efter att du installerat Windows Server 2003 Service Pack 1: Åtkomst nekad eller ingen nätverksleverantör accepterade den givna nätverksvägen. |
| Always-On Lyssnar-loopbackskydd | När man ansluter till Always-On Listener från primärnoden kommer anslutningen att vara NTLM. Detta aktiverar Loopback Check och resulterar i ett felmeddelande "Inloggning misslyckades" som anger att användaren kommer från en icke betrodd domän. För att lösa detta fel, skriv in Listener NETBIOS-namnet och fullt kvalificerat namn i registernyckeln BackConnectionHostNames på alla maskiner i Tillgänglighetsgruppen. För mer information, se Felmeddelande när du försöker komma åt en server lokalt genom att använda dess FQDN eller dess CNAME-alias efter att du installerat Windows Server 2003 Service Pack 1: Åtkomst nekad eller ingen nätverksleverantör accepterade den givna nätverksvägen. |
| LANMAN-kompatibilitetsnivå | Detta händer oftast mellan äldre datorer (före Windows 2008) och nyare datorer. Sätt LANMAN-kompatibilitetsnivån till 5 på alla datorer. Detta förbjuder också NTLM v1. Du kan också byta till Kerberos för att undvika detta problem. |
| Känsligt konto | Vissa konton kan vara markerade som känsliga i Active Directory. Dessa konton kan inte delegeras till en annan tjänst i ett dubbelhopp-scenario. |
| Inte ett begränsat mål | Om begränsad delegering är aktiverad för ett visst tjänstekonto, kommer Kerberos att misslyckas om målserverns SPN inte finns med på listan över mål för begränsad delegering. |
| Per-Service-SID | Denna funktion 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-inloggningsuppgifter, men den kan inte delegeras vidare utan att använda begränsad delegering. |
| NTLM och begränsad delegering | Om målet är en fildelning måste delegeringstypen för mellanklasskontot vara Constrained-Any och inte Constrained-Kerberos. |
Anmärkning
Ett dubbelhopp innebär vanligtvis delegering av användaruppgifter över flera fjärrdatorer. Till exempel, anta att du har en SQL Server-instans som heter SQL1 där du skapade en länkad server för en fjärr-SQL Server som heter SQL2. I länkad serversäkerhetskonfiguration valde du alternativet Be made med logins nuvarande säkerhetskontext. När du använder denna konfiguration, om du kör en länkad serverfråga på SQL1 från en fjärrklientdator som heter Client1, måste Windows-inloggningsuppgifterna först hoppa från Client1 till SQL1 och sedan från SQL1 till SQL2 (därför kallas det ett dubbelhopp). För mer information, se Förståelse för Kerberos dubbelhopp och Kerberos översikt av begränsad delegering
Inloggning misslyckades för användaren (tom)
Detta fel uppstår när en användare utan framgång försöker logga in. Detta fel kan uppstå om din dator inte är ansluten till nätverket. Till exempel kan du få ett felmeddelande som liknar följande:
Source: NETLOGON
Date: 8/12/2012 8:22:16 PM
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: <computer name>
Description: This computer was not able to set up a secure session with a domain controller in domain 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.
En tom sträng betyder att SQL Server försökte överlämna inloggningsuppgifterna till Local Security Authority Subsystem Service (LSASS) men inte kunde på grund av något problem. Antingen var LSASS inte tillgängligt, eller så kunde domänkontrollanten inte kontaktas.
Du kan också se följande motsvarande SSPI-felkoder:
SSPI-handskakningen misslyckades med felkoden 0x80090311 när den etablerade en anslutning med integrerad säkerhet; anslutningen har stängts.
SSPI-handshake misslyckades med felkod 0x80090304 när man upprättade en anslutning med integrerad säkerhet; anslutningen har stängts.
Dessa felkoder översätts enligt följande:
Fel -2146893039 (0x80090311): Ingen auktoritet kunde kontaktas för autentisering. Fel -2146893052 (0x80090304): Den lokala säkerhetsmyndigheten kan inte kontaktas.
För att lösa dessa fel kan du ta den felaktiga DC:n offline eller använda NLTEST.EXE för att byta DC.
- För att fråga DC:n, kör kommandot NLTEST /SC_QUERY:CONTOSO .
- För att ändra DC, kör kommandot NLTEST /SC_RESET:CONTOSO\DC03 .
Om du behöver ytterligare hjälp, kontakta Microsoft Active Directory-teamet.
Kontrollera händelseloggarna på klienten och servern efter eventuella nätverks- eller Active Directory-relaterade meddelanden som loggades runt tidpunkten för felet. Om du hittar några, samarbeta med din domänadministratör för att åtgärda problemen.
Inloggning misslyckades för användaren '(null)'
En indikation på "null" kan innebära att LSASS inte kan dekryptera säkerhetstoken genom att använda SQL Server-tjänstekontots uppgifter. Huvudorsaken till detta tillstånd är att SPN är kopplat till fel konto.
Följ dessa steg för att åtgärda problemet:
Använd SQLCheck eller Setspn.exe för att diagnostisera och åtgärda SPN-relaterade problem.
Använd SQLCheck för att kontrollera om SQL Service-kontot är betrodd för delegering. Om utdata visar att kontot inte är betrodd för delegering, samarbeta med din Active Directory-administratör för att aktivera delegering för kontot.
Anmärkning
Och SETSPN -X-Q är användbara kommandon för att kontrollera om det finns dubbletter eller felplacerade SPN:er.
Diagnostisera och åtgärda problem med upplösning av Domain Name System (DNS). Till exempel:
Pinga IP-adress genom att använda PowerShell-skript:
-
ping -a <your_target_machine>(används-4för IPv4 och-6IPv6 specifikt) ping -a <your_remote_IPAddress>
-
Använd NSLookup för att ange ditt lokala och fjärrdatornamn och IP-adress flera gånger.
Leta efter eventuella avvikelser och avvikelser i de returnerade resultaten. Noggrannheten i DNS-konfigurationen på nätverket är viktig för en lyckad SQL Server-anslutning. En felaktig DNS-post kan orsaka många anslutningsproblem senare.
Se till att brandväggar eller andra nätverksenheter inte blockerar en klient från att ansluta till domänkontrollanten. SPN:er lagras i Active Directory. Om klienterna inte kan kommunicera med katalogen kan inte anslutningen lyckas.
Ytterligare felinformation
För att öka säkerheten döljer felmeddelandet som returneras till klienten medvetet arten av autentiseringsfelet. I SQL Server-felloggen innehåller dock ett motsvarande fel ett feltillstånd som motsvarar ett autentiseringsfelvillkor. Jämför felstatusen med följande lista för att ta reda på orsaken till inloggningsmisslyckandet.
| Stat/län | Description |
|---|---|
| 1 | Felinformation finns inte tillgänglig. Detta tillstånd innebär oftast att du inte har tillstånd att ta emot feluppgifterna. Kontakta din SQL Server-administratör för mer information. |
| 2 | Användar-ID är inte giltigt. |
| 5 | Användar-ID är inte giltigt. |
| 6 | Ett försök gjordes att använda ett Windows-inloggningsnamn med SQL Server-autentisering. |
| 7 | Inloggning är inaktiverad och lösenordet är felaktigt. |
| 8 | Lösenordet är fel. |
| 9 | Lösenordet är inte giltigt. |
| 11 | Inloggningen är giltig, men serveråtkomsten misslyckades. En möjlig orsak till detta fel är när Windows-användaren har tillgång till SQL Server som medlem i den lokala administratörsgruppen, men Windows inte tillhandahåller administratörsuppgifter. För att ansluta startar du anslutningsprogrammet med alternativet Kör som administratör och lägger sedan till Windows-användaren i SQL Server som en specifik inloggning. |
| 12 | Inloggningen är giltig, men serveråtkomsten misslyckades. |
| 18 | Lösenordet måste ändras. |
| 38, 46 | Kunde inte hitta databasen som användaren begärt. |
| 58 | När SQL Server är inställd på att endast använda Windows-autentisering, och en klient försöker logga in med SQL-autentisering. En annan orsak är när SIDs inte matchar. |
| 62 | Uppstår när ett Windows-autentiseringskonto försöker komma åt en innehållen databas, och den innehållna databasen existerar, men SID:arna stämmer inte överens. |
| 102 - 111 | Azure AD failure. |
| 122 - 124 | Misslyckande på grund av tomt användarnamn eller lösenord. |
| 126 | Databasen som användaren begärt finns inte. |
| 132 - 133 | Azure AD failure. |
Andra feltillstånd finns och indikerar ett oväntat internt bearbetningsfel.
Mer sällsynt möjlig orsak
Felorsaken Ett försök att logga in med SQL-autentisering misslyckades. Servern är konfigurerad för endast Windows-autentisering. kan returneras i följande situationer.
När servern är konfigurerad för mixed mode-autentisering, och en ODBC-anslutning använder TCP-protokollet, och anslutningen specificerar inte uttryckligen att anslutningen ska använda en betrodd anslutning.
När SQL Server är konfigurerad för mixed mode-autentisering, och en ODBC-anslutning använder namngivna pipor, och de inloggningsuppgifter klienten använde för att öppna den namngivna pipan används för att automatiskt utge sig för att vara användaren, och anslutningssträngen specificerar inte uttryckligen användningen av en betrodd autentisering.
För att lösa detta problem, inkludera TRUSTED_CONNECTION = TRUE i anslutningssträngen.
Examples
I detta exempel är autentiseringsfelet 8. Detta indikerar att lösenordet är felaktigt.
| Date | Källa | Message |
|---|---|---|
| 2007-12-05 20:12:56.34 | Logon | Fel: 18456, Allvarlighet: 14, Delstat: 8. |
| 2007-12-05 20:12:56.34 | Logon | Inloggningen misslyckades för användaren '<user_name>'. [KLIENT: <IP-adress>] |
Anmärkning
När SQL Server installeras med Windows-autentiseringsläge och senare ändras till SQL Server och Windows-autentiseringsläge, inaktiveras sa-inloggningen initialt. Detta orsakar felet i tillstånd 7: "Inloggning misslyckades för användaren 'sa'." För att aktivera sa-inloggning , se Ändra serverautentiseringsläge.