Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
platí pro:
SQL Server
Podrobnosti
| Vlastnost | Hodnota |
|---|---|
| Název produktu | SQL Server |
| ID události | 18456 |
| Zdroj událostí | MSSQLSERVER |
| Součást | SQLEngine |
| Symbolický název | LOGON_FAILED |
| Text zprávy | Přihlášení neúspěšné pro uživatele '%.*ls'.%.*ls |
Explanation
Tuto chybovou zprávu dostanete, když je pokus o připojení zamítnut kvůli selhání autentizace. Přihlášení uživatelů může selhat z mnoha důvodů, například kvůli neplatným přihlašovacím údajům, vypršení hesla nebo zapnutí nesprávného autentizačního režimu. V mnoha případech chybové kódy obsahují popisy.
Akce uživatele
Následující příklady jsou některé z běžných neúspěchů při přihlášení. Vyberte přesně tu chybu, kterou zažíváte, abyste problém vyřešili:
Přihlášení selhalo pro uživatelské< jméno nebo nepřihlášení pro uživatelské jméno neúspěšné pro uživatelské jméno<<>>>
Pokud doménové jméno není specifikováno, problém je neúspěšný pokus o přihlášení do SQL Serveru. Pokud je doména specifikována, problém je v neúspěšném přihlášení uživatelského účtu Windows. Pro možné příčiny a navrhovaná řešení viz:
| Možná příčina | Navrhované řešení |
|---|---|
| Snažíte se použít SQL Server Authentication, ale instance SQL Serveru je nakonfigurována pro Windows Authentication režim. | Ověřte, že SQL Server je nakonfigurován pro použití SQL Server a Windows Authentication režimu. Režim ověřování pro vaši SQL Server instanci můžete zkontrolovat a změnit na stránce Bezpečnost v sekci Vlastnosti pro příslušnou instanci ve SQL Server Management Studio (SSMS). Pro více informací viz Změnit režim ověřování serveru. Alternativně můžete změnit aplikaci tak, aby používala režim Windows Authentication pro připojení k SQL Serveru. Poznámka: V SQL Server Error logu pro tento scénář můžete vidět zprávu podobnou této následující: Login failed for user '<UserName>'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. |
| Snažíte se přistupovat ke SQL Serveru přes skupinu a vidíte chybovou zprávu. | Pokud nemáte potřebná oprávnění k přístupu k serveru, poskytovatel zobrazí chybovou zprávu "Přihlášení neúspěšné pro uživatele 'contoso/user1'". Použijte funkci "Přístup přes skupinu", která vám umožní přistupovat k serveru na základě vašeho členství ve skupině. Když spustíte uloženou proceduru xp_logininfo 'contoso/user1' , může nastat následující:- Pokud vidíte chybu, SQL Server uživatelské jméno vůbec nedokáže vyřešit. Je pravděpodobné, že jméno není v Active Directory (AD) nebo mohou být problémy s připojením k doménovému řadiči (DC). Zkuste použít jiné jméno, abyste zjistili, jestli se problém týká konkrétního účtu. - Pokud se připojujete k serveru napříč doménami, skupina musí být v SQL Server doméně, nikoli v uživatelské doméně, aby bylo možné vyřešit její členství. - Když databázový dotaz nevrátí žádné řádky, znamená to, že neexistuje skupina, která by serveru poskytla přístup. Když dotaz vrátí jeden nebo více řádků, znamená to, že uživatel patří do skupiny, která poskytuje přístup. DBA může oprávnění zkontrolovat kontrolou ve složce Security\Logins ve SQL Server Management Studio (SSMS). Security\Logins zobrazuje seznam vytvořených přihlašovacích údajů. Pokud je databáze uzavřená, DBA může zkontrolovat Security\Logins pod názvem databáze, aby kontroloval a spravoval přihlášení. Pro více informací viz Konfigurace řízení přístupu uživatele a oprávnění. |
| SQL přihlášení není povoleno | Databázový systém správy (DBMS) může zobrazit určitou variantu zprávy Login failed for user '<username>' . Tuto chybu vyřešíte takto:1. Zkontrolujte, zda chybový log SQL Serveru obsahuje chybovou zprávu "Přihlášení neúspěšné pro uživatelské< jméno>". Důvod: Pokus o přihlášení pomocí SQL autentizace selhal. Server je nastaven pouze pro autentizaci Windows." 2. Použijte jednu z následujících metod k vyřešení chyby: - Používejte integrované přihlašovací údaje. Například pro poskytovatele OLE DB přidejte INTEGRATED SECURITY=SSPI do spojovacího řetězce a u ODBC ovladačů přidejte TRUSTED_CONNECTION=YES. Poskytovatel .NET přijímá obě syntaxe.Poznámka: To by mohlo vést k dalším problémům, pokud nejsou správně nastaveny pro integrovanou autentizaci a bude třeba je vyšetřovat jako samostatný problém. - Povolit přihlášení do SQL na serveru: a. V SQL Server Management Studio klikněte pravým tlačítkem na název SQL Serveru v Průzkumníku objektů a vyberte Vlastnosti. b) V panelu Bezpečnost vyberte režim ověřování SQL Server a Windows . c. Vyberte OK. d. Restartujte SQL Server a změna se může stát. Poznámka: To může vést k dalším problémům, například k definování SQL přihlášení. - Zkuste specifikovat lokální Windows účet nebo doménový účet pro uživatelské jméno. Povolené jsou pouze přihlášení do SQL. Aplikace by měla používat integrovanou bezpečnost. |
| Přihlášení neexistuje na instanci SQL Serveru, ke které se snažíte připojit. | Ověřte, že přihlášení k SQL Serveru existuje a že jste ho správně napsali. Pokud přihlášení neexistuje, vytvořte ho. Pokud je přítomný, ale špatně napsaný, opravte to v řetězci aplikace. SQL Server Errorlog bude obsahovat jednu z následujících zpráv: - 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.To může být běžný problém, pokud nasadíte aplikaci, která používá DEV nebo QA server, do produkce a neaktualizujete spojovací řetězec. Pro vyřešení tohoto problému ověřte, že se připojujete ke správnému serveru. Pokud ne, opravte spojovací řetězec. Pokud ano, udělte přihlašovací přístup ke svému SQL Serveru. Nebo pokud je to přihlášení do Windows, udělit přístup přímo nebo přidat do lokální či doménové skupiny, která se může připojit k databázovému serveru. Pro více informací viz Vytvořit přihlášení. |
| Používáte SQL Server Authentication, ale heslo, které jste zadali pro přihlášení do SQL Serveru, je nesprávné. | Zkontrolujte SQL chybový log, jestli nejsou zprávy jako "Důvod: Heslo se neshodovalo s tímto k uvedenému přihlašování", abyste potvrdili příčinu. Abyste problém vyřešili, použijte správné heslo ve své žádosti nebo použijte jiný účet, pokud si heslo nepamatujete. Případně spolupracujte se správcem SQL Serveru na resetování hesla k účtu. Pokud je aplikace SQL Server Integration Services (SSIS), může existovat více úrovní konfiguračního souboru pro danou úlohu, což může přepisovat nastavení Connection Manageru pro daný balíček. Pokud byla aplikace napsána vaší firmou a spojovací řetězec je programově generován, zapojte vývojový tým, aby problém vyřešil. Jako dočasné řešení natvrdo zakódujte spojovací řetězec a otestujte. Použijte soubor UDL nebo skript k prokázání, že spojení je možné pomocí pevně zakódovaného řetězce připojení. |
| Spojovací řetězec má nesprávnou syntaxi, název serveru nebo uživatelské přihlašovací údaje. | K vyřešení tohoto problému postupujte podle těchto kroků:
|
| Žádné přihlášení | Zkontrolujte, zda SQL Server zobrazuje následující zprávy: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ěkteré chyby patří účtu Anonymous Logon. To souvisí s otázkou Kerberosu. V souboru HOSTS byl špatný ruční záznam, tedy špatný název serveru. Zbývající otázky mohou spadat do následujících kategorií:
|
| Snažíte se připojit pomocí Windows autentizace, ale jste přihlášeni do nesprávné domény. | Ověřte, že jste správně přihlášeni do správné domény. Chybová zpráva obvykle zobrazuje doménové jméno. |
| Zkontrolujte oprávnění databáze | Databáze se v SQL Server Management Studio nezobrazuje offline. Ostatní uživatelé, například DBA, se k němu dokážou připojit. Uživatelský účet musí mít explicitní přístup k databázi nebo musí být přidán do role SQL Server či do lokální Windows či doménové skupiny, která má přístup k databázi. Pro více informací viz CREATE USER,ALTER ROLE a ALTER SERVER ROLE |
| Neprovozujete svou aplikaci (například SSMS) jako správce. | Pokud se snažíte připojit pomocí administrátorských přihlašovacích údajů, spusťte aplikaci pomocí možnosti Spustit jako správce . Po připojení přidejte uživatele Windows jako individuální přihlášení. |
| Přihlášení je smazáno po migraci na uživatele s uzavřenou databází. | Pokud databázový engine podporuje uzavřené databáze, ověřte, že přihlášení nebylo po migraci na uzavřeného uživatele databáze smazáno. Pro více informací viz Ověření v databázi: Úvod. |
| Výchozí databáze přihlášení je offline nebo jinak nedostupná. | Poraďte se se svým správcem SQL Serveru a vyřešte problémy týkající se dostupnosti databáze. Pokud má přihlášení oprávnění k jiným databázím na serveru a nemusíte přistupovat k aktuálně nakonfigurované výchozí databázi ve své aplikaci, použijte jednu z následujících možností: - Požádat správce o změnu výchozí databáze přihlášení pomocí příkazu ALTER LOGIN nebo SSMS. - Explicitně uveďte jinou databázi ve vašem řetězci připojení aplikace. Nebo pokud používáte SSMS, přepněte na záložku Vlastnosti připojení a zadejte databázi, která je aktuálně dostupná.Aplikace jako SSMS mohou zobrazovat chybovou hlášku podobnou této: Cannot open user default database. Login failed.Login failed for user <user name>. (Microsoft SQL Server, Error: 4064)SQL Server Errorlog bude mít chybovou zprávu podobnou té následující: Login failed for user '<user name>'. Reason: Failed to open the database '<dbname>' specified in the login properties [CLIENT: <ip address>]Pro více informací viz MSSQLSERVER_4064. |
| Databáze explicitně uvedená v řetězci spojení nebo v SSMS je nesprávně napsaná, offline nebo jinak nedostupná. | - Opravte název databáze v řetězci spojů. Dávejte pozor na citlivost na velká písmena, pokud používáte sortaci rozlišující písmena na serveru. - Pokud je název databáze správný, ověřte si u správce SQL Serveru a vyřešte problémy týkající se dostupnosti databáze. Zkontrolujte, jestli je databáze offline, neobnovená a podobně. - Pokud bylo přihlášení přiřazeno uživatelům s oprávněními k jiným databázím na serveru a nemusíte přistupovat k aktuálně konfigurované databázi ve své aplikaci, zadejte v rámci svého spojovacího řetězce jinou databázi. Nebo pokud se připojujete přes SSMS, použijte záložku Vlastnosti spojení k určení databáze, která je aktuálně dostupná. SQL Server Errorlog bude mít chybovou zprávu podobnou té následující: Login failed for user <UserName>. Reason: Failed to open the explicitly specified database 'dbname'. [CLIENT: <ip address>]Poznámka: Pokud je výchozí databáze přihlášení dostupná, SQL Server umožňuje připojení úspěšné. Pro více informací viz MSSQLSERVER_4064. |
| Uživatel nemá oprávnění k požadované databázi. | - Zkuste se připojit jako jiný uživatel s právy správce systému, abyste zjistili, zda lze navázat konektivitu. - Udělit přihlašovací přístup do databáze vytvořením odpovídajícího uživatele (například CREATE USER [<UserName>] FOR LOGIN [UserName]) |
Také si prohlédněte rozsáhlý seznam chybových kódů na stránce Troubleshooting Error 18456.
Pro více pomoci s diagnostikou viz Řešení problémů s připojením SQL klienta / serveru.
Přihlášení selhalo pro uživatele NT AUTHORITY\ANONYMOUS LOGON
Pro tento problém existují alespoň čtyři scénáře. V následující tabulce prostudujte každou vhodnou možnou příčinu a použijte vhodné rozlišení: Viz poznámka níže v tabulce pro vysvětlení termínu dvojitý skok.
| Možné příčiny | Navrhovaná usnesení |
|---|---|
| Snažíte se předávat NT LAN Manager (NTLM) přihlašovací údaje z jedné služby na druhou na stejném počítači (například z IIS do SQL Serveru), ale v procesu dojde k selhání. | Přidejte záznamy v registru DisableLoopbackCheck nebo BackConnectionHostNames . |
| Existují scénáře s dvojitým skokem (delegace omezení) napříč více počítači. Chyba může nastat, pokud připojení Kerberos selže kvůli problémům s názvy hlavních služeb (SPN). | Spusť SQLCheck na každém SQL Serveru i na webovém serveru. Použijte návody na řešení problémů: 0600 Problém s delegací přihlašovacích údajů a 0650 SQL Server Linked Server Delegace Problémů. |
| Pokud není zapojen dvojitý skok (delegace omezení), pravděpodobně existují duplicitní SPN a klient běží jako LocalSystem nebo jiný strojový účet, který získává NTLM přihlašovací údaje místo Kerberos. | Použijte SQLCheck nebo Setspn.exe k diagnostice a opravě problémů souvisejících se SPN. Také si přečtěte Přehled Kerberos Configuration Manager pro SQL Server. |
| Místní bezpečnostní politika Windows mohla být nakonfigurována tak, aby zabránila použití počítačového účtu pro požadavky na vzdálenou autentizaci. | Přejděte na Local Security Policy>Local Policy Security>Options Síťová>bezpečnost: Povolte lokálnímu systému používat identitu počítače pro NTLM, vyberte možnost Povolit , pokud je nastavení vypnuté, a poté vyberte OK. Poznámka: Jak je podrobně popsáno na záložce Vysvětlit , tato politika je ve Windows 7 a novějších verzích ve výchozím nastavení povolena. |
| Občasný výskyt tohoto problému při použití omezené delegace může naznačovat přítomnost expirovaného tiketu, který střední úroveň nemůže obnovit. Toto je očekávané chování buď u propojeného serveru, nebo u jakékoli aplikace, která drží přihlašovací relaci déle než 10 hodin. | Změňte nastavení delegace na vašem středně pokročilém serveru z Trust this computer for delegation only na specifikované služby – Použijte pouze Kerberos Only pro důvěru tomuto počítači pro delegaci pouze na specifikované služby – Použijte libovolný protokol. Pro více informací viz Přerušované ANONYMNÍ PŘIHLÁŠENÍ do SQL Server propojeného serveru double hop. |
| NTLM peer přihlášení | Tato chyba souvisí s NTLM autentizačním protokolem používaným operačním systémem Microsoft Windows. Při komunikaci mezi počítači, které jsou buď na pracovních stanicích, nebo v doménách, které si navzájem nedůvěřují, můžete na obou strojích nastavit identické účty a použít NTLM peer authentication NTLM Peer Login. Přihlášení funguje pouze tehdy, pokud se uživatelský účet i heslo shodují na obou zařízeních. |
| Ochrana zpětné smyčky | Ochrana zpětné smyčky je navržena tak, aby zabránila aplikacím volat jiné služby na stejném počítači. Můžete nastavit (preferované) klíče DisableLoopbackCheckBackConnectionHostNames registru tak, aby to umožňovaly. Pro více informací viz Chybová zpráva při pokusu o přístup k serveru lokálně pomocí jeho FQDN nebo aliasu CNAME po instalaci Windows Server 2003 Service Pack 1: Přístup zamítnut nebo Žádný poskytovatel sítě nepřijal danou síťovou cestu. |
| Always-On Ochrana smyčky posluchačů | Při připojení k Always-On Listeneru z primárního uzlu bude spojení NTLM. Tím se spustí Loopback Check a zobrazí se chyba "Přihlášení selhalo", která uvede, že uživatel pochází z nedůvěryhodné domény. Pro vyřešení této chyby zadejte název NETBIOS posluchače a plně kvalifikované jméno do registrového klíče BackConnectionHostNames na všech strojích ve skupině dostupnosti. Pro více informací viz Chybová zpráva při pokusu o přístup k serveru lokálně pomocí jeho FQDN nebo aliasu CNAME po instalaci Windows Server 2003 Service Pack 1: Přístup zamítnut nebo Žádný poskytovatel sítě nepřijal danou síťovou cestu. |
| Úroveň kompatibility LANMAN | To se obvykle děje mezi staršími počítači (před Windows 2008) a novějšími počítači. Nastavte úroveň kompatibility LANMAN na 5 na všech počítačích. To také zakazuje NTLM v1. Můžete také přepnout na Kerberos, abyste se tomuto problému vyhnuli. |
| Citlivý účet | Některé účty mohou být v Active Directory označeny jako citlivé. Tyto účty nelze v případě dvojitého skoku delegovat na jinou službu. |
| Není to omezený cíl | Pokud je omezená delegace povolena pro konkrétní servisní účet, Kerberos selže, pokud SPN cílového serveru není na seznamu cílů omezené delegace. |
| Per-Service-SID | Tato funkce omezuje lokální připojení na použití NTLM a ne Kerberosu jako autentizační metody. Služba může provést jeden skok na jiný server pomocí NTLM přihlašovacích údajů, ale nelze jej dále delegovat bez použití omezené delegace. |
| NTLM a omezená delegace | Pokud je cílem sdílená složka, musí být typ delegace středního servisního účtu Constrained-Any a ne Constrained-Kerberos. |
Poznámka:
Dvojitý skok obvykle zahrnuje delegaci uživatelských přihlašovacích údajů mezi více vzdálených počítačů. Například předpokládejme, že máte SQL Server instance jménem SQL1 , kde jste vytvořili propojený server pro vzdálený SQL Server jménem SQL2. V konfiguraci zabezpečení propojeného serveru jste zvolili možnost Be made s použitím aktuálního bezpečnostního kontextu přihlášení. Při použití této konfigurace, pokud provedete dotaz propojeného serveru na SQL1 z vzdáleného klientského počítače jménem Client1, musí Windows přihlašovací údaje nejprve přeskočit z Client1 do SQL1 a poté ze SQL1 do SQL2 (proto se tomu říká double-hop). Pro více informací viz Přehled Understanding Kerberos Double Hop and Kerberos Constrained Delegation
Přihlášení pro uživatele selhalo (prázdné)
Tato chyba nastává, když se uživatel neúspěšně pokusí přihlásit. Tato chyba může nastat, pokud váš počítač není připojen k síti. Například můžete obdržet chybovou zprávu, která se podobá následující:
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.
Prázdný řetězec znamená, že SQL Server se pokusil předat přihlašovací údaje Local Security Authority Subsystem Service (LSASS), ale kvůli nějakému problému se mu to nepodařilo. Buď nebyl LSASS dostupný, nebo nebylo možné kontaktovat doménový řadič.
Můžete také vidět následující odpovídající chybové kódy SSPI:
SSPI handshake selhal s chybovým kódem 0x80090311 při navazování spojení s integrovanou bezpečností; spojení bylo uzavřeno.
SSPI handshake selhal s chybovým kódem 0x80090304 při navazování spojení s integrovanou bezpečností; spojení bylo uzavřeno.
Tyto chybové kódy se překládají následovně:
Chyba -2146893039 (0x80090311): Nebylo možné kontaktovat žádnou autoritu pro ověření. Chyba -2146893052 (0x80090304): Místní bezpečnostní úřad nelze kontaktovat.
Pro vyřešení těchto chyb můžete problémový DC vypnout nebo použít NLTEST.EXE k přepnutí DC.
- Pro dotaz do DC spusťte NLTEST /SC_QUERY:CONTOSO příkaz.
- Pro změnu DC spusťte NLTEST /SC_RESET:CONTOSO\DC03 příkaz.
Pokud potřebujete další pomoc, kontaktujte tým Microsoft Active Directory.
Zkontrolujte logy událostí na klientovi a serveru, zda nejsou zaznamenány zprávy týkající se sítě nebo Active Directory, které byly zaznamenány v době selhání. Pokud nějaké najdete, spolupracujte se správcem domény, abyste problém vyřešili.
Přihlášení neúspěšné pro uživatele '(null)'
Označení "null" může znamenat, že LSASS nemůže dešifrovat bezpečnostní token pomocí přihlašovacích údajů k účtu SQL Server. Hlavním důvodem tohoto stavu je, že SPN je spojena se špatným účtem.
K vyřešení problému postupujte podle těchto kroků:
Použijte SQLCheck nebo Setspn.exe k diagnostice a opravě problémů souvisejících se SPN.
Použijte SQLCheck k ověření, zda je účet SQL Service důvěryhodný pro delegování. Pokud výstup ukazuje, že účet není důvěryhodný pro delegování, spolupracujte se správcem Active Directory na povolení delegace pro účet.
Poznámka:
Příkazy SETSPN -X a -Q jsou užitečné pro kontrolu duplicitních nebo ztracených SPN.
Diagnostikujte a opravte problémy s řešením DNS systému nájmen. Například:
Pingujte IP adresu pomocí PowerShell skriptů:
-
ping -a <your_target_machine>(použití-4konkrétně pro IPv4 a-6IPv6) ping -a <your_remote_IPAddress>
-
Použijte NSLopřipojení k několikrát zadání místního i vzdáleného názvu počítače a IP adresy.
Hledejte případné nesrovnalosti a nesoulady ve vrácených výsledcích. Přesnost DNS konfigurace v síti je důležitá pro úspěšné připojení k SQL Serveru. Nesprávný DNS záznam může později způsobit řadu problémů s připojením.
Ujistěte se, že firewally nebo jiná síťová zařízení neblokují klienta v připojení k doménovému řadiči. SPN jsou uloženy v Active Directory. Pokud klienti nemohou komunikovat s adresářem, spojení nemůže uspět.
Další informace o chybách
Pro zvýšení bezpečnosti chybová zpráva vrácená klientovi záměrně skrývá povahu chyby autentizace. V SQL Server error logu však odpovídající chyba obsahuje stav chyby, který se mapuje na podmínku selhání autentizace. Porovnejte stav chyby s následujícím seznamem, abyste zjistili důvod neúspěchu přihlášení.
| Stát | Description |
|---|---|
| 1 | Informace o chybách nejsou k dispozici. Tento stav obvykle znamená, že nemáte oprávnění přijímat údaje o chybě. Pro více informací kontaktujte svého správce SQL Serveru. |
| 2 | Uživatelské ID není platné. |
| 5 | Uživatelské ID není platné. |
| 6 | Byl učiněn pokus použít přihlašovací jméno Windows s ověřením SQL Server. |
| 7 | Přihlášení je deaktivované a heslo je nesprávné. |
| 8 | Heslo je nesprávné. |
| 9 | Heslo není platné. |
| 11 | Přihlášení je platné, ale přístup na server selhal. Jednou z možných příčin této chyby je, když má uživatel Windows přístup k SQL Serveru jako člen místní administrátorské skupiny, ale Windows neposkytuje administrátorské přihlašovací údaje. Pro připojení spusťte připojovací program pomocí možnosti Spustit jako správce a poté přidejte uživatele Windows do SQL Server jako konkrétní přihlašovací údaje. |
| 12 | Přihlášení je platné, ale přístup na server selhal. |
| 18 | Heslo musí být změněno. |
| 38, 46 | Nepodařilo se najít databázi požadovanou uživatelem. |
| 58 | Když je SQL Server nastaven pouze na Windows Authentication a klient se pokusí přihlásit pomocí SQL autentizace. Další příčinou je, když se SID neshodují. |
| 62 | Vzniká, když se Windows Authentication účet pokusí získat přístup k uzavřené databázi a ta existuje, ale SID se neshodují. |
| 102 - 111 | Azure AD failure. |
| 122 - 124 | Selhání kvůli prázdnému uživatelskému jménu nebo heslu. |
| 126 | Databáze požadovaná uživatelem neexistuje. |
| 132 - 133 | Azure AD failure. |
Existují i další chybové stavy, které znamenají neočekávanou vnitřní chybu zpracování.
Vzácnější možná příčina
Důvod chyby Pokus o přihlášení pomocí SQL autentizace selhal. Server je nastaven pouze pro autentizaci ve Windows. lze vrátit v následujících situacích.
Když je server nastaven pro autentizaci v režimu smíšeného režimu a ODBC připojení používá protokol TCP, spojení výslovně nespecifikuje, že by mělo použít důvěryhodné připojení.
Když je SQL Server nakonfigurován pro smíšené režimy autentizace a ODBC spojení používá pojmenované trubky, a přihlašovací údaje, které klient použil k otevření pojmenovaného potrubí, se automaticky používají k impersonaci uživatele, přičemž spojovací řetězec explicitně nespecifikuje použití důvěryhodné autentizace.
Pro vyřešení tohoto problému zahrňte TRUSTED_CONNECTION = TRUE do spojovacího řetězce.
Examples
V tomto příkladu je stav chyby autentizace 8. To naznačuje, že heslo je nesprávné.
| Date | Zdroj | Message |
|---|---|---|
| 2007-12-05 20:12:56.34 | Logon | Chyba: 18456, závažnost: 14, stát: 8. |
| 2007-12-05 20:12:56.34 | Logon | Přihlášení pro uživatele '<user_name>' selhalo. [KLIENT: <IP adresa>] |
Poznámka:
Když je SQL Server nainstalován v režimu Windows Authentication a později změněn na SQL Server a Windows Authentication režim, přihlášení se nejprve deaktivuje. To způsobuje chybu stavu 7: "Přihlášení neúspěšné pro uživatele 'sa'." Pro povolení přihlášení do SA viz Změnit režim autentizace serveru.