Udostępnij za pośrednictwem

Spójne problemy z uwierzytelnianiem w programie SQL Server

  • Artykuł

Dotyczy: SQL Server

Uwaga 16.

Polecenia podane w tym artykule dotyczą tylko systemów Windows.

Spójne problemy z uwierzytelnianiem występujące w programie Microsoft SQL Server są zwykle związane z uwierzytelnianiem i autoryzacją użytkowników lub aplikacji, które próbują uzyskać dostęp do bazy danych programu SQL Server. Te problemy mogą być błędami uwierzytelniania, błędami odmowy dostępu lub innymi problemami związanymi z zabezpieczeniami.

Kluczem do efektywnego rozwiązywania spójnych problemów z uwierzytelnianiem jest zrozumienie różnych typów błędów i znaczenie każdego komunikatu o błędzie. Niektóre błędy mogą występować w więcej niż jednym problemie z uwierzytelnianiem. Aby rozwiązać ten problem, możesz użyć informacji dotyczących rozwiązywania problemów wymienionych w sekcji Typy błędów .

Wymagania wstępne

Przed rozpoczęciem rozwiązywania problemów zapoznaj się z listą kontrolną wymagań wstępnych, aby przygotować następujące informacje:

Typy błędów

W tej sekcji opisano typy błędów i powiązane informacje.

  • Błędy usług katalogowych: jeśli plik dziennika błędów programu SQL Server zawiera oba następujące komunikaty, ten błąd jest związany z usługami domena usługi Active Directory (AD DS). Ten błąd może również wystąpić, jeśli system Windows na komputerze opartym na programie SQL Server nie może skontaktować się z kontrolerem domeny (DC) lub jeśli usługa podsystemu lokalnego urzędu zabezpieczeń (LSASS) napotka problem.

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

  • Błędy logowania nie powiodły się: podczas rozwiązywania problemów z błędem "Logowanie nie powiodło się" dziennik błędów programu SQL Server zawiera dodatkowe szczegółowe informacje o kodzie błędu 18456, w tym określoną wartość stanu, która oferuje więcej kontekstu na temat błędu. Aby uzyskać więcej informacji, zobacz plik dziennika błędów programu SQL Server w wartości stanu SQL. Możesz spróbować rozwiązać problem zgodnie z opisem wartości stanu.

    W poniższej tabeli wymieniono określone komunikaty o błędach "Logowanie nie powiodło się" oraz ich możliwe przyczyny i rozwiązania.

    Komunikat o błędzie Więcej informacji
    "Wystąpił błąd na poziomie transportu podczas wysyłania żądania do serwera". Sprawdź, czy mapowanie połączonego konta serwera jest poprawne. Aby uzyskać więcej informacji, zobacz sp_addlinkedsrvlogin.
    "Nie można wygenerować kontekstu SSPI"
    "Nie można otworzyć testu> bazy danych <żądanego podczas logowania. Logowanie nie powiodło się”. Baza danych może być w trybie offline lub uprawnienia mogą nie być wystarczające. Aby uzyskać więcej informacji, zobacz Baza danych w trybie offline w MSSQLSERVER_18456.
    Sprawdź również, czy nazwa bazy danych w parametry połączenia jest poprawna.
    "Logowanie nie powiodło się dla nazwy użytkownika> użytkownika<". Ten błąd może wystąpić, jeśli konto serwera proxy nie zostało poprawnie uwierzytelnione.
    "Logowanie użytkownika nie powiodło się: 'NT AUTHORITY\ANONYMOUS LOGON'" Ten błąd może wystąpić, jeśli brakuje nazwy SPN, nazwa SPN jest zduplikowana lub nazwa SPN znajduje się na nieprawidłowym koncie.
    "Logowanie nie powiodło się dla nazwy użytkownika> użytkownika<".
    "Logowanie użytkownika "<database\username>" nie powiodło się
    		 Sprawdź, czy parametry połączenia zawiera nieprawidłową nazwę serwera. Sprawdź również, czy użytkownik należy do grupy lokalnej używanej do udzielania dostępu do serwera. Aby uzyskać więcej przyczyn, zobacz NT AUTHORITY\ANONYMOUS LOGON.
    "Logowanie użytkownika '<username>' nie powiodło się. Przyczyna: Hasło nie pasuje do podanego identyfikatora logowania". Ten błąd może wystąpić, jeśli jest używane nieprawidłowe hasło. Aby uzyskać więcej informacji, zobacz Logowanie użytkownika "<nazwa użytkownika>" nie powiodło się lub logowanie użytkownika "<nazwa użytkownika> domeny><" nie powiodło się.
    "Program SQL Server nie istnieje lub odmowa dostępu". Połączenia nazwanych potoków kończą się niepowodzeniem, ponieważ użytkownik nie ma uprawnień do logowania się do systemu Windows.
    "Logowanie pochodzi z niezaufanej domeny i nie można jej używać z uwierzytelnianiem systemu Windows". Ten błąd może być związany z problemami z podsystemem zabezpieczeń lokalnych.
    "Konto użytkownika nie jest dozwolone dla typu logowania sieciowego". Może nie być możliwe zalogowanie się do sieci.

