Błąd logowania uwierzytelniania systemu Windows w SQL Server 2008: login pochodzi z niezaufanej domeny

Podczas próby połączenia się z wystąpieniem programu SQL Server 2008 przy użyciu programu Management Studio otrzymuję następujący błąd:

Logowanie nie powiodło się. Dane logowania pochodzą z niezaufanej domeny i nie mogą być używane z uwierzytelnianiem systemu Windows. (Microsoft SQL Server, błąd: 18452)

Mogę bez problemu zalogować się przy użyciu uwierzytelniania SQL. Nagle otrzymuję ten błąd. Mam włączone uwierzytelnianie w trybie mieszanym.

Czy ktoś ma z tym jakieś doświadczenie?

Dodatkowe informacje: 64-bitowa wersja SQL Enterprise Edition w systemie Windows 2003 Server

Innym powodem, dla którego może się to zdarzyć (mi się to przydarzyło) ... jest wygaśnięcie hasła użytkownika. Nie zdawałem sobie z tego sprawy, dopóki nie spróbowałem zdalnie połączyć się z rzeczywistym serwerem i zostałem poproszony o zmianę hasła.

U mnie stało się tak, gdy edytowałem pusty drivers/etc/hostsplik i dodałem wpis dotyczący lokalnej witryny internetowej, ale zaniedbałem dodanie127.0.0.1 localhost

Problem był spowodowany przez wyłączony serwer Active Directory, który oczywiście nie mógł uwierzytelnić konta Windows. Dziękuję za pomoc.

Dla każdego, kto napotka na to, mam to w moim pliku hosts:

127.0.0.1   localhost
127.0.0.1   customname

i potrzebowałem, żeby to było:

127.0.0.1   localhost
127.0.0.1   localhost   customname

„Problem został spowodowany przez wyłączony serwer Active Directory, który oczywiście nie mógł uwierzytelnić konta systemu Windows”

To nie jest „oczywiście - ponieważ jeśli AD nie jest dostępne, uwierzytelnianie Kerberos powraca do NTLM (poświadczenia konta domeny są buforowane lokalnie, można się nim zalogować, nawet jeśli AD / Kerberos nie jest dostępny). jednoczesne warunki wystąpienia tego niepowodzenia:

• SQL Server nie jest lokalny (na innym komputerze)
• Zaufanie jest skonfigurowane „Tylko Kerberos”

lub inne specyficzne konfiguracje sieci / serwera / AD / maszyny zabezpieczającej

Miałem ten problem z instancją serwera na moim komputerze lokalnym i stwierdziłem, że jest to spowodowane wskazaniem adresu 127.0.0.1 z czymś innym niż „localhost” w moim pliku hosts. Istnieją dwa sposoby rozwiązania tego problemu w moim przypadku:

1. Wyczyść obraźliwy wpis wskazujący na 127.0.0.1 w pliku hosts
2. użyj „localhost” zamiast innej nazwy, która w pliku hosts wskazuje na 127.0.0.1

* To działało tylko wtedy, gdy uruchamiałem instancję serwera sql na moim komputerze lokalnym i próbowałem uzyskać do niej dostęp z tej samej maszyny.

Upewnij się, że nie masz połączenia z siecią VPN w innej domenie \ użytkownik . Albo odwrotnie, upewnij się, że są podłączone, jeśli to, co jest wymagane.

Naprawiłem ten problem na komputerze wyłączając ustawienie kontroli sprzężenia zwrotnego:

1. Edytuj rejestr systemu Windows: Start -> Uruchom> Regedit
2. Przejdź do: HKLM \ System \ CurrentControlSet \ Control \ LSA
3. Dodaj wartość DWORD o nazwie „DisableLoopbackCheck”
4. Ustaw tę wartość na 1

spróbuj użyć innego prawidłowego loginu za pomocą polecenia RUNAS

runas /user:domain\user “C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe” 

runas /user:domain\user “C:\WINDOWS\system32\mmc.exe /s \”C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC\”" 

runas /user:domain\user isqlw 

