Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A következőkre vonatkozik:
SQL Server
Részletek
| Attribute | Érték |
|---|---|
| Terméknév | SQL Server |
| Eseményazonosító | 18456 |
| Eseményforrás | MSSQLSERVER |
| Összetevő | SQLEngine |
| Szimbolikus név | LOGON_FAILED |
| Üzenet szövege | Bejelentkezés sikertelen volt a '%.*ls' felhasználónál.%.*ls |
Explanation
Ezt a hibaüzenetet akkor kapod, amikor egy csatlakozási kísérletet hitelesítési hiba miatt elutasítanak. A felhasználói bejelentkezések számos okból hibázhatnak, például érvénytelen hitelesítések, jelszó lejárata vagy a rossz hitelesítési mód engedélyezése. Sok esetben a hibakódok leírásokat tartalmaznak.
Felhasználói művelet
Az alábbi példák néhány gyakori bejelentkezési hibát mutatnak be. Válaszd ki pontosan azt a hibát, amit tapasztalsz, hogy elhárítsd a problémát:
Bejelentkezés sikertelen volt a '<felhasználónév>' vagy a '<domain>\<username>' felhasználónév esetén
Ha a domain név nincs megadva, akkor a probléma egy sikertelen SQL Server bejelentkezési kísérlet. Ha a domain név meg van adva, a probléma egy sikertelen Windows felhasználói fiók bejelentkezése. A lehetséges okok és javasolt megoldások további megoldásaihoz lásd:
| Lehetséges ok | Javasolt megoldás |
|---|---|
| SQL Server hitelesítést próbálsz használni, de az SQL Server példány Windows hitelesítési módra van konfigurálva. | Ellenőrizd, hogy az SQL Server be van állítva, hogy SQL Server és Windows hitelesítési mód használja. Az SQL Server példányod hitelesítési módját az SQL Server instance Security oldalán a megfelelő instance Tulajdonságok menüjében az SQL Server Management Studio (SSMS) területén is áttekintheted és megváltoztathatod. További információért lásd: Szerver hitelesítési mód módosítása. Alternatívaként módosíthatod az alkalmazást Windows hitelesítési módra az SQL Serverhez való csatlakozáshoz. Megjegyzés: Az SQL Server hibanaplójában az alábbi üzenetet ebben a helyzetben láthatod: Login failed for user '<UserName>'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. |
| Egy csoporton keresztül próbálsz elérni az SQL Servert, és hibaüzenetet látsz. | Ha nincs meg a szükséges jogosultságod a szerverhez való hozzáféréshez, a szolgáltató "Bejelentkezés sikertelen volt a 'contoso/user1' felhasználó számára" hibaüzenetet jelenít meg. Használd a "Hozzáférés csoporton keresztül" funkciót, amely segít elérni egy szervert a csoporttagságod alapján. Amikor elfuttatod a tárolt xp_logininfo 'contoso/user1' eljárást, a következő előfordulhat:- Ha hibát látsz, az SQL Server egyáltalán nem tudja megoldani a felhasználónevet. Valószínű, hogy nincs név az Active Directory-ben (AD), vagy problémák vannak a domain vezérlőhöz (DC) való csatlakozásnál. Próbálj meg más néven ellenőrizni, hogy a probléma csak egy adott fiókra jellemző-e. - Ha egy doménmentes szerverhez csatlakozol, a csoportnak az SQL Server tartományban kell lennie, nem a felhasználói domainben, hogy a tagsága megoldható legyen. - Ha egy adatbázis-lekérdezés nem ad sorokat, az azt jelenti, hogy nincs olyan csoport, amely hozzáférést biztosítana a szerverhez. Ha egy lekérdezés egy vagy több sort ad vissza, az azt jelenti, hogy a felhasználó egy olyan csoporthoz tartozik, amely hozzáférést biztosít. A DBA kétszer is ellenőrizheti a jogosultságokat, ha megnézi az SQL Server Management Studio (SSMS) Security\Logins mappáját. A Security\Logins a létrehozott bejelentkezések listáját jeleníti meg. Ha egy zárt adatbázisról van szó, a DBA ellenőrizheti az Security\Logins (Security\Logins ) adatbázis nevét a bejelentkezések ellenőrzésére és kezelésére. További információért lásd: Felhasználói hozzáférési vezérlés és jogosultságok konfigurálása. |
| SQL bejelentkezések nincsenek engedélyezve | Az adatbázis-kezelő rendszer (DBMS) valamilyen változatot mutathat az Login failed for user '<username>' üzenetnek. A probléma megoldásához kövesse ezeket a lépéseket:1. Ellenőrizze, hogy az SQL Server hibanaplója tartalmazza-e a "Bejelentkezés sikertelen a felhasználó '<felhasználónév>' számára". Ok: SQL hitelesítéssel való bejelentkezési kísérlet sikertelen volt. A szerver csak Windows hitelesítésre van konfigurálva." 2. Használj az alábbi módszerek egyikét a hiba megoldására: - Integrált bejelentkezést használjunk. Például OLE DB szolgáltatók esetén adjunk INTEGRATED SECURITY=SSPI hozzá a csatlakozási lánchoz, az ODBC illesztőprogramok esetén pedig adjunk TRUSTED_CONNECTION=YEShozzá . A .NET szolgáltató mindkét szintaxist elfogadja.Jegyzet: Ez más problémákhoz vezethet, ha nem megfelelően konfigurálják az integrált hitelesítést, és külön problémaként kell vizsgálni. - SQL bejelentkezések engedélyezése a szerveren: a). Az SQL Server Management Studio-ban jobb kattintással az SQL Server nevére az Objektum Explorerben , és válaszd ki a Tulajdonságokat. b. A Biztonság panelben válaszd ki az SQL Server és Windows hitelesítési módot. c. Kattintson az OK gombra. d. Indítsd újra az SQL Servert, hogy a változás megtörténjen. Jegyzet: Ez más problémákhoz is vezethet, például SQL bejelentkezés meghatározásához. - Próbálj meg helyi Windows vagy domain fiókot megadni a felhasználónévhez. Csak SQL bejelentkezések engedélyezettek. Az alkalmazásnak integrált biztonságot kell használnia. |
| Bejelentkezés nincs azon az SQL Server példányon, amihez csatlakozni próbálsz. | Ellenőrizd, hogy létezik-e az SQL Server bejelentkezés, és hogy helyesen írtad be. Ha a bejelentkezés nem létezik, hozd létre. Ha jelen van, de rosszul van írva, javítsd ki az alkalmazás kapcsolati láncsorban. Az SQL Server hibanaplója az alábbi üzenetek egyikét fogja tartalmazni: - 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.Ez gyakori probléma lehet, ha olyan alkalmazást telepítesz, amely DEV vagy QA szervert használ, gyártásba kerül, és nem frissíted a kapcsolati láncot. Ennek a problémának a megoldásához ellenőrizd, hogy a megfelelő szerverhez csatlakozol. Ha nem, javítsd ki a csatlakozási láncot. Ha igen, adj hozzáférést az SQL Serveredhez. Vagy ha Windows bejelentkezésről van szó, közvetlenül engedélyez hozzáférést, vagy hozzáadja egy helyi vagy tartománycsoporthoz, amely csatlakozhat az adatbázis szerverhez. További információért lásd: Bejelentkezés létrehozása. |
| SQL Server hitelesítést használsz, de az SQL Server bejelentkezéshez megadott jelszó hibás. | Nézd meg az SQL hibanaplót, hogy olyan üzeneteket találjanak, mint például: "Ok: Jelszó nem egyezett meg a megadott bejelentkezésnél", hogy megerősítsd az okot. A probléma megoldásához használd a megfelelő jelszót az alkalmazásodban, vagy használj másik fiókot, ha nem emlékszel a jelszóra. Alternatívaként egyeztess az SQL Server adminisztrátoroddal, hogy visszaállítsd a fiók jelszavát. Ha az alkalmazás SQL Server Integration Services (SSIS), több konfigurációs fájl is lehet a feladathoz, amelyek felülírhatják a csomag Connection Manager beállításait. Ha az alkalmazást a céged írta, és a kapcsolati lánc programozott módon generálódott, vond fel a fejlesztőcsapatot a probléma megoldására. Ideiglenes megoldásként kódold keményen a csatlakozási láncsort és teszteld. Használj UDL fájlt vagy szkriptet, hogy bizonyítsd a kapcsolat lehetséges egy kemény kódolt kapcsolódási láncsal. |
| A kapcsolati lánc hibás szintaxissal, szervernévgel vagy felhasználói hitelességgel rendelkezik. | Ennek megoldásához kövesse ezeket a lépéseket:
|
| Bejelentkezés nélkül | Nézd meg, hogy az SQL Server megjeleníti-e a következő üzeneteket: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éhány hiba az Anonymous Logon fiókhoz tartozik. Ez a Kerberos ügyhöz kapcsolódik. Rossz kézi bejegyzés volt a HOSTS fájlban, vagyis rossz szervernevet adtak meg. A fennmaradó számok a következő kategóriákba sorolhatók:
|
| Windows hitelesítéssel próbálsz csatlakozni, de hibás domainbe vagy bejelentkezve. | Ellenőrizd, hogy megfelelően vagy bejelentkezve a megfelelő domainbe. A hibaüzenet általában a domain nevet mutatja. |
| Ellenőrizd az adatbázis-jogosultságokat | Az adatbázis nem jelenik meg offline az SQL Server Management Studio-ban. Más felhasználók, például a DBA, képesek csatlakozni hozzá. Az adott felhasználói fióknak kifejezetten hozzáférést kell kapnia az adatbázishoz, vagy fel kell illeszteni egy SQL Server szerepkörbe, vagy egy helyi Windows csoporthoz vagy domaincsoporthoz, amely hozzáfér az adatbázishoz. További információért lásd: CREATE USER, ALTER ROLE, és ALTER SERVER ROLE |
| Nem futtatod az alkalmazásodat (például SSMS-t) adminisztrátorként. | Ha az adminisztrátori igazolvással próbálsz csatlakozni, indítsd el az alkalmazást a Run as Administrator opcióval. Ha csatlakozik, add fel a Windows felhasználódat egyéni bejelentkezésként. |
| A bejelentkezést töröljük, miután egy tárolt adatbázis-felhasználóra migrálnak. | Ha az adatbázis motor támogatja a tárolt adatbázisokat, győződjön meg róla, hogy a bejelentkezés nem lett törölve a bevezetett adatbázis felhasználóra való migráció után. További információért lásd: Zárt adatbázis hitelesítés: Bevezetés. |
| A bejelentkezés alapértelmezett adatbázisa offline vagy egyébként nem elérhető. | Egyeztess az SQL Server adminisztrátoroddal, és oldd meg az adatbázis elérhetőségével kapcsolatos problémákat. Ha a bejelentkezés jogosultságokat tartalmaz más adatbázisokhoz a szerveren, és nem kell hozzáférned az alkalmazásban beállított alapértelmezett adatbázishoz, használd az alábbi opciók egyikét: - Kérje meg az adminisztrátort, hogy változtassa meg a bejelentkezés alapértelmezett adatbázisát ALTER LOGIN utasítással vagy SSMS-szel. - Explicit módon jelölj meg egy másik adatbázist az alkalmazáskapcsolati stringben. Vagy ha SSMS-t használsz, válts a Connection Properties fülre, hogy megadd a jelenleg elérhető adatbázist.Az SSMS-hez hasonló alkalmazások például a következőhöz hasonló hibaüzenetet mutathatnak: Cannot open user default database. Login failed.Login failed for user <user name>. (Microsoft SQL Server, Error: 4064)Az SQL Server hibanaplója hasonló hibaüzenetet fog tartalmazni: Login failed for user '<user name>'. Reason: Failed to open the database '<dbname>' specified in the login properties [CLIENT: <ip address>]További információért lásd: MSSQLSERVER_4064. |
| A kapcsolati láncsorban vagy az SSMS-ben kifejezetten megadott adatbázis helytelenül van írva, offline vagy egyébként nem elérhető. | - Javítsuk meg az adatbázis nevet a kapcsolati stringben. Figyelj a kis- és nagybetűérzékenységre, ha kis- és nagybetűérzékeny kollekciót használsz a szerveren. - Ha az adatbázis neve helyes, egyeztess az SQL Server adminisztrátoroddal, és oldd meg az adatbázis elérhetőségével kapcsolatos problémákat. Ellenőrizd, hogy az adatbázis offline-e, nem helyreállított-e, és így tovább. - Ha a bejelentkezést a szerveren lévő más adatbázisokhoz jogosult felhasználókhoz jelölték, és nem kell hozzáférned az alkalmazásban a jelenleg konfigurált adatbázishoz, akkor adj meg egy másik adatbázist a kapcsolati stringben. Vagy ha SSMS-hez csatlakozol, használd a Kapcsolat Tulajdonságai fület egy jelenleg elérhető adatbázis megadására. Az SQL Server hibanaplója hasonló hibaüzenetet fog tartalmazni: Login failed for user <UserName>. Reason: Failed to open the explicitly specified database 'dbname'. [CLIENT: <ip address>]Megjegyzés: Ha a bejelentkezés alapértelmezett adatbázisa elérhető, az SQL Server lehetővé teszi a kapcsolat sikeres működését. További információért lásd: MSSQLSERVER_4064. |
| A felhasználónak nincs engedélye a kért adatbázishoz. | - Próbálj meg egy másik rendszergazdálkodó felhasználóval kapcsolatba lépni, hogy lásd, létrejön-e a kapcsolat. - Hozzáférés biztosítása az adatbázishoz a megfelelő felhasználó létrehozásával (például, CREATE USER [<UserName>] FOR LOGIN [UserName]) |
Nézd meg a hibakódok részletes listáját a 18456-os hibakeresés oldalon.
További hibakeresési segítségért lásd: SQL kliens / szerver kapcsolati problémák hibakeresése.
Bejelentkezés sikertelen volt az NT AUTHORITY\ANONYMOUS LOGON felhasználónál
Legalább négy forgatókönyv van erre a problémára. A következő táblázatban vizsgáljuk meg az összes lehetséges okot, és használd a megfelelő felbontást: Lásd a táblázat alatti jegyzetet a dupla hop kifejezés magyarázatáért.
| Lehetséges okok | Javasolt határozatok |
|---|---|
| Próbálod átadni az NT LAN Manager (NTLM) hitelesedéseket egyik szolgáltatásról a másikra ugyanazon a számítógépen (például IIS-ről SQL Serverre), de a folyamat során hiba történik. | Add hozzá a DisableLoopbackCheck vagy BackConnectionHostNames adatbázis bejegyzéseket. |
| Több számítógépen is léteznek dupla ugrás (korlátozás delegálás) forgatókönyvek. A hiba akkor is előfordulhat, ha a Kerberos kapcsolat meghibásodik Szolgáltatásfőnevek (SPN) miatt. | Futtasd az SQLCheck-et minden SQL Serveren és a webszerveren. Használd a hibaelhárítási útmutatókat: 0600 Credential Delegation Issue és 0650 SQL Server Linked Server Delegation Issues. |
| Ha nincs dupla ugrás (korlátozási delegáció), akkor valószínűleg léteznek duplikált SPN-ek, és a kliens LocalSystem vagy más gépfiókként fut, amely NTLM hitelesítő adatokat kap Kerberos helyett. | Használd az SQLChecket vagy aSetspn.exe-t az SPN-hez kapcsolódó problémák diagnosztizálására és javítására. Nézd át továbbá a Kerberos Configuration Manager for SQL Server áttekintését is. |
| A Windows helyi biztonsági szabályzatát úgy lehetett, hogy megakadályozzák a gépfiók távoli hitelesítési kérések használatát. | Navigálj a Helyi Biztonsági Politika>Helyi Szabályzatok Biztonsági>Opciók Hálózati>biztonság: Engedélyezd a Helyi Rendszer számára, hogy használja a számítógép identitását NTLM-hez, válaszd az Engedélyezett opciót, ha a beállítás le van tiltva, majd válaszd az OK-t. Megjegyzés: Ahogy az Magyarázat fülön részletezzük, ez a szabályzat alapértelmezés szerint engedélyezett a Windows 7 és újabb verziókban. |
| A probléma időszakos előfordulása korlátozott delegáció esetén arra utalhat, hogy lejárt jegy van, amelyet a középső szint nem tud megújítani. Ez egy elvárt viselkedés akár összekapcsolt szerver esetén, akár bármely olyan alkalmazásnál, amely több mint 10 órán át tartóztatja a bejelentkezési ülést. | Változtasd meg a delegáció beállításait a középszintű szerveredben a Trust this computer for delegat for only megadott szolgáltatásokra – Használd a Kerberos Only for Trust this computer for delegating for only to stated services - Használj bármilyen protokollt. További információért lásd: SQL Server kapcsolt szerver dupla ugrás időszakos ANONIM BEJELENTKEZÉSE. |
| NTLM Peer bejelentkezés | Ez a hiba a Microsoft Windows operációs rendszer által használt NTLM hitelesítési protokollhoz kapcsolódik. Amikor olyan számítógépek között kommunikálsz, amelyek vagy munkaállomásokon vannak, vagy nem megbízható tartományokon vannak, mindkét gépen azonos fiókokat állíthatsz be, és NTLM peer hitelesítést használsz, NTLM Peer Login-t. A bejelentkezések csak akkor működnek, ha mindkét gépen egyezik a felhasználói fiók és a jelszó. |
| Visszacsatolás-védelem | A loopback védelem célja, hogy megakadályozza az alkalmazások más szolgáltatásokat hívni ugyanazon a gépen. Beállíthatod a DisableLoopbackCheck (preferált BackConnectionHostNames ) regisztrációs kulcsokat úgy, hogy ezt engedélyezzék. További információért lásd: Hibaüzenet, amikor megpróbálsz helyben elérni egy szervert a FQDN vagy CNAME alias használatával a Windows Server 2003 Service Pack 1 telepítése után: Hozzáférés megtagadva vagy Nem ismerte el a megadott hálózati utat. |
| Always-On Hallgatói Loopback védelem | Amikor a fő csomópontról csatlakozik a Always-On hallgatóhoz, a kapcsolat NTLM lesz. Ez aktiválja a Loopback Check-et, és "Bejelentkezés sikertelen" hibát eredményez, amely szerint a felhasználó egy nem megbízható domainről származik. Ennek a hibanak a megoldásához írja be a hallgató NETBIOS nevét és a teljes minősített nevet a BackConnectionHostNames regisztrációs kulcsba az összes Elérhetőségi Csoport gépén. További információért lásd: Hibaüzenet, amikor megpróbálsz helyben elérni egy szervert a FQDN vagy CNAME alias használatával a Windows Server 2003 Service Pack 1 telepítése után: Hozzáférés megtagadva vagy Nem ismerte el a megadott hálózati utat. |
| LANMAN kompatibilitási szint | Ez általában régebbi (Windows 2008 előtti) és újabb számítógépek között történik. Állítsd be a LANMAN kompatibilitási szintet 5-re minden számítógépen. Ez az NTLM v1-et is kitiltja. Kerberosra is válthatsz, hogy elkerüld ezt a problémát. |
| Érzékeny fiók | Néhány fiók az Active Directory-ban érzékenyként is meg lehet jelölve. Ezeket a fiókokat nem lehet átruházni egy másik szolgáltatásnak egy dupla átszállás során. |
| Nem korlátozott célpont | Ha egy adott szolgáltatásfióknál engedélyezik a korlátozott delegáció, a Kerberos megbukik, ha a célszerver SPN-je nincs a korlátozott delegáció célpontjainak listáján. |
| Per-Service-SID | Ez a funkció korlátozza a helyi kapcsolatokat arra, hogy NTLM-et használjanak, ne Kerberos hitelesítési módszerként. A szolgáltatás egyetlen ugrást is megtehet egy másik szerverre NTLM hitelesítő jelekkel, de nem lehet tovább delegálni korlátozott delegáció nélkül. |
| NTLM és korlátozott delegáció | Ha a célpont fájlmegosztás, akkor a középszintű szolgáltatási fiók delegációs típusának Constrained-Any-nek kell lennie, nem pedig korlátozott Kerberosnak. |
Megjegyzés:
A dupla ugrás általában a felhasználói jogosultságok delegálását több távoli számítógép között foglalja. Például tegyük fel, hogy van egy SQL Server példányod SQL1 néven, ahol létrehoztál egy linkelt szervert egy távoli SQL Server számára, amelynek neve SQL2. A linked server biztonsági konfigurációban kiválasztottad a Be a bejelentkezés aktuális biztonsági kontextusában létrehozható opciót. Ilyen konfigurációval használod, ha egy összekapcsolt szerver lekérdezést futtatsz SQL1-en egy Client1 nevű távoli kliensszámítógépről, a Windows hitelesítő adatainak először Client1-rőlSQL1-re , majd SQL1-rőlSQL2-re kell ugraniuk (ezért dupla ugrásnak hívják). További információért lásd: Kerberos dupla ugrás és Kerberos korlátozott delegáció áttekintése
Bejelentkezés sikertelen volt a felhasználónál (üres)
Ez a hiba akkor fordul elő, amikor a felhasználó sikertelenül próbál bejelentkezni. Ez a hiba akkor is előfordulhat, ha a számítógép nincs csatlakoztatva a hálózathoz. Például kaphat egy hibaüzenetet, amely a következőhöz hasonlít:
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.
Az üres string azt jelenti, hogy az SQL Server megpróbálta átadni a hitelesítéseket a Helyi Biztonsági Hatóság Alrendszeri Szolgáltatásának (LSASS), de valamilyen probléma miatt nem tudta megtenni. Vagy az LSASS nem volt elérhető, vagy a domain vezérlőt nem lehetett elérni.
A következő SSPI hibakódokat is láthatod:
Az SSPI kézfogás hibakóddal 0x80090311 hibával meghibásodott, miközben integrált biztonsági kapcsolatot hoztak létre; a kapcsolatot lezárták.
Az SSPI kézfogás hibás hibakóddal 0x80090304 volt, miközben integrált biztonsággal való kapcsolatot hoztak létre; a kapcsolatot lezárták.
Ezek a hibakódok a következőképpen fordíthatók:
Hiba -2146893039 (0x80090311): Nem lehetett felvenni a hitelesítéshez illetékes hatóságot. -2146893052 hiba (0x80090304): A helyi biztonsági hatóságot nem lehet elérni.
A hibák megoldásához lehasználhatod a hibás DC-t, vagy használhatod NLTEST.EXE-t a DC-k váltására.
- A DC-t kérdezni a parancs futtatására NLTEST /SC_QUERY:CONTOSO .
- A DC megváltoztatásához futtatd a NLTEST /SC_RESET:CONTOSO\DC03 parancsot.
Ha további segítségre van szüksége, vegye fel a kapcsolatot a Microsoft Active Directory csapatával.
Ellenőrizze a kliens és a szerver eseménynaplóit, hogy van-e hálózathoz vagy Active Directory kapcsolódó üzenet, amely a hiba idején történt. Ha találsz ilyet, dolgozz a domain administratoroddal a problémák megoldásáért.
Bejelentkezés sikertelen volt a '(null)' felhasználónál
A "null" jelzés azt jelentheti, hogy az LSASS nem tudja dekódolni a biztonsági tokent az SQL Server szolgáltatási fiók hitelesítési adataival. Ennek az állapotnak az elsődleges oka, hogy az SPN rossz fiókhoz van kötve.
A probléma megoldásához kövesse az alábbi lépéseket:
Használd az SQLCheck vagy Setspn.exe módszert az SPN-hez kapcsolódó problémák diagnosztizálására és javítására.
Az SQLCheck segítségével ellenőrizd, megbízható-e az SQL Service fiók delegálásához. Ha a kimenet azt mutatja, hogy a fiók nem megbízható delegációhoz, egyeztess az Active Directory adminisztrátoroddal, hogy engedélyezd a delegációt a fióknál.
Megjegyzés:
Az SETSPN -X és -Q parancsok hasznosak a duplikált vagy elhibázott SPN-ek ellenőrzésére.
Diagnosztizálni és javítani a DNS névfeloldási problémákat. Például:
PowerShell szkriptekkel pingelheted az IP-címet:
-
ping -a <your_target_machine>(kifejezetten IPv4 és-6IPv6 esetén használva-4) ping -a <your_remote_IPAddress>
-
Az NSLookup segítségével többször is megadja a helyi és távoli számítógép nevét és IP-címét.
Figyelj bármilyen eltérésre vagy eltérésre a visszaadott eredményekben. A DNS konfigurációjának pontossága a hálózaton fontos egy sikeres SQL Server kapcsolathoz. Egy hibás DNS-bejegyzés később számos kapcsolódási problémát okozhat.
Győződj meg róla, hogy a tűzfalak vagy más hálózati eszközök ne akadályozzák meg a kliensnek a domain vezérlőhöz való csatlakozását. Az SPN-ek az Active Directory-ban vannak tárolva. Ha az ügyfelek nem tudnak kommunikálni a könyvtárral, a kapcsolat nem sikerülhet.
További hibainformációk
A biztonság növelése érdekében a klienshez visszaküldött hibaüzenet szándékosan elrejti a hitelesítési hiba természetét. Azonban az SQL Server hibanaplójában egy hozzá tartozó hiba tartalmaz egy hibaállapotot, amely egy hitelesítési hiba állapotához hasonlít. Hasonlítsd össze a hibaállapotot az alábbi listával, hogy meghatározd a bejelentkezési hiba okát.
| Állam | Description |
|---|---|
| 1 | Hibainformáció nincs elérhető. Ez az állapot általában azt jelenti, hogy nincs engedélyed a hibaadatok megszerzésére. További információért keresse fel az SQL Server adminisztrátorát. |
| 2 | A felhasználói azonosító nem érvényes. |
| 5 | A felhasználói azonosító nem érvényes. |
| 6 | Megpróbáltak Windows bejelentkezési nevet használni SQL Server hitelesítéssel. |
| 7 | A bejelentkezés le van tiltva, és a jelszó hibás. |
| 8 | A jelszó hibás. |
| 9 | A jelszó nem érvényes. |
| 11 | A bejelentkezés érvényes, de a szerver hozzáférés meghibásodott. Ennek a hibának az egyik lehetséges oka, ha a Windows felhasználó a helyi adminisztrátorok csoportjának tagjaként hozzáfér az SQL Serverhez, de a Windows nem ad adandó adminisztrátori hitelesítményeket. A csatlakozáshoz indítsd el a csatlakozó programot a Run as administrator opcióval, majd add hozzá a Windows felhasználót az SQL Serverhez egy adott bejelentkezésként. |
| 12 | A bejelentkezés érvényes, de a szerver hozzáférés meghibásodott. |
| 18 | A jelszót meg kell változtatni. |
| 38, 46 | Nem találtam a felhasználó által kért adatbázist. |
| 58 | Amikor az SQL Server csak Windows hitelesítést használ, és egy kliens megpróbál SQL hitelesítéssel bejelentkezni. Egy másik ok, ha az SID-ek nem egyeznek. |
| 62 | Akkor fordul elő, amikor egy Windows hitelesítési fiók megpróbál hozzáférni egy tárolt adatbázishoz, és az adatbázis létezik, de a SID-ek nem egyeznek. |
| 102 - 111 | Azure AD hiba. |
| 122 - 124 | Hiba üres felhasználónév vagy jelszó miatt. |
| 126 | A felhasználó által kért adatbázis nem létezik. |
| 132 - 133 | Azure AD hiba. |
Más hibaállapotok is léteznek, amelyek váratlan belső feldolgozási hibát jeleznek.
Ritkább lehetséges ok
A hiba oka : SQL hitelesítéssel való bejelentkezési kísérlet sikertelen volt. A szerver csak Windows hitelesítésre van konfigurálva. a következő esetekben vissza lehet küldeni.
Amikor a szerver vegyes módú hitelesítésre van konfigurálva, és egy ODBC kapcsolat a TCP protokollt használja, és a kapcsolat nem határozza meg kifejezetten, hogy a kapcsolat megbízható kapcsolatot használja.
Amikor az SQL Server vegyes módú hitelesítésre van konfigurálva, és egy ODBC kapcsolat neves csöveket használ, és a kliens által használt hitelesítő adatok automatikusan utánozzák a felhasználót, és a kapcsolati lánc nem határozza meg kifejezetten a megbízható hitelesítés használatát.
Ennek a problémának a megoldásához a csatlakozási lánc beépítése TRUSTED_CONNECTION = TRUE a láncszálba.
Példák
Ebben a példában a hitelesítési hibaállapot 8. Ez azt jelzi, hogy a jelszó hibás.
| Date | Forrás | Message |
|---|---|---|
| 2007-12-05 20:12:56.34 | Logon | Hiba: 18456, súlyosság: 14, állam: 8. |
| 2007-12-05 20:12:56.34 | Logon | Bejelentkezés sikertelen volt a '<user_name>' felhasználónál. [ÜGYFÉL: <IP cím>] |
Megjegyzés:
Amikor az SQL Servert Windows hitelesítési módban telepítik, majd később SQL Server és Windows hitelesítési módra váltanak, a SA bejelentkezés kezdetben letiltott. Ez a 7-es állapotú hibát okozza: "Bejelentkezés sikertelen a 'sa' felhasználónál." A bejelentkezés engedélyezéséhez lásd: Szerver hitelesítési módjának módosítása.