Typy spójnych problemów z uwierzytelnianiem

W tej sekcji opisano typowe przyczyny spójnych problemów z uwierzytelnianiem wraz z odpowiednimi rozwiązaniami. Wybierz typ problemu, aby wyświetlić odpowiednie problemy, przyczyny i rozwiązania.

Parametry połączenia

W tej sekcji wymieniono problemy związane z ustawieniami konfiguracji używanymi przez aplikacje do nawiązywania połączenia z bazą danych.

Baza danych

W tej sekcji wymieniono problemy specyficzne dla różnych aspektów programu SQL Server:

  • Baza danych jest w trybie offline — odnosi się do scenariusza, w którym baza danych programu SQL Server próbuje ponownie nawiązać połączenie z wystąpieniem programu SQL Server skonfigurowanym dla trybu uwierzytelniania systemu Windows.

    Rozwiązanie: Aby uzyskać więcej informacji, zobacz MSSQLSERVER_18456.

  • Uprawnienia bazy danych — odnosi się do włączania lub ograniczania dostępu do bazy danych programu SQL Server.

    Rozwiązanie: Aby uzyskać więcej informacji, zobacz MSSQLSERVER_18456.

  • Błędy łączności serwera połączonego w programie SQL Server — występuje problem z procesem uwierzytelniania, który ma wpływ na połączone serwery w kontekście programu SQL Server.

    Rozwiązanie: Aby rozwiązać ten problem, zobacz Błędy łączności serwera połączonego w programie SQL Server.

  • Metadane połączonego serwera są niespójne — odwołuje się do problemu, w którym metadane połączonego serwera są niespójne lub nie są zgodne z oczekiwanymi metadanymi.

    Widok lub procedura składowana wysyła zapytanie do tabel lub widoków na serwerze połączonym, ale odbiera błędy logowania, mimo że instrukcja rozproszona SELECT skopiowana z procedury nie.

    Ten problem może wystąpić, jeśli widok został utworzony, a następnie serwer połączony został ponownie utworzony lub tabela zdalna została zmodyfikowana bez ponownego kompilowania widoku.

    Rozwiązanie: Odśwież metadane połączonego serwera, uruchamiając procedurę składowaną sp_refreshview .

  • Konto serwera proxy nie ma uprawnień — zadanie usługi SQL Server Integration Service (SSIS), które jest uruchamiane przez agenta SQL, może wymagać uprawnień innych niż te, które może zapewnić konto usługi agenta SQL.

    Rozwiązanie: Aby rozwiązać ten problem, zobacz Pakiet usług SSIS nie jest uruchamiany po wywołaniu z kroku zadania agenta programu SQL Server.

  • Nie można zalogować się do bazy danych programu SQL Server — brak możliwości logowania może spowodować błędy w uwierzytelnieniu.

    Rozwiązanie: Aby rozwiązać ten problem, zobacz MSSQLSERVER_18456.

Usługi katalogowe