Dla mnie było to spowodowane tym, że nie dodałem konta, aby mieć role, których chciałem użyć, do samej bazy danych SQL. A także z powodu prób podania złego hasła za pośrednictwem konta blokującego problem z kopiowaniem wklejania.

Okej, odpowiedź ode mnie. Otrzymałem ten błąd ze środowiska programistycznego hostowanego na VM VirtualBox. Trzy serwery; SharePoint, SQL DB i kontroler domeny. Serwer SharePoint nie mógł połączyć się z bazą danych konfiguracji. Nadal mogę połączyć się przez ODBC w celu uwierzytelnienia Sql przy użyciu konta SA, ale nie uwierzytelnienia systemu Windows. Ale ten użytkownik szczęśliwie zalogowałby się do SSMS na samym serwerze sql. Otrzymałem również lepszy komunikat o błędzie od ODBC, a także po sprawdzeniu nieudanych komunikatów logowania na serwerze sql:

select text from sys.messages where message_id = '18452' and language_id = 1033

Nie mogę tego przypisać, ponieważ poprosiłem jednego z naszych administratorów systemów przedsiębiorstwa o pomoc i zdiagnozował to w ciągu około 5 minut, patrząc na kilka zrzutów ekranu, które mu wysłałem. Problem polegał na tym, że zegar kontrolera domeny był ustawiony nieprawidłowo! Nie mogłem w to uwierzyć. Serwery są skonfigurowane do pracy w sieci tylko host, więc nie mają internetu do synchronizacji zegara. To wyjaśnia również, dlaczego przywrócenie wcześniejszej migawki, gdy wiem, że system działał, nie rozwiązało problemu.

Edycja: Zainstalowanie dodatków dla gości na serwerze synchronizuje zegar gościa z hostem.

W sterowniku jTDS znajduje się ustawienie o nazwie USENTLMV2, które domyślnie ma wartość false. Ustawienie tego na „prawda” w moim oprogramowaniu db (DBVisualizer) rozwiązało problem.

Innym scenariuszem, w którym może się to pojawić, jest próba połączenia się z innym serwerem SQL z sesji SSMS, która była już zalogowana podczas zmiany hasła. Sekwencja wydarzeń może wyglądać następująco:

1. RDP do Server-A (twój SQL Server), otwórz SSMS i zaloguj się
2. RDP na Server-B w tej samej domenie i zmień swoje hasło
3. Wróć do sesji RDP na serwerze A i za pośrednictwem programu SSMS spróbuj dodać kolejną bazę danych do istniejącej grupy dostępności AlwaysOn. Podczas łączenia się z replikami pojawia się błąd „niezaufana domena” -login-error

Aby rozwiązać ten problem, po prostu wyloguj się i zaloguj ponownie

Możesz zostać wprowadzony w błąd co do nazwy użytkownika, której używasz lokalnie. Tak było w moim przypadku w systemie Windows 10 Home. Kiedy patrzę na użytkowników w panelu sterowania, widzę nazwę usrpc01 . Jednak kiedy piszę net config workstation, okazuje się, że nazwa użytkownika to spc01 . Wygląda na to, że ktoś zmienił nazwę użytkownika, ale nazwa wewnętrzna pozostała niezmieniona.

Nie wiedząc, jak naprawić nazwę użytkownika systemu Windows (i nazwę folderu pod C:\Users, która również odnosi się do pierwotnej nazwy wewnętrznej), dodałem nowe konto użytkownika na moim serwerze db.

Próbowałem zalogować się do programu SQL Server 2008 z konta domeny. SQL Server 2008 jest hostowany na innym komputerze grupy roboczej, który nie jest częścią domeny. Choć brzmi to dziwnie, na serwerze grupy roboczej, na którym działa SQL Server 2008, musiałem przejść do Właściwości systemu | Nazwa komputera (karta) | Zmień (przycisk) | Zmiana nazwy komputera | Więcej ... (przycisk) i wpisz „Sufiks podstawowego DNS tego komputera” (było puste, więc wprowadź żądany sufiks dla swojej sieci) i zaznacz pole „Zmień sufiks podstawowego DNS po zmianie członkostwa w domenie”. Pozwoliło to na zakończenie procesu uwierzytelniania systemu Windows podczas logowania do programu SQL Server 2008.

