Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:
SQL Server
Szczegóły
| Attribute | Wartość |
|---|---|
| Nazwa produktu | SQL Server |
| Identyfikator zdarzenia | 18456 |
| Źródło zdarzenia | MSSQLSERVER |
| Składnik | SQLEngine |
| Nazwa symboliczna | LOGON_FAILED |
| Tekst wiadomości | Logowanie dla użytkownika '%.*ls' się nie powiodło.%.*ls |
Explanation
Pojawia się ten komunikat o błędzie, gdy próba połączenia zostaje odrzucona z powodu niepowodzenia uwierzytelniania. Logowania użytkowników mogą zawiódć z wielu powodów, takich jak nieprawidłowe dane uwierzytelniające, wygaśnięcie hasła czy włączenie niewłaściwego trybu uwierzytelniania. W wielu przypadkach kody błędów zawierają opisy.
Akcja użytkownika
Poniższe przykłady to jedne z najczęstszych błędów logowania. Wybierz dokładnie ten błąd, który napotykasz, aby rozwiązać problem:
Logowanie się nie powiodło dla użytkownika '<username>' lub nie udało się logowania dla użytkownika '<domena>\<username>'
Jeśli nazwa domeny nie jest określona, problemem jest nieudana próba logowania do SQL Server. Jeśli podana jest nazwa domeny, problemem jest nieudane logowanie użytkownika Windows. Możliwe przyczyny i proponowane rozwiązania zobacz:
| Potencjalna przyczyna | Sugerowane rozwiązanie |
|---|---|
| Próbujesz użyć uwierzytelniania SQL Server, ale instancja SQL Server jest skonfigurowana do trybu uwierzytelniania Windows. | Sprawdź, czy SQL Server jest skonfigurowany do obsługi SQL Server i trybu uwierzytelniania Windows. Możesz przejrzeć i zmienić tryb uwierzytelniania dla swojej instancji SQL Server na stronie Bezpieczeństwo w sekcji Właściwości dla odpowiedniej instancji w SQL Server Management Studio (SSMS). Więcej informacji można znaleźć w artykule Zmień tryb uwierzytelniania serwera. Alternatywnie możesz zmienić aplikację na tryb uwierzytelniania Windows do połączenia z SQL Server. Uwaga: Podobny komunikat możesz zobaczyć w logu błędów SQL Server dla tego scenariusza: Login failed for user '<UserName>'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. |
| Próbujesz uzyskać dostęp do SQL Server przez grupę i widzisz komunikat o błędzie. | Jeśli nie masz odpowiednich uprawnień, aby uzyskać dostęp do serwera, dostawca wyświetla komunikat o błędzie "Logowanie nieudane dla użytkownika 'contoso/user1'". Skorzystaj z funkcji "Dostęp przez grupę", która pozwala uzyskać dostęp do serwera na podstawie członkostwa w grupie. Podczas wykonywania procedury xp_logininfo 'contoso/user1' przechowywanej może wystąpić następujące rzeczy:- Jeśli zobaczysz błąd, SQL Server w ogóle nie jest w stanie rozwiązać nazwy użytkownika. Prawdopodobnie nie ma nazwy w Active Directory (AD) lub mogą wystąpić problemy z połączeniem z kontrolerem domeny (DC). Spróbuj użyć innej nazwy, aby sprawdzić, czy problem dotyczy konkretnego konta. - Jeśli łączysz się z serwerem międzydomenowym, grupa musi znajdować się w domenie SQL Server, a nie w domenie użytkownika, aby można było ustalić jej członkostwo. - Gdy zapytanie bazowe nie zwraca wierszy, oznacza to, że nie ma grupy zapewniającej dostęp do serwera. Gdy zapytanie zwraca jeden lub więcej wierszy, oznacza to, że użytkownik należy do grupy zapewniającej dostęp. DBA może podwójnie sprawdzić uprawnienia, sprawdzając folder Security\Logins w SQL Server Management Studio (SSMS). Security\Logins wyświetla listę utworzonych loginów. Jeśli baza danych jest zamknięta, DBA może sprawdzić Security\Logins pod nazwą bazy, aby sprawdzić i zarządzać logowaniami. Więcej informacji można znaleźć w sekcji Konfiguruj kontrolę dostępu użytkownika i uprawnienia. |
| Logowania SQL nie są włączone | System zarządzania bazą danych (DBMS) może wykazywać pewną wariację Login failed for user '<username>' wiadomości. Aby rozwiązać ten problem, wykonaj następujące kroki:1. Sprawdź, czy log błędów SQL Server zawiera komunikat o błędzie "Login failed for user '<username>'. Powód: Próba zalogowania się za pomocą uwierzytelniania SQL zakończyła się niepowodzeniem. Serwer jest skonfigurowany wyłącznie do uwierzytelniania Windows." 2. Użyj jednej z następujących metod do rozwiązania błędu: - Użyj zintegrowanego logowania. Na przykład dla dostawców OLE DB dodaj INTEGRATED SECURITY=SSPI do ciągu połączeń, a dla sterowników ODBC dodaj TRUSTED_CONNECTION=YES. Dostawca .NET akceptuje obie składnie.Nuta: Może to prowadzić do innych problemów, jeśli nie są poprawnie skonfigurowane do zintegrowanej uwierzytelniania i wymagają zbadania jako osobnego problemu. - Włączenie logowania SQL na serwerze: a. W SQL Server Management Studio kliknij prawym przyciskiem myszy na nazwę SQL Server w Eksploratorze Obiektów i wybierz Właściwości. b. W panelu Bezpieczeństwo wybierz tryby uwierzytelniania SQL Server i Windows . c. Kliknij przycisk OK. d. Zrestartuj SQL Server, aby zmiana nastąpiła. Nuta: Może to prowadzić do innych problemów, takich jak definiowanie logowania SQL. - Spróbuj określić lokalne konto Windows lub konto domenowe dla nazwy użytkownika. Dozwolone są tylko logowania SQL. Aplikacja powinna korzystać z zintegrowanego zabezpieczenia. |
| Logowanie nie istnieje na instancji SQL Server, do której próbujesz się połączyć. | Sprawdź, czy logowanie SQL Server istnieje i czy poprawnie je napisałeś. Jeśli login nie istnieje, utwórz go. Jeśli jest obecny, ale jest błędnie napisany, popraw to w ciągu aplikacji connection. Dziennik błędów SQL Server będzie zawierał jeden z następujących komunikatów: - 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 może być częsty problem, jeśli wdrożysz aplikację korzystającą z serwera DEV lub QA do produkcji i nie zaktualizujesz ciągu połączeń. Aby rozwiązać ten problem, sprawdź, czy łączysz się z odpowiednim serwerem. Jeśli nie, popraw ciąg połączeń. Jeśli tak, przyznaj dostęp do logowania do swojego SQL Servera. Albo jeśli to logowanie Windows, przyznaj bezpośredni dostęp lub dodaj go do lokalnej lub domenowej grupy, która może łączyć się z serwerem bazy danych. Więcej informacji można znaleźć w artykule Utworzenie logowania. |
| Używasz uwierzytelniania SQL Server, ale hasło, które podał do logowania SQL Server, jest błędne. | Sprawdź log błędów SQL pod kątem komunikatów typu "Powód: Hasło nie pasowało do podanego logowania", aby potwierdzić przyczynę. Aby rozwiązać problem, użyj poprawnego hasła w aplikacji lub użyj innego konta, jeśli nie pamiętasz hasła. Alternatywnie, współpracuj z administratorem SQL Server, aby zresetować hasło do konta. Jeśli aplikacją jest SQL Server Integration Services (SSIS), może istnieć kilka poziomów pliku konfiguracyjnego dla zadania, które mogą nadpisać ustawienia Menedżera Połączeń dla pakietu. Jeśli aplikacja została napisana przez Twoją firmę, a ciąg połączeń jest programowo generowany, zaangażuj zespół deweloperski do rozwiązania problemu. Jako tymczasowe obejście zakoduj na stałe ciąg połączeń i przetestuj. Użyj pliku UDL lub skryptu, aby udowodnić, że połączenie jest możliwe za pomocą na stałe zakodowanego ciągu połączeń. |
| Ciąg połączeń ma nieprawidłową składnię, nazwę serwera lub dane uwierzytelniające użytkownika. | Aby to rozwiązać, postępuj zgodnie z następującymi krokami:
|
| Brak logowania | Sprawdź, czy SQL Server wyświetla następujące komunikaty: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: ]Niektóre z błędów pochodzą z konta Anonimowego Logowania. To ma związek z problemem Kerberosa. W pliku HOSTS pojawił się błędny ręczny wpis, czyli podany błędny adres serwera. Pozostałe kwestie mogą należeć do następujących kategorii:
|
| Próbujesz połączyć się za pomocą uwierzytelniania Windows, ale jesteś zalogowany na błędną domenę. | Sprawdź, czy jesteś prawidłowo zalogowany na właściwą domenę. Komunikat o błędzie zwykle wyświetla nazwę domeny. |
| Sprawdź uprawnienia bazy danych | Baza danych nie pojawia się offline w SQL Server Management Studio. Inni użytkownicy, na przykład DBA, mogą się z nim połączyć. Konto użytkownika musi otrzymać jawny dostęp do bazy danych lub zostać dodane do roli SQL Server lub lokalnej grupy Windows lub domeny, która ma dostęp do bazy. Więcej informacji można znaleźć w CREATE USER,ALTER ROLE oraz ALTER SERVER ROLE |
| Nie uruchamiasz swojej aplikacji (na przykład SSMS) jako administrator. | Jeśli próbujesz połączyć się za pomocą swoich danych administratorskich, rozpocznij aplikację od opcji Uruchom jako administrator . Po połączeniu dodaj użytkownika Windows jako indywidualne logowanie. |
| Logowanie jest usuwane po migracji do użytkownika z zamkniętą bazą danych. | Jeśli silnik bazy danych obsługuje zawarte bazy danych, potwierdz, że logowanie nie zostało usunięte po migracji do użytkownika z zamkniętą bazą danych. Więcej informacji można znaleźć w artykule Contained Database Authentication: Introdukcja. |
| Domyślna baza danych logowania jest offline lub w inny sposób niedostępna. | Skontaktuj się z administratorem SQL Server i rozwiąż kwestie związane z dostępnością bazy danych. Jeśli logowanie ma uprawnienia do innych baz danych na serwerze i nie musisz uzyskiwać dostępu do obecnie skonfigurowanej domyślnej bazy danych w aplikacji, użyj jednej z następujących opcji: - Poproś administratora o zmianę domyślnej bazy danych logowania za pomocą instrukcji ALTER LOGIN lub SSMS. - Wyraźnie określ inną bazę danych w ciągu połączenia aplikacji. Albo jeśli używasz SSMS, przejdź do zakładki Właściwości połączenia , aby określić aktualnie dostępną bazę danych.Aplikacje takie jak SSMS mogą wyświetlać komunikat o błędzie, taki jak następujący: Cannot open user default database. Login failed.Login failed for user <user name>. (Microsoft SQL Server, Error: 4064)SQL Server Errorlog będzie miał komunikat o błędzie podobny do następującego: Login failed for user '<user name>'. Reason: Failed to open the database '<dbname>' specified in the login properties [CLIENT: <ip address>]Więcej informacji można znaleźć w MSSQLSERVER_4064. |
| Baza danych wyraźnie określona w ciągu połączenia lub w SSMS jest błędnie napisana, offline lub w inny sposób niedostępna. | - Popraw nazwę bazy danych w ciągu połączeń. Zwracaj uwagę na wielkość liter, jeśli używasz sortowania na serwerze z dużą literą. - Jeśli nazwa bazy danych jest poprawna, skontaktuj się z administratorem SQL Server i rozwiąż kwestie związane z dostępnością bazy danych. Sprawdź, czy baza danych jest offline, nie została odzyskana i tak dalej. - Jeśli logowanie zostało przypisane użytkownikom z uprawnieniami do innych baz danych na serwerze i nie musisz uzyskiwać dostępu do obecnie skonfigurowanej bazy danych w aplikacji, wtedy w ciągu połączeń określ inną bazę danych. Albo jeśli łączysz się z SSMS, użyj zakładki Właściwości połączenia , aby określić aktualnie dostępną bazę danych. SQL Server Errorlog będzie miał komunikat o błędzie podobny do następującego: Login failed for user <UserName>. Reason: Failed to open the explicitly specified database 'dbname'. [CLIENT: <ip address>]Uwaga: Jeśli domyślna baza danych logowania jest dostępna, SQL Server pozwala na powodzenie połączenia. Więcej informacji można znaleźć w MSSQLSERVER_4064. |
| Użytkownik nie ma uprawnień do żądanej bazy danych. | - Spróbuj połączyć się jako inny użytkownik posiadający prawa administratora systemu, aby sprawdzić, czy można nawiązać łączność. - Przyznanie logowania do bazy danych poprzez utworzenie odpowiedniego użytkownika (na przykład CREATE USER [<UserName>] FOR LOGIN [UserName]) |
Sprawdź także obszerną listę kodów błędów w sekcji Troubleshooting Error 18456.
Więcej pomocy w rozwiązywaniu problemów znajdziesz w artykule Rozwiązywanie problemów z połączeniem klienta SQL / serwera.
Zalogowanie się nie udało dla użytkownika NT AUTHORITY\ANONYMOUS LOGON
Istnieją co najmniej cztery scenariusze tego problemu. W poniższej tabeli przeanalizuj każdą potencjalną przyczynę i użyj odpowiedniej rozdzielczości: Zobacz notatkę poniżej tabeli, aby wyjaśnić pojęcie podwójnego skoku.
| Potencjalne przyczyny | Proponowane postanowienia |
|---|---|
| Próbujesz przekazać poświadczenia NT LAN Manager (NTLM) z jednej usługi do drugiej na tym samym komputerze (na przykład: z IIS do SQL Server), ale w tym procesie następuje awaria. | Dodaj wpisy rejestru DisableLoopbackCheck lub BackConnectionHostNames . |
| Istnieją scenariusze podwójnego skoku (delegacja ograniczeń) na wielu komputerach. Błąd może wystąpić, jeśli połączenie Kerberos zawiodło z powodu problemów z nazwami głównych usług (SPN). | Uruchom SQLCheck na każdym SQL Server i serwerze WWW. Skorzystaj z poradników rozwiązywania problemów: 0600 Problem z delegowaniem poświadczeń oraz 0650 SQL Server Linked Server Delegowanie Problemów. |
| Jeśli nie ma podwójnego skoku (delegacji ograniczeń), prawdopodobnie istnieją duplikaty SPN, a klient działa jako konto LocalSystem lub inne konto maszynowe, które otrzymuje dane uwierzytelniające NTLM zamiast Kerberos. | Użyj SQLCheck lub Setspn.exe , aby zdiagnozować i naprawić wszelkie problemy związane ze SPN. Zapoznaj się także z przeglądem Menedżera konfiguracji Kerberos dla SQL Server. |
| Polityka bezpieczeństwa lokalnego Windows mogła być skonfigurowana tak, aby uniemożliwić korzystanie z konta maszyny do żądań zdalnej autoryzacji. | Przejdź do Lokalnej Polityki>Polityki>Lokalne Opcje>Bezpieczeństwa Bezpieczeństwo sieci: Pozwól Lokalnemu Systemowi używać tożsamości komputera dla NTLM, wybierz opcję Włącz, jeśli ustawienie jest wyłączone, a następnie wybierz OK. Uwaga: Jak szczegółowo opisano na zakładce Wyjaśnij , ta polityka jest domyślnie włączona w Windows 7 i nowszych. |
| Okresowe wystąpienia tego problemu przy użyciu ograniczonej delegacji mogą wskazywać na obecność wygasłego zgłoszenia, którego nie można odnowić przez średni tier. Jest to oczekiwane zachowanie zarówno w scenariuszu serwera połączonego, jak i w każdej aplikacji, która utrzymuje sesję logowania dłużej niż 10 godzin. | Zmień ustawienia delegacji na swoim serwerze średniej klasy z Zaufaj temu komputerowi tylko do określonych usług – Użyj tylko Kerberosa , aby zaufać temu komputerowi do delegowania tylko do określonych usług – Użyj dowolnego protokołu. Więcej informacji można znaleźć w artykule Intermittent ANONYMOUS LOGON do SQL Server linked server double hop. |
| Logowanie równocześnicze NTLM | Błąd ten jest związany z protokołem uwierzytelniania NTLM używanym przez system Microsoft Windows. Podczas komunikacji między komputerami znajdującymi się na stacjach roboczych lub w domenach, które sobie nie ufają, możesz skonfigurować identyczne konta na obu maszynach i użyć NTLM peer authentication NTLM Peer Login. Logowania działają tylko wtedy, gdy zarówno konto użytkownika, jak i hasło są zgodne na obu urządzeniach. |
| Ochrona przed pętlą zwrotną | Ochrona pętli zwrotnej ma na celu uniemożliwienie aplikacjom wywoływania innych usług na tym samym komputerze. Możesz ustawić klucze DisableLoopbackCheck rejestru lub BackConnectionHostNames (preferowane), aby to umożliwić. Aby uzyskać więcej informacji, zobacz komunikat o błędzie przy próbie lokalnego dostępu do serwera za pomocą jego FQDN lub aliasu CNAME po zainstalowaniu Windows Server 2003 Service Pack 1: Dostęp odrzucony lub Żaden dostawca sieci nie zaakceptował danej ścieżki sieciowej. |
| Always-On Ochrona przed pętlą słuchaczy | Podczas łączenia z Always-On Listener z węzła głównego, połączenie będzie NTLM. To uruchamia Loopback Check i powoduje błąd "Logowanie się nie powiodło", informując, że użytkownik pochodzi z domeny nieufnej (nieufnej domeny). Aby rozwiązać ten błąd, wpisz nazwę NETBIOS nasłuchiwacza oraz w pełni kwalifikowaną nazwę do klucza BackConnectionHostNames rejestru na wszystkich maszynach w Grupie Dostępności. Aby uzyskać więcej informacji, zobacz komunikat o błędzie przy próbie lokalnego dostępu do serwera za pomocą jego FQDN lub aliasu CNAME po zainstalowaniu Windows Server 2003 Service Pack 1: Dostęp odrzucony lub Żaden dostawca sieci nie zaakceptował danej ścieżki sieciowej. |
| Poziom kompatybilności z LANMAN | Zazwyczaj dzieje się to między starszymi komputerami (przed Windows 2008) a nowszymi. Ustaw poziom kompatybilności LANMAN na 5 na wszystkich komputerach. To również uniemożliwia NTLM v1. Możesz też przełączyć się na Kerberos, żeby uniknąć tego problemu. |
| Wrażliwe konto | Niektóre konta mogą być oznaczone jako Wrażliwe w Active Directory. Tych kont nie można delegować innej usłudze w scenariuszu podwójnego skoku. |
| Nie jest to ograniczony cel | Jeśli dla konkretnego konta usługi jest włączona delegacja z ograniczeniem, Kerberos nie zawie, jeśli SPN serwera docelowego nie znajduje się na liście celów delegacji ograniczonej. |
| Per-Service-SID | Ta funkcja ogranicza lokalne połączenia do używania NTLM, a nie Kerberos jako metody uwierzytelniania. Usługa może wykonać pojedynczy skok do innego serwera za pomocą poświadczeń NTLM, ale nie można go dalej delegować bez użycia ograniczonej delegacji. |
| NTLM i delegacja z ograniczeniami | Jeśli celem jest udostępnienie plików, typ delegacji konta usługi średniej klasy musi być Constrained-Any, a nie Constrained-Kerberos. |
Uwaga / Notatka
Podwójny skok zazwyczaj polega na delegowaniu danych uwierzytelniających użytkownika na wiele zdalnych komputerów. Na przykład, załóżmy, że masz instancję SQL Server o nazwie SQL1 , w której utworzyłeś połączony serwer dla zdalnego SQL Server o nazwie SQL2. W konfiguracji zabezpieczeń serwera połączonego wybierasz opcję Be made używając aktualnego kontekstu zabezpieczeń logowania. W tej konfiguracji, jeśli wykonasz zapytanie serwera powiązanego w SQL1 z komputera zdalnego klienta o nazwie Client1, dane poświadczenia Windows najpierw muszą przeskoczyć z Client1 do SQL1 , a następnie z SQL1 do SQL2 (stąd nazywa się to podwójnym skokem). Więcej informacji można znaleźć w artykule Understanding Kerberos Double Hop and Kerberos Constrained Delegation Overview
Zalogowanie użytkownika (puste)
Błąd ten występuje, gdy użytkownik próbuje bezskutecznie się zalogować. Ten błąd może wystąpić, jeśli Twój komputer nie jest podłączony do sieci. Na przykład możesz otrzymać komunikat o błędzie przypominający następujący:
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.
Pusty ciąg oznacza, że SQL Server próbował przekazać dane uwierzytelniające do Local Security Authority Subsystem Service (LSASS), ale nie udało się tego z powodu jakiegoś problemu. Albo LSASS nie było dostępne, albo kontroler domeny nie był dostępny za pomocą kontaktu.
Możesz również zobaczyć następujące odpowiadające kody błędów SSPI:
Ustawa SSPI nie powiodła się z kodem błędu 0x80090311 podczas nawiązywania połączenia z zintegrowanym zabezpieczeniem; Połączenie zostało zamknięte.
Utrzask SSPI zawiódł z kodem błędu 0x80090304 podczas nawiązywania połączenia z zintegrowanym zabezpieczeniem; Połączenie zostało zamknięte.
Te kody błędów tłumaczą się następująco:
Błąd -2146893039 (0x80090311): Nie udało się skontaktować z żadnym organem w celu uwierzytelnienia. Błąd -2146893052 (0x80090304): Nie można skontaktować się z Lokalnym Urzędem Bezpieczeństwa.
Aby rozwiązać te błędy, możesz wyłączyć problematyczny kontroler lub użyć NLTEST.EXE do przełączania kontrolerów.
- Aby zapytać do kontrolera danych, wykonaj polecenie NLTEST /SC_QUERY:CONTOSO .
- Aby zmienić DC, wykonaj polecenie NLTEST /SC_RESET:CONTOSO\DC03 .
Jeśli potrzebujesz dalszej pomocy, skontaktuj się z zespołem Microsoft Active Directory.
Sprawdź dzienniki zdarzeń na kliencie i serwerze pod kątem wiadomości związanych z siecią lub Active Directory, które zostały zarejestrowane w czasie awarii. Jeśli coś znajdziesz, współpracuj z administratorem domeny, aby rozwiązać problemy.
Logowanie dla użytkownika '(null)' się nie powiodło
Wskazanie "null" może oznaczać, że LSASS nie może odszyfrować tokena bezpieczeństwa za pomocą danych uwierzytelniających konta SQL Server. Głównym powodem tego stanu jest to, że SPN jest powiązany z niewłaściwym kontem.
Aby rozwiązać ten problem, wykonaj następujące kroki:
Użyj SQLCheck lub Setspn.exe , aby zdiagnozować i naprawić problemy związane z SPN.
Użyj SQLCheck , aby sprawdzić, czy konto SQL Service jest zaufane do delegowania. Jeśli wyjście wskazuje, że konto nie jest zaufane do delegowania, współpracuj z administratorem Active Directory, aby umożliwić delegację dla konta.
Uwaga / Notatka
I SETSPN -X-Q są użytecznymi poleceniami do sprawdzania duplikatów lub błędnych SPN.
Zdiagnozuj i napraw problemy z systemem nazw domen (DNS). Przykład:
Pinguj adres IP za pomocą skryptów PowerShell:
-
ping -a <your_target_machine>(zastosowanie-4w szczególności dla IPv4 i-6IPv6) ping -a <your_remote_IPAddress>
-
Użyj NSLookup , aby wielokrotnie wprowadzać nazwę i adres IP lokalnego i zdalnego komputera.
Zwróć uwagę na wszelkie rozbieżności i niezgodności w zwróconych wynikach. Dokładność konfiguracji DNS w sieci jest kluczowa dla udanego połączenia z SQL Server. Błędne wpisanie DNS może później spowodować liczne problemy z łącznością.
Upewnij się, że zapory sieciowe lub inne urządzenia sieciowe nie blokują klienta przed połączeniem się z kontrolerem domeny. SPN są przechowywane w Active Directory. Jeśli klienci nie mogą komunikować się z katalogiem, połączenie nie może się powieść.
Dodatkowe informacje o błędach
Aby zwiększyć bezpieczeństwo, komunikat o błędzie zwracany do klienta celowo ukrywa charakter błędu uwierzytelniania. Jednak w logu błędów SQL Server odpowiadający mu błąd zawiera stan błędu, który odpowiada warunkowi awarii uwierzytelniania. Porównaj stan błędu z poniższą listą, aby ustalić przyczynę niepowodzenia logowania.
| State | Description |
|---|---|
| 1 | Informacje o błędach nie są dostępne. Ten stan zwykle oznacza, że nie masz zgody na otrzymywanie szczegółów błędu. Skontaktuj się z administratorem SQL Server, aby uzyskać więcej informacji. |
| 2 | Identyfikator użytkownika nie jest ważny. |
| 5 | Identyfikator użytkownika nie jest ważny. |
| 6 | Podjęto próbę użycia nazwy logowania Windows z uwierzytelnieniem SQL Server. |
| 7 | Logowanie jest wyłączone, a hasło jest błędne. |
| 8 | Hasło jest błędne. |
| 9 | Hasło nie jest ważne. |
| 11 | Logowanie jest ważne, ale dostęp do serwera się nie powiódł. Jedną z możliwych przyczyn tego błędu jest sytuacja, gdy użytkownik Windows ma dostęp do SQL Server jako członek lokalnej grupy administratorów, ale Windows nie udostępnia danych danych uwierzytelniających administratora. Aby się połączyć, uruchom program łączący za pomocą opcji Uruchom jako administrator , a następnie dodaj użytkownika Windows do SQL Server jako konkretne logowanie. |
| 12 | Logowanie jest prawidłowe, ale dostęp do serwera zawiódł. |
| 18 | Hasło musi zostać zmienione. |
| 38, 46 | Nie udało się znaleźć bazy danych żądanej przez użytkownika. |
| 58 | Gdy SQL Server jest ustawiony wyłącznie na uwierzytelnianie Windows, a klient próbuje zalogować się za pomocą uwierzytelniania SQL. Inną przyczyną jest sytuacja, gdy SID się nie pokrywają. |
| 62 | Występuje, gdy konto Windows Authentication próbuje uzyskać dostęp do zawartej bazy danych, a zawarta baza istnieje, ale SID-y nie są zgodne. |
| 102 - 111 | Azure AD failure. |
| 122 - 124 | Awaria z powodu pustej nazwy użytkownika lub hasła. |
| 126 | Baza danych żądana przez użytkownika nie istnieje. |
| 132 - 133 | Azure AD failure. |
Istnieją inne stany błędu, które oznaczają nieoczekiwany wewnętrzny błąd przetwarzania.
Rzadsza możliwa przyczyna
Przyczyna błędu : Próba logowania za pomocą uwierzytelniania SQL zakończyła się niepowodzeniem. Serwer jest skonfigurowany wyłącznie do uwierzytelniania Windows. mogą być zwrócone w następujących sytuacjach.
Gdy serwer jest skonfigurowany do uwierzytelniania trybów mieszanych, a połączenie ODBC używa protokołu TCP, połączenie nie określa wprost, że połączenie powinno korzystać z zaufanego połączenia.
Gdy SQL Server jest skonfigurowany do uwierzytelniania w trybie mieszanym, a połączenie ODBC używa nazwanych potoków, a dane uwierzytelniające użyte przez klienta do otwarcia nazwanego pociągu są automatycznie używane do podszywania się pod użytkownika, a ciąg połączenia nie określa wyraźnie użycia zaufanej uwierzytelniania.
Aby rozwiązać ten problem, dodaj TRUSTED_CONNECTION = TRUE w ciągu połączeń.
Przykłady
W tym przykładzie stan błędu uwierzytelniania wynosi 8. To wskazuje, że hasło jest błędne.
| Date | Źródło | Message |
|---|---|---|
| 2007-12-05 20:12:56.34 | Logon | Błąd: 18456, Stopień nasilenia: 14, Stan 8. |
| 2007-12-05 20:12:56.34 | Logon | Logowanie użytkownika '<user_name>' się nie powiodło. [KLIENT: <adres> IP] |
Uwaga / Notatka
Gdy SQL Server jest instalowany w trybie uwierzytelniania Windows, a następnie zmieniany na SQL Server i tryb uwierzytelniania Windows, logowanie sa jest początkowo wyłączone. Powoduje to błąd stanu 7: "Logowanie dla użytkownika 'sa' się nie powiodło." Aby włączyć logowanie SA , zobacz Zmień tryb uwierzytelniania serwera.