W tej sekcji wymieniono problemy związane z usługami katalogowymi i serwerami.

  • Konto jest wyłączone — ten scenariusz może wystąpić, jeśli konto użytkownika zostało wyłączone przez administratora lub przez użytkownika. W takim przypadku nie możesz zalogować się przy użyciu tego konta lub nie możesz użyć tego konta do uruchomienia usługi. Może to spowodować spójne problemy z uwierzytelnianiem, ponieważ może uniemożliwić uzyskiwanie dostępu do zasobów lub wykonywanie akcji wymagających uwierzytelniania.

    Rozwiązanie: Administrator domeny może rozwiązać ten problem, ponownie włączając konto. Gdy konto jest wyłączone, zazwyczaj jest to spowodowane tym, że użytkownik próbował zalogować się przy użyciu nieprawidłowego hasła zbyt wiele razy lub dlatego, że aplikacja lub usługa próbuje użyć starego hasła.

  • Konto nie znajduje się w grupie — ten problem może wystąpić, jeśli użytkownik próbuje uzyskać dostęp do zasobu ograniczonego do określonej grupy.

    Rozwiązanie: Sprawdź identyfikatory logowania SQL, aby wyliczyć dozwolone grupy i upewnić się, że użytkownik należy do jednej z grup.

  • Migracja konta nie powiodła się — jeśli stare konta użytkowników nie mogą nawiązać połączenia z serwerem, ale nowo utworzone konta mogą nie być poprawne. Ten problem jest związany z usługami AD DS.

    Rozwiązanie: Aby uzyskać więcej informacji, zobacz Transfer logins and passwords between instances of SQL Server (Przenoszenie nazw logowania i haseł między wystąpieniami programu SQL Server).

  • Kontroler domeny jest w trybie offline — dotyczy problemu, w którym kontroler domeny nie jest dostępny.

    Rozwiązanie: użyj nltest polecenia , aby wymusić przełączenie komputera na inny kontroler domeny. Aby uzyskać więcej informacji, zobacz Zdarzenie replikacji usługi Active Directory o identyfikatorze 2087: Niepowodzenie wyszukiwania DNS spowodowało niepowodzenie replikacji.

  • Zapora blokuje kontroler domeny — podczas zarządzania dostępem użytkownika do zasobów mogą wystąpić problemy.

    Rozwiązanie: upewnij się, że kontroler domeny jest dostępny z klienta lub serwera. W tym celu użyj nltest /SC_QUERY:CONTOSO polecenia .

  • Logowanie pochodzi z niezaufanej domeny — ten problem jest związany z poziomem zaufania między domenami. Może zostać wyświetlony następujący komunikat o błędzie: "Logowanie nie powiodło się. Nazwa logowania pochodzi z niezaufanej domeny i nie może być używana z uwierzytelnianiem systemu Windows. (18452)."

    Błąd 18452 wskazuje, że logowanie używa uwierzytelniania systemu Windows, ale identyfikator logowania jest nierozpoznaną jednostką systemu Windows. Nierozpoznany podmiot zabezpieczeń systemu Windows wskazuje, że nie można zweryfikować logowania przez system Windows. Może się tak zdarzyć, ponieważ logowanie do systemu Windows pochodzi z niezaufanej domeny. Poziom zaufania między domenami może powodować błędy w uwierzytelnianiu konta lub widoczność nazwy dostawcy usług (SPN).

    Rozwiązanie: Aby rozwiązać ten problem, zobacz MSSQLSERVER_18452.

  • Brak uprawnień dla grup między domenami — użytkownicy z domeny zdalnej powinni należeć do grupy w domenie programu SQL Server. Jeśli spróbujesz użyć grupy lokalnej domeny do nawiązania połączenia z wystąpieniem programu SQL Server z innej domeny, może wystąpić problem.

    Rozwiązanie: Jeśli domeny nie mają odpowiedniego zaufania, dodanie użytkowników w grupie w domenie zdalnej może uniemożliwić serwerowi wyliczanie członkostwa grupy.

  • Uwierzytelnianie selektywne jest wyłączone — odwołuje się do funkcji zaufania domeny, która umożliwia administratorowi domeny ograniczenie użytkowników, którzy mają dostęp do zasobów w domenie zdalnej. Jeśli uwierzytelnianie selektywne nie jest włączone, wszyscy użytkownicy w zaufanej domenie mogą uzyskać dostęp do domeny zdalnej.

    Rozwiązanie: Aby rozwiązać ten problem, włącz uwierzytelnianie selektywne, aby upewnić się, że użytkownicy nie mogą uwierzytelniać się w domenie zdalnej.

Uwierzytelnianie Kerberos