Musiałem użyć netonly, aby to działało na nowoczesnym systemie Windows:

runas /netonly /user:domain\user "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

Inny powód> ktoś zmienił hasło dla domyślnego użytkownika SQL

zdarzyło mi się to kilka minut temu, przełączając się na nowy kontroler domeny ...

Miałem zły wpis w pliku hosts pod C:\Windows\System32\drivers\etc

[Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Upewnij się, że masz wpis jak poniżej

127.0.0.1   localhost
127.0.0.1   localhost   servername

Używałem aliasu dla instancji SQL Server, która wskazywała na „127.0.0.1”. Zamiast tego zmiana na „localhost” załatwiła sprawę.

Jeśli serwer Sql działa na serwerze, który nie jest częścią domeny, aw ciągu połączenia używasz w pełni kwalifikowanej nazwy domeny (np. Xyz.mypc.com) z Integrated Security = True, być może będziesz musiał przełączyć się na używanie adres IP, MachineName (SERVER01) lub kropka (.) w przypadku, gdy jest hostowany lokalnie.

To zadziałało dla mnie, użycie fqdn spowodowało powyższy błąd.

aby włączyć uwierzytelnianie systemu Windows, oba komputery muszą znajdować się w tej samej domenie. aby umożliwić studiom zarządzania przekazywanie bieżących poświadczeń i uwierzytelnianie w polu sql

W moim przypadku muszę się rozłączyć (zmienić grupę roboczą / domenę) z domeny i ponownie połączyć.

I jeszcze jeden możliwy powód: Nowo utworzone konto lokalne na serwerze DB miało ustawioną flagę: „Użytkownik musi zmienić hasło przy następnym logowaniu”.

Oto, co mi to rozwiązało: Właściwości połączenia sieciowego Kliknij: „Protokół internetowy w wersji 4 (TCT / IPv4)”. Kliknij przycisk „Właściwości”. Kliknij przycisk „Zaawansowane”. Wybierz kartę „DNS”. Usuń tekst w polu „Sufiks DNS dla tego połączenia”.

Nie udało mi się również połączyć zdalnie z serwerem SQL. Zarówno serwer SQL, jak i serwer zdalny znajdują się w tej samej domenie. Kilka dni wcześniej poproszono mnie o zmianę hasła. Zrestartowanie zarówno serwera SQL, jak i serwera zdalnego, z którego próbowałem uzyskać dostęp do serwera SQL, załatwiło sprawę.

W naszym przypadku był to fakt, że programista uruchomił pulę aplikacji na swoim koncie i zresetował swoje hasło, ale zapomniał je zmienić w puli aplikacji. Aha ...

W moim przypadku serwer został wyłączony w kontrolerze domeny. Wszedłem do OU KOMPUTERÓW w Active Directory, kliknąłem prawym przyciskiem na serwerze, włączyłem go, a następnie wykonałem gpupdate / force z serwera SQL. Zajęło to chwilę, ale w końcu zadziałało.

W moim przypadku w pliku hosta nazwa komputera jest zakodowana na stałe za pomocą starszego adresu IP. Wymieniam starsze IP na nowe, problem rozwiązany.

Lokalizacja pliku hosta

WindowsDrive: \ Windows \ System32 \ drivers \ etc \ hosts

Modyfikacje wykonane 159.xx.xx.xxx MachineName

Żadne z powyższych nie działało dla mnie. Co musiałem zrobić, to: W SQL Server Management Studio na ekranie logowania wybierz Opcje >> W sekcji Sieć zmień protokół sieciowy na Named Pipes.

Ponadto musiałem zrobić, aby działało z <default>ustawieniem, aby wyłączyć sieć bezprzewodową (urządzenie było również podłączone do przewodowej sieci LAN).

Moja poprawka polegała na zmianie pliku web.config, aby był skorelowany z moją nową nazwą serwera dla połączenia SQL (IT Security właśnie dokonał zmiany nazwy domeny sieciowej na moim komputerze programistycznym.