W tej sekcji wymieniono problemy związane z uwierzytelnianiem Kerberos:

  • Niepoprawny sufiks DNS jest dołączany do nazwy NetBIOS — ten problem może wystąpić, jeśli używasz tylko nazwy NetBIOS (na przykład SQLPROD01) zamiast w pełni kwalifikowanej nazwy domeny (FQDN) (na przykład SQLPROD01.CONTOSO.COM). W takim przypadku może zostać dodany niewłaściwy sufiks DNS.

    Rozwiązanie: Sprawdź ustawienia sieci dla domyślnych sufiksów, aby upewnić się, że są poprawne, lub użyj nazwy FQDN, aby uniknąć problemów.

  • Niesymetryczność zegara jest zbyt wysoka — ten problem może wystąpić, jeśli wiele urządzeń w sieci nie jest zsynchronizowanych. Aby uwierzytelnianie Kerberos działało, zegary między urządzeniami nie mogą być wyłączone przez więcej niż pięć minut lub mogą wystąpić spójne błędy uwierzytelniania.

    Rozwiązanie: skonfiguruj komputery, aby regularnie synchronizować zegary z centralną usługą czasową.

  • Delegowanie kont poufnych do innych usług — niektóre konta mogą być oznaczone jako Sensitive w usługach AD DS. Tych kont nie można delegować do innej usługi w scenariuszu podwójnego przeskoku. Poufne konta mają kluczowe znaczenie dla zapewnienia bezpieczeństwa, ale mogą mieć wpływ na uwierzytelnianie.

    Rozwiązanie: Aby rozwiązać ten problem, zobacz Logowanie użytkownika NT AUTHORITY\ANONYMOUS LOGON nie powiodło się.

  • Delegowanie do udziału plików — odnosi się do sytuacji, w której użytkownik lub aplikacja deleguje swoje poświadczenia w celu uzyskania dostępu do udziału plików. Bez odpowiednich ograniczeń delegowanie poświadczeń do udziału plików może spowodować zagrożenie bezpieczeństwa.

    Rozwiązanie: Aby rozwiązać ten rodzaj problemu, upewnij się, że używasz ograniczonego delegowania.

  • Rozłączna przestrzeń nazw DNS — odnosi się do spójnego problemu z uwierzytelnianiem, który może wystąpić, jeśli sufiks DNS nie jest zgodny z elementem członkowskim domeny i systemem DNS. Problemy z uwierzytelnianiem mogą wystąpić, jeśli używasz rozłącznej przestrzeni nazw. Jeśli hierarchia organizacyjna w usługach AD DS i dns nie jest zgodna, nieprawidłowa nazwa SPN może zostać wygenerowana, jeśli używasz nazwy NETBIOS w aplikacji bazy danych parametry połączenia. W takiej sytuacji nie można odnaleźć nazwy SPN, a poświadczenia new Technology LAN Manager (NTLM) są używane zamiast poświadczeń protokołu Kerberos.

    Rozwiązanie: Aby rozwiązać ten problem, użyj nazwy FQDN serwera lub określ nazwę SPN w parametry połączenia. Aby uzyskać informacje na temat nazwy FQDN, zobacz Nazewnictwo komputerów.

  • Zduplikowana nazwa SPN — odnosi się do sytuacji, w której co najmniej dwie nazwy SPN są identyczne w domenie. Nazwy SPN służą do unikatowego identyfikowania usług działających na serwerach w domenie systemu Windows. Zduplikowane nazwy SPN mogą powodować problemy z uwierzytelnianiem.

    Rozwiązanie: Aby rozwiązać ten problem, zobacz Rozwiązywanie problemu z programem Kerberos Configuration Manager (zalecane).

  • Włącz porty HTTP w nazwach SPN — zazwyczaj nazwy SPN HTTP nie używają numerów portów (na przykład http/web01.contoso.com).

    Rozwiązanie: Aby rozwiązać ten problem, możesz to włączyć przy użyciu zasad na klientach. Następnie nazwa SPN musi być w http/web01.contoso.com:88 formacie, aby umożliwić poprawne działanie protokołu Kerberos. W przeciwnym razie używane są poświadczenia NTLM.

    Poświadczenia NTLM nie są zalecane, ponieważ mogą utrudnić diagnozowanie problemu. Ponadto taka sytuacja może spowodować nadmierne obciążenie administracyjne.

  • Wygasłe bilety — odnosi się do biletów Kerberos. Użycie wygasłych biletów Kerberos może powodować problemy z uwierzytelnianiem.

    Rozwiązanie: Aby rozwiązać ten problem, zobacz Wygasłe bilety.

  • Plik HOSTS jest niepoprawny — plik HOSTS może zakłócić wyszukiwanie DNS i może wygenerować nieoczekiwaną nazwę SPN. Taka sytuacja powoduje, że należy użyć poświadczeń NTLM. Jeśli w pliku HOSTS znajduje się nieoczekiwany adres IP, wygenerowana nazwa SPN może nie być zgodna z serwerem zaplecza, na który wskazuje.

    Rozwiązanie: Przejrzyj plik HOSTS i usuń wpisy serwera. Wpisy pliku HOSTS są wyświetlane w raporcie SQLCHECK.

  • Problem z uprawnieniami identyfikatora zabezpieczeń usługi (SID) — identyfikator SID dla usługi to funkcja zabezpieczeń programu SQL Server, która ogranicza połączenia lokalne do korzystania z protokołu NTLM, a nie Kerberos jako metody uwierzytelniania. Usługa może przeskoczyć jeden przeskok na inny serwer przy użyciu poświadczeń NTLM, ale nie można go delegować dalej bez korzystania z ograniczonego delegowania. Aby uzyskać więcej informacji, zobacz Logowanie nie powiodło się dla użytkownika NT AUTHORITY\ANONYMOUS LOGON.

    Rozwiązanie: Aby rozwiązać ten problem, administrator domeny musi skonfigurować ograniczone delegowanie.

  • Uwierzytelnianie w trybie jądra — nazwa SPN na koncie puli aplikacji jest zwykle wymagana dla serwerów internetowych. Jednak w przypadku użycia uwierzytelniania w trybie jądra nazwa SPN hosta komputera jest używana do uwierzytelniania. Ta akcja odbywa się w jądrze. To ustawienie może być używane, jeśli serwer hostuje wiele różnych witryn internetowych, które używają tego samego adresu URL nagłówka hosta, różnych kont puli aplikacji i uwierzytelniania systemu Windows.

    Rozwiązanie: Usuń nazwy SPN HTTP, jeśli jest włączone uwierzytelnianie w trybie jądra.

  • Ograniczanie uprawnień delegowania do programu Access lub Excel — dostawcy technologii joint engine technology (JET) i aparatu łączności dostępu (ACE) są podobne do dowolnego z systemów plików. Aby umożliwić programowi SQL Server odczytywanie plików znajdujących się na innym komputerze, należy użyć ograniczonego delegowania. Ogólnie rzecz biorąc, dostawca ACE nie powinien być używany na serwerze połączonym, ponieważ nie jest to jawnie obsługiwane. Dostawca JET jest przestarzały i jest dostępny tylko na komputerach 32-bitowych.

    Uwaga 16.

    Gdy program SQL Server 2014, ostatnia wersja do obsługi instalacji 32-bitowych nie będzie już obsługiwana, scenariusz JET nie będzie już obsługiwany.

  • Brak nazwy SPN — ten problem może wystąpić, jeśli nazwa SPN powiązana z wystąpieniem serwera SQL jest nieobecna.

    Rozwiązanie: Aby uzyskać więcej informacji, zobacz Naprawianie błędu przy użyciu programu Kerberos Configuration Manager (zalecane).

  • Nie jest to ograniczony element docelowy — jeśli ograniczone delegowanie jest włączone dla określonego konta usługi, kerberos zakończy się niepowodzeniem, jeśli główna nazwa usługi serwera docelowego nie znajduje się na liście obiektów docelowych ograniczonego delegowania.

    Rozwiązanie: Aby rozwiązać ten problem, administrator domeny musi dodać nazwę SPN serwera docelowego do docelowych nazw SPN konta usługi warstwy środkowej.

  • NTLM i ograniczone delegowanie — jeśli element docelowy jest udziałem plików, typ delegowania konta usługi warstwy środkowej musi być ograniczony-Any i nie ograniczony-Kerberos. Jeśli typ delegowania ma ustawioną wartość Constrained-Kerberos, konto warstwy środkowej może przydzielić tylko do określonych usług, ale ustawienie Ograniczone —dowolne umożliwia kontu usługi delegowanie do dowolnej usługi.

    Rozwiązanie: Aby rozwiązać ten problem, zobacz Logowanie użytkownika NT AUTHORITY\ANONYMOUS LOGON nie powiodło się.

  • Konto usługi nie może być zaufane w przypadku delegowania w usłudze AD — w scenariuszu podwójnego przeskoku konto usługi w warstwie środkowej musi być zaufane w przypadku delegowania w usługach AD DS. Jeśli konto usługi nie jest zaufane do delegowania, uwierzytelnianie Kerberos może zakończyć się niepowodzeniem.

    Rozwiązanie: Jeśli jesteś administratorem, włącz opcję Zaufane dla delegowania .

  • Niektórzy starsi dostawcy nie obsługują protokołu Kerberos za pośrednictwem nazwanych potoków — starszy dostawca OLE DB (SQLOLEDB) i dostawca ODBC (SQL Server), który jest powiązany z systemem Windows, nie oferuje obsługi uwierzytelniania Kerberos za pośrednictwem nazwanych potoków. Zamiast tego obsługują tylko uwierzytelnianie NTLM.

    Rozwiązanie: użyj połączenia TCP, aby zezwolić na uwierzytelnianie Kerberos. Można również użyć nowszego sterownika, na przykład MSOLEDBSQL lub STEROWNIKA ODBC 17. Jednak protokół TCP jest nadal preferowany w przypadku nazwanych potoków, niezależnie od wersji sterownika.

  • Nazwa SPN jest skojarzona z nieprawidłowym kontem — ten problem może wystąpić, jeśli nazwa SPN jest skojarzona z niewłaściwym kontem w usługach AD DS. Aby uzyskać więcej informacji, zobacz Naprawianie błędu przy użyciu protokołu Kerberos Configuration Manager (zalecane).

    Jeśli nazwa SPN została skonfigurowana na nieprawidłowym koncie w usługach AD DS, może zostać wyświetlony komunikat o błędzie.

    Rozwiązanie: Aby rozwiązać ten problem, wykonaj następujące kroki:

    1. Użyj SETSPN -Q spnName polecenia , aby zlokalizować nazwę SPN i jego bieżące konto.
    2. Użyj SETSPN -D polecenia , aby usunąć istniejące nazwy SPN.
    3. Użyj polecenia , SETSPN -S aby przeprowadzić migrację nazwy SPN do poprawnego konta.

  • Alias SQL może nie działać poprawnie — alias programu SQL Server może spowodować wygenerowanie nieoczekiwanej nazwy SPN. Powoduje to niepowodzenie poświadczeń NTLM, jeśli nie znaleziono głównej nazwy usługi lub błąd SSPI, jeśli przypadkowo pasuje do nazwy SPN innego serwera.

    Rozwiązanie: Aliasy SQL są wyświetlane w raporcie SQLCHECK. Aby rozwiązać ten problem, zidentyfikuj i popraw wszystkie niepoprawne lub błędnie skonfigurowane aliasy SQL, aby wskazywały poprawny program SQL Server.

  • Użytkownik należy do wielu grup — jeśli użytkownik należy do wielu grup, problemy z uwierzytelnianiem mogą wystąpić w protokole Kerberos. Jeśli używasz protokołu Kerberos za pośrednictwem protokołu UDP, cały token zabezpieczający musi mieścić się w jednym pakiecie. Użytkownicy należący do wielu grup mają większy token zabezpieczający niż użytkownicy należący do mniejszej liczby grup.

    Rozwiązanie: Jeśli używasz protokołu Kerberos za pośrednictwem protokołu TCP, możesz zwiększyć ustawienie [MaxTokenSize]. Aby uzyskać więcej informacji, zobacz MaxTokenSize i Kerberos Token Bloat.

  • Użyj nagłówka hosta witryny internetowej — nagłówek hosta HTTP odgrywa bardzo ważną rolę w protokole HTTP na potrzeby uzyskiwania dostępu do stron internetowych.

    Rozwiązanie: Jeśli witryna internetowa ma nazwę nagłówka hosta, nie można użyć nazwy SPN hosts. Należy użyć jawnej nazwy SPN HTTP. Jeśli witryna internetowa nie ma nazwy nagłówka hosta, zostanie użyta funkcja NTLM. Nie można delegować protokołu NTLM do wystąpienia programu SQL Server zaplecza ani innej usługi.

NT LAN Manager (NTLM)

W tej sekcji wymieniono problemy specyficzne dla NTLM (NT LAN Manager):

  • Odmowa dostępu w przypadku logowania równorzędnego NTLM — dotyczy problemu związanego z logowaniem równorzędnym NTLM.

    Rozwiązanie: Podczas komunikacji między komputerami, które znajdują się na stacjach roboczych lub domenach, które nie ufają sobie nawzajem, można skonfigurować identyczne konta na obu komputerach i używać uwierzytelniania równorzędnego NTLM.

    Logowania działają tylko wtedy, gdy zarówno konto użytkownika, jak i hasło są zgodne na obu komputerach. Uwierzytelnianie NTLM może być wyłączone lub nieobsługiwane po stronie klienta lub serwera. Taka sytuacja może spowodować błędy uwierzytelniania. Aby uzyskać więcej informacji, zobacz MSSQLSERVER_18456.

  • Scenariusze podwójnego przeskoku na wielu komputerach — proces podwójnego przeskoku zakończy się niepowodzeniem, jeśli są używane poświadczenia NTLM. Wymagane są poświadczenia protokołu Kerberos.

    Rozwiązanie: Aby rozwiązać ten problem, zobacz Logowanie użytkownika NT AUTHORITY\ANONYMOUS LOGON nie powiodło się.

  • Ochrona sprzężenia zwrotnego nie jest poprawnie ustawiona — ochrona sprzężenia zwrotnego została zaprojektowana tak, aby uniemożliwić aplikacjom wywoływanie innych usług na tym samym komputerze. Jeśli ochrona sprzężenia zwrotnego nie jest poprawnie skonfigurowana lub jeśli wystąpi awaria, taka sytuacja może pośrednio spowodować problemy z uwierzytelnianiem.

    Rozwiązanie: Aby rozwiązać ten problem, zobacz MSSQLSERVER_18456.

  • Ochrona sprzężenia zwrotnego kończy się niepowodzeniem po nawiązaniu połączenia z odbiornikiem Always-on — ten problem jest związany z ochroną sprzężenia zwrotnego. Po nawiązaniu połączenia z odbiornikiem zawsze włączonym z węzła podstawowego połączenie korzysta z uwierzytelniania NTLM.

    Rozwiązanie: Aby uzyskać więcej informacji, zobacz MSSQLSERVER_18456.

  • Problem, który ma wpływ na poziom zgodności lanMAN — problem z uwierzytelnianiem programu LAN Manager (LANMAN) występuje zwykle, jeśli niezgodność istnieje w protokołach uwierzytelniania używanych przez starsze (w wersji starszej niż Windows Server 2008) i nowszych komputerach. Po ustawieniu poziomu zgodności na 5, NTLMv2 nie jest dozwolony.

    Rozwiązanie: przełączanie do protokołu Kerberos pozwala uniknąć tego problemu, ponieważ protokół Kerberos jest bezpieczniejszy. Aby uzyskać więcej informacji, zobacz Logowanie nie powiodło się dla użytkownika NT AUTHORITY\ANONYMOUS LOGON.

identyfikator logowania SQL

W tej sekcji wymieniono problemy związane z poświadczeniami uwierzytelniania:

  • Nieprawidłowe hasło — odnosi się do problemu związanego z logowaniem.

    Rozwiązanie: Aby rozwiązać ten problem, zobacz MSSQLSERVER_18456.

  • Nieprawidłowa nazwa użytkownika — odnosi się do problemu związanego z logowaniem.

    Rozwiązanie: Aby rozwiązać ten problem, zobacz MSSQLSERVER_18456.

  • Identyfikatory logowania programu SQL Server nie są włączone — odwołuje się do scenariusza, w którym próbujesz nawiązać połączenie z wystąpieniem programu Microsoft SQL Server przy użyciu uwierzytelniania programu SQL Server, ale identyfikator logowania skojarzony z kontem jest wyłączony.

    Rozwiązanie: Aby rozwiązać ten problem, zobacz MSSQLSERVER_18456.

  • Połączenia nazwanych potoków kończą się niepowodzeniem, ponieważ użytkownik nie ma uprawnień do logowania się do systemu Windows — odnosi się do problemu z uprawnieniami w systemie Windows .

    Rozwiązanie: Aby rozwiązać ten problem, zobacz Problem z połączeniami nazwanych potoków w programie SQL Server.

Uprawnienia systemu Windows

W tej sekcji wymieniono problemy specyficzne dla uprawnień systemu Windows lub ustawień zasad:

  • Dostęp jest udzielany za pośrednictwem grup lokalnych — jeśli użytkownik nie należy do grupy lokalnej używanej do udzielenia dostępu do serwera, dostawca wyświetla komunikat o błędzie "Logowanie nie powiodło się dla użytkownika "contoso/user1".

    Rozwiązanie: Administrator bazy danych może sprawdzić tę sytuację, sprawdzając folder Identyfikatory logowania zabezpieczeń>w programie SQL Server Management Studio (SSMS). Jeśli baza danych jest zawartą bazą danych, sprawdź w obszarze databasename. Aby uzyskać więcej informacji, zobacz Logowanie nie powiodło się dla użytkownika "<nazwa użytkownika>" lub logowanie nie powiodło się dla użytkownika "<domena>\<nazwa_użytkownika>".

  • Funkcja Credential Guard jest włączona — ten scenariusz wskazuje, że funkcja Credential Guard jest włączona w systemie Windows i służy do tworzenia bezpiecznego środowiska do przechowywania poufnych informacji. Jednak w niektórych sytuacjach ta funkcja może powodować problemy z uwierzytelnianiem.

    Rozwiązanie: Aby rozwiązać ten problem, poproś administratora domeny o skonfigurowanie ograniczonego delegowania. Aby uzyskać więcej informacji, zobacz Zagadnienia i znane problemy podczas korzystania z funkcji Credential Guard.

  • Błędy podsystemu zabezpieczeń lokalnych — w przypadku wystąpienia błędów podsystemu zabezpieczeń lokalnych, szczególnie tych, które są połączone z usługą LSASS stają się nieodpowiadające, może to wskazywać na podstawowe problemy wpływające na uwierzytelnianie.

    Rozwiązanie: Aby rozwiązać te błędy, zobacz Błędy podsystemu zabezpieczeń lokalnych w programie SQL Server.

  • Niedozwolone logowanie do sieci — ten scenariusz występuje podczas próby zalogowania się do sieci, ale żądanie logowania zostało odrzucone z określonych powodów.

    Rozwiązanie: Aby rozwiązać ten problem, zobacz Użytkownik nie ma uprawnień do logowania się do sieci.

  • Tylko administratorzy mogą się zalogować — ten problem występuje, jeśli dziennik zabezpieczeń na komputerze jest pełny i nie ma wystarczającej ilości miejsca do wypełnienia zdarzeń. Funkcja zabezpieczeń CrashOnAuditFail jest używana przez administratorów systemu do sprawdzania wszystkich zdarzeń zabezpieczeń. Prawidłowe wartości to CrashOnAuditFail 0, 1 i 2. Jeśli klucz dla CrashOnAuditFail parametru ma wartość 2, oznacza to, że dziennik zabezpieczeń jest pełny i zostanie wyświetlony komunikat o błędzie "Tylko administratorzy mogą się zalogować".

    Rozwiązanie: Aby rozwiązać ten problem, wykonaj następujące kroki:

    1. Uruchom edytor rejestru.
    2. Znajdź i sprawdź podklucz HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa!crashonauditfail , aby sprawdzić, czy wartość jest ustawiona na 2. Ta wartość wskazuje, że dziennik zabezpieczeń wymaga ręcznego czyszczenia.
    3. Ustaw wartość 0, a następnie uruchom ponownie serwer. Możesz również zmienić dziennik zabezpieczeń, aby umożliwić przerzucanie zdarzeń. Aby uzyskać więcej informacji na temat wpływu ustawienia na wszystkie usługi, takie jak SQL, IIS, udział plików i logowanie, zobacz Użytkownicy nie mogą uzyskać dostępu do witryn sieci Web, gdy dziennik zdarzeń zabezpieczeń jest pełny.

    Uwaga 16.

    Ten problem dotyczy tylko zintegrowanych logowań. Połączenie nazwanych potoków również będzie miało wpływ na logowanie programu SQL Server, ponieważ nazwane potoki najpierw logują się do potoku administracyjnego systemu Windows przed nawiązaniem połączenia z programem SQL Server.

  • Konto usługi nie jest zaufane w przypadku delegowania — ten rodzaj problemu zwykle występuje, jeśli konto usługi nie może przypisać poświadczeń do innych serwerów. Ten problem może mieć wpływ na usługi wymagające delegowania.

    Rozwiązanie: Jeśli scenariusz delegowania nie jest włączony, sprawdź secpol.msc programu SQL Server, aby określić, czy konto usługi programu SQL Server jest wyświetlane w obszarze Przypisanie > praw użytkownika Zasady lokalne > Personifikuj klienta po ustawieniach zasad zabezpieczeń uwierzytelniania. Aby uzyskać więcej informacji, zobacz Włączanie zaufania kont komputerów i użytkowników w kwestii delegowania.

  • Nie można załadować profilu użytkownika systemu Windows w programie SQL Server — dotyczy problemu z profilem użytkownika systemu Windows.

    Rozwiązanie: Aby uzyskać więcej informacji na temat rozwiązywania problemów z uszkodzonymi profilami użytkowników, zobacz Nie można załadować profilu użytkownika systemu Windows w programie SQL Server.

Inne aspekty

W tej sekcji wymieniono problemy związane z uwierzytelnianiem i kontrolą dostępu w środowisku internetowym:

  • Zintegrowane uwierzytelnianie nie jest włączone — odwołuje się do problemu z konfiguracją, w którym zintegrowane uwierzytelnianie systemu Windows (IWA) nie jest poprawnie skonfigurowane.

    Rozwiązanie: Aby rozwiązać ten problem, upewnij się, że opcja Zintegrowane uwierzytelnianie systemu Windows jest włączona w ustawieniach Opcji internetowych.

  • Uwierzytelnianie usług IIS nie jest dozwolone — ten problem występuje z powodu błędów konfiguracji w usługach IIS. Ustawienia uwierzytelniania zdefiniowane w pliku Web.config aplikacji internetowej mogą powodować konflikt z ustawieniami skonfigurowanymi w usługach IIS. Taka sytuacja może powodować problemy z uwierzytelnianiem.

    Rozwiązanie: Aby rozwiązać ten problem, skonfiguruj witrynę internetową, aby włączyć uwierzytelnianie systemu Windows i ustawić <identity impersonate="true"/> wartość w pliku Web.config .

  • Nieprawidłowa strefa internetowa — ten problem może wystąpić, jeśli spróbujesz uzyskać dostęp do witryny sieci Web, która nie znajduje się w prawidłowej strefie internetowej w programie Internet Explorer. Poświadczenia nie będą działać, jeśli witryna internetowa znajduje się w lokalnej strefie intranetu.

    Rozwiązanie: Dodaj serwer internetowy do lokalnej strefy intranetowej programu IE.

Zastrzeżenie dotyczące innych firm

Produkty innych firm omówione w tym artykule są wytwarzane przez producentów niezależnych od firmy Microsoft. Firma Microsoft nie udziela żadnych gwarancji, dorozumianych ani żadnego innego rodzaju, w odniesieniu do wydajności lub niezawodności tych produktów.

Więcej informacji

Zbieranie danych w celu rozwiązywania problemów z łącznością z programem SQL Server