Główna nazwa docelowa jest nieprawidłowa. Nie można wygenerować kontekstu SSPI

Usiłuję uzyskać połączenie SQL Server z komputera A do komputera B, na którym działa SQL Server.

Dużo szukałem w Google i wszystkie znalezione rzeczy nie działają. Nie prowadzą też krok po kroku przez proces rozwiązywania tego problemu.

Nie używamy protokołu Kerberos, ale NTLM, jeśli jest skonfigurowany.

Maszyny, których to dotyczy, to (xx służy do ukrywania nazwy komputera ze względów bezpieczeństwa):

• xxPRODSVR001 - kontroler domeny systemu Windows Server 2012
• xxDEVSVR003 - Windows Server 2012 (ten komputer generuje błąd)
• xxDEVSVR002 - Windows Server 2012 (na tym komputerze jest uruchomiony program SQL Server 2012)

Następujące nazwy SPN są zarejestrowane na DC (xxPRODSVR001). Zasłoniłem domenę yyy ze względów bezpieczeństwa:

Zarejestrowane ServicePrincipalNames dla CN = xxDEVSVR002, CN = Computers, DC = yyy, DC = local:

            MSSQLSvc/xxDEVSVR002.yyy.local:49298

            MSSQLSvc/xxDEVSVR002.yyy.local:TFS

            RestrictedKrbHost/xxDEVSVR002

            RestrictedKrbHost/xxDEVSVR002.yyy.local

            Hyper-V Replica Service/xxDEVSVR002

            Hyper-V Replica Service/xxDEVSVR002.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR002

            Microsoft Virtual System Migration Service/xxDEVSVR002.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR002

            Microsoft Virtual Console Service/xxDEVSVR002.yyy.local

            SMTPSVC/xxDEVSVR002

            SMTPSVC/xxDEVSVR002.yyy.local

            WSMAN/xxDEVSVR002

            WSMAN/xxDEVSVR002.yyy.local

            Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/xxDEVSVR002.yyy.local

            TERMSRV/xxDEVSVR002

            TERMSRV/xxDEVSVR002.yyy.local

            HOST/xxDEVSVR002

            HOST/xxDEVSVR002.yyy.local

Zarejestrowane ServicePrincipalNames dla CN = xxDEVSVR003, CN = Computers, DC = yyy, DC = local:

            MSSQLSvc/xxDEVSVR003.yyy.local:1433

            MSSQLSvc/xxDEVSVR003.yyy.local

            Hyper-V Replica Service/xxDEVSVR003

            Hyper-V Replica Service/xxDEVSVR003.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR003

            Microsoft Virtual System Migration Service/xxDEVSVR003.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR003

            Microsoft Virtual Console Service/xxDEVSVR003.yyy.local

            WSMAN/xxDEVSVR003

            WSMAN/xxDEVSVR003.yyy.local

            TERMSRV/xxDEVSVR003

            TERMSRV/xxDEVSVR003.yyy.local

            RestrictedKrbHost/xxDEVSVR003

            HOST/xxDEVSVR003

            RestrictedKrbHost/xxDEVSVR003.yyy.local

            HOST/xxDEVSVR003.yyy.local

Gdyby tylko komunikat o błędzie programu SQL Server był bardziej opisowy i powiedział mi, z jaką główną nazwą próbuje się połączyć, mógłbym to zdiagnozować.

Czy więc ktoś może mi pokazać, jak rozwiązać ten problem, czy może widzisz w tym, co podałem, coś, co jest nie tak?

Z przyjemnością wygeneruję więcej informacji debugowania, po prostu powiedz mi, czego potrzebujesz.

Miałem ten problem z aplikacją ASP.NET MVC, nad którą pracowałem.

Zdałem sobie sprawę, że niedawno zmieniłem hasło i mogłem to naprawić, wylogowując się i logując ponownie.

Otrzymałem ten błąd podczas łączenia się przez SQL Server Management Studio przy użyciu uwierzytelniania systemu Windows. Moje hasło wygasło, ale jeszcze go nie zmieniłem. Po zmianie musiałem się wylogować i zalogować ponownie, aby komputer działał przy użyciu moich nowych poświadczeń.

Spróbuj ustawić, Integrated Security=trueaby usunąć ten parametr z parametrów połączenia.

WAŻNE: jak skomentował @Auspex,

Usunięcie zintegrowanych zabezpieczeń zapobiegnie wystąpieniu tego błędu, ponieważ błąd występuje podczas próby zalogowania się przy użyciu poświadczeń systemu Windows. Niestety przez większość czasu chcesz mieć możliwość logowania się przy użyciu poświadczeń systemu Windows

Otrzymałem ten sam błąd podczas próby uwierzytelnienia systemu Windows. Brzmi absurdalnie, ale na wszelki wypadek, gdyby pomogło to komuś innemu: stało się tak, ponieważ moje konto domeny zostało w jakiś sposób zablokowane, gdy byłem nadal zalogowany (!). Odblokowanie konta naprawiło problem.

Logowałem się do systemu Windows 10 za pomocą kodu PIN zamiast hasła. Zamiast tego wylogowałem się i zalogowałem ponownie przy użyciu hasła i mogłem zalogować się do programu SQL Server przez Management Studio.

Aby dodać kolejne potencjalne rozwiązanie tego najbardziej niejednoznacznego błędu The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider):

Sprawdź, czy adres IP rozwiązany podczas pingowania programu SQL Server jest taki sam, jak ten w programie Configuration Manager. Aby to sprawdzić, otwórz SQL Server Configuration Manager, a następnie przejdź do SQL Server Network Configuration> Protocols for MSSQLServer> TCP / IP.

Upewnij się, że protokół TCP / IP jest włączony i na karcie Adresy IP upewnij się, że adres IP, na który serwer rozpoznaje podczas pingowania, jest taki sam. To naprawiło ten błąd.

Błąd kontekstu SSPI zdecydowanie wskazuje, że podjęto próbę uwierzytelnienia przy użyciu protokołu Kerberos .

Ponieważ uwierzytelnianie Kerberos Uwierzytelnianie systemu Windows Server SQL Server opiera się na usłudze Active Directory , która wymaga relacji zaufania między komputerem a sieciowym kontrolerem domeny, należy rozpocząć od sprawdzenia tej relacji.

Możesz szybko sprawdzić tę relację za pomocą następującego polecenia programu PowerShell Test-ComputerSecureChannel .

Test-ComputerSecureChannel -verbose

Jeśli zwróci wartość Fałsz , musisz naprawić bezpieczny kanał Active Directory na komputerze, ponieważ bez niego nie jest możliwa weryfikacja poświadczeń domeny poza komputerem.

Możesz naprawić bezpieczny kanał komputera za pomocą następującego polecenia Powershell :

Test-ComputerSecureChannel -Repair

Sprawdź dzienniki zdarzeń bezpieczeństwa, jeśli używasz protokołu Kerberos, powinieneś zobaczyć próby logowania z pakietem uwierzytelniania: Kerberos.

Uwierzytelnianie NTLM może się nie powieść i dlatego jest podejmowana próba uwierzytelnienia Kerberos. Możesz również zobaczyć niepowodzenie próby logowania NTLM w dzienniku zdarzeń zabezpieczeń?

Możesz włączyć rejestrowanie zdarzeń Kerberos w dev, aby spróbować zdebugować, dlaczego Kerberos nie działa, chociaż jest to bardzo szczegółowe.

Menedżer konfiguracji Kerberos firmy Microsoft dla programu SQL Server może pomóc w szybkim zdiagnozowaniu i rozwiązaniu tego problemu.

Oto dobra historia do przeczytania: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/

Wydaje się, że problem dotyczy poświadczeń systemu Windows. Otrzymałem ten sam błąd na moim laptopie roboczym z VPN. Podobno jestem zalogowany jako moja domena / nazwa użytkownika, czego używam z powodzeniem podczas bezpośredniego łączenia, ale gdy tylko przejdę do VPN z innym połączeniem, otrzymuję ten błąd. Myślałem, że to problem z DNS, ponieważ mogłem pingować serwer, ale okazało się, że musiałem uruchomić SMSS jawnie jako mój użytkownik z wiersza polecenia.

np. runas / netonly / user: YourDoman \ YourUsername "C: \ Program Files (x86) \ Microsoft SQL Server Management Studio 18 \ Common7 \ IDE \ Ssms.exe"

Zaloguj się do swojego SQL Box i swojego klienta i wpisz:

ipconfig /flushdns
nbtstat -R

Jeśli to nie zadziała, odnów DHCP na komputerze klienckim ... Działa to na 2 komputerach w naszym biurze.

Właśnie wpadłem na to i naprawiłem to, wykonując 2 rzeczy:

1. Przyznawanie uprawnień do odczytu / zapisu servicePrincipalName do konta usługi za pomocą ADSI Edit, zgodnie z opisem w https://support.microsoft.com/en-us/kb/811889

2. Usuwanie nazw SPN, które wcześniej istniały na koncie komputera programu SQL Server (w przeciwieństwie do konta usługi) przy użyciu

   setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME
   

   gdzie 1234 był numerem portu używanym przez instancję (moja nie była instancją domyślną).

W moim przypadku ponowne uruchomienie SQL Server 2014 (na moim serwerze deweloperskim) rozwiązało problem.

Testowałem IPv6 na klastrze komputerów w odizolowanej sieci i napotkałem ten problem, kiedy przywróciłem IPv4. Grałem w Active Directory, DNS i DHCP, więc nie mam pojęcia, co skłoniłem, aby złamać konfigurację Kerberos.

Ponownie przetestowałem połączenie poza moim oprogramowaniem, korzystając z tej przydatnej wskazówki dotyczącej połączenia zdalnej, którą znalazłem.

https://blogs.msdn.microsoft.com/steverac/2010/12/13/test-remote-sql-connectivity-easily/

następnie po krótkim wyszukiwaniu znalazłem to w witrynie Microsoft https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message .

uruchom narzędzie na serwerze SQL, sprawdź, czy jest jakiś problem, jeśli stan mówi o błędzie, a następnie naciśnij przycisk naprawy, który się pojawi.

To rozwiązało problem.

Zwykle jest to spowodowane brakującymi, nieprawidłowymi lub zduplikowanymi nazwami usług (SPN)

Kroki do rozwiązania:

1. Sprawdź, jakiego konta usługi AD używa SQL Server
2. Uruchom następujące polecenie w Powershell lub CMD w trybie administratora (konto usługi nie powinno zawierać domeny)

setspn -L <ServiceAccountName> | Select-String <ServerName> | select line

3. Upewnij się, że zwrócone dane wyjściowe zawierają nazwę SPN, która jest w pełni kwalifikowana, a nie w pełni kwalifikowana, z portem i bez portu.

   Oczekiwany wynik:

   Registered ServicePrincipalNames for CN=<ServiceAccountName>,OU=CSN Service Accounts,DC=<Domain>,DC=com: 
   MSSQLSvc/<ServerName>.<domain>.com:1433
   MSSQLSvc/<ServerName>:1433                                           
   MSSQLSvc/<ServerName>.<domain>.com
   MSSQLSvc/<ServerName>
   

4. Jeśli nie widzisz wszystkich powyższych, uruchom następujące polecenie w PowerShell lub CMD w trybie administratora (pamiętaj, aby zmienić port, jeśli nie używasz domyślnego 1433)

SETSPN -S  MSSQLSvc/<ServerName> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>:1433 <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain>:1433 <Domain>\<ServiceAccountName>

5. Po wykonaniu powyższych czynności propagacja DNS zajmuje zwykle kilka minut

Ponadto, jeśli pojawi się komunikat o znalezieniu zduplikowanych nazw SPN, możesz je usunąć i utworzyć ponownie

Miałem ten problem podczas uzyskiwania dostępu do aplikacji internetowej. Może to być spowodowane tym, że ostatnio zmieniłem hasło systemu Windows.

Ten problem został rozwiązany, gdy zaktualizowałem hasło do puli aplikacji, w której hostowałem aplikację internetową.

Sprawdź, czy zegar zgadza się między klientem a serwerem.

Kiedy sporadycznie otrzymywałem ten błąd, żadna z powyższych odpowiedzi nie działała, a następnie stwierdziliśmy, że czas dryfował na niektórych naszych serwerach, a po ponownej synchronizacji błąd zniknął. Wyszukaj w32tm lub NTP, aby zobaczyć, jak automatycznie synchronizować czas w systemie Windows.

Ponieważ wylądowałem tutaj, szukając rozwiązania mojego własnego problemu, podzielę się nim tutaj, na wypadek gdyby inni też tu wylądowali.

Łączyłem się dobrze z SQL Server, dopóki mój komputer nie został przeniesiony do innego biura w innej domenie . Następnie po przełączeniu otrzymywałem ten błąd dotyczący docelowej nazwy głównej. Naprawiono to, że łączyło się przy użyciu w pełni kwalifikowanej nazwy, takiej jak: serwer.domena.com . I faktycznie, kiedy połączyłem się w ten sposób z pierwszym serwerem, mogłem połączyć się z innymi serwerami, używając tylko nazwy serwera (bez pełnej kwalifikacji), ale Twój przebieg może się różnić.

Wpadłem na to dzisiaj i chciałem podzielić się swoją poprawką, ponieważ ta jest po prostu przeoczona i łatwa do naprawienia.

Zarządzamy własnym rDNS i ostatnio zmieniliśmy schemat nazewnictwa serwerów. W ramach tego powinniśmy zaktualizować nasz rDNS i zapomnieć o tym.

Ping zwrócił poprawną nazwę hosta, ale ping -a zwrócił nieprawidłową nazwę hosta.

Łatwa naprawa: zmień rDNS, wykonaj ipconfig / flushdns, poczekaj 30 sekund (po prostu coś, co robię), wykonaj kolejne polecenie ping -a, zobacz, jak rozwiązuje poprawną nazwę hosta, połącz ... zysk.

W tym celu natknąłem się na nowy: SQL 2012 hostowany na serwerze 2012. Otrzymałem zadanie utworzenia klastra dla SQL AlwaysOn.
Klaster powstał, każdy dostał wiadomość SSPI.

Aby rozwiązać problemy, uruchomiono następujące polecenie:

setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService

DomainNamerunningSQLService== konto domeny, które ustawiłem dla SQL Potrzebowałem administratora domeny, aby uruchomić polecenie. Tylko jeden serwer w klastrze miał problemy.

Następnie ponownie uruchomiono SQL. Ku mojemu zdziwieniu udało mi się połączyć.

Próbowałem połączyć się z maszyną wirtualną z programem SQL Server 2015 z mojego laptopa w aplikacji konsoli programu Visual Studio 2015. Uruchomiłem aplikację poprzedniego wieczoru i wszystko jest w porządku. Rano próbuję zdebugować aplikację i pojawia się ten błąd. Próbowałem ipconfig/flushi release+ renewi sporo innych śmieci, ale w końcu ...

Uruchom ponownie maszynę wirtualną i uruchom ponownie klienta. To naprawiło to dla mnie. Powinienem był wiedzieć, restart działa za każdym razem.

Miałem ten problem na moim serwerze sql. Ustawiłem spn -D mssqlsvc \ Hostname.domainname Nazwa hosta, a następnie zatrzymałem i uruchomiłem usługę serwera SQL.

Myślę, że wystarczyłoby zatrzymanie i uruchomienie mojej usługi sql.

Miałem ten sam problem, ale blokowanie i odblokowywanie maszyny działało dla mnie. Czasami problemy z zaporą ogniową powodują błędy.

Nie jestem pewien, czy to zadziała, czy nie, po prostu dzielę się moim doświadczeniem.

Wypróbowałem tutaj wszystkie rozwiązania i żadne z nich jeszcze nie zadziałało. Rozwiązaniem, które działa, jest kliknięcie Połącz , wprowadź nazwę serwera, wybierz Opcje, zakładka Właściwości połączenia. Ustaw „Protokół sieciowy” na „Nazwane potoki”. Pozwala to użytkownikom na zdalne łączenie się przy użyciu poświadczeń sieciowych. Opublikuję aktualizację, gdy dostanę poprawkę.

W moim przypadku problemem była konfiguracja DNS na wifi. Usunąłem ustawienia, zostawiłem je puste i działałem.

Upewnij się, że „Named Pipes” są włączone w „SQL Server Configuration Manager”. To zadziałało dla mnie.

1. Otwórz „SQL Server Configuration Manager”.
2. Rozwiń „Konfiguracja sieci SQL Server” z listy po lewej stronie.
3. Wybierz „Protokoły dla [nazwa Twojej instancji]”.
4. Kliknij prawym przyciskiem myszy „Nazwane potoki” z listy po prawej stronie.
5. Wybierz „Włącz”
6. Uruchom ponownie usługę Instance.

To narzędzie Microsoft jest jak Magic. Uruchom go, połącz z serwerem SQL i kliknij Napraw

Stara wersja, do której link znajduje się tutaj, działała na serwerze SQL 2017.

Menedżer konfiguracji Kerberos dla SQL Server https://www.microsoft.com/en-us/download/details.aspx?id=39046

W mojej sytuacji próbowałem użyć Integrated Security, aby połączyć się z komputerem PC z serwerem SQL na innym komputerze w sieci bez domeny. Na obu komputerach logowałem się do systemu Windows przy użyciu tego samego konta Microsoft . I przełączane do konta lokalnego na obu komputerach i SQL Server teraz łączy się pomyślnie.

W moim przypadku, odkąd pracowałem w swoim środowisku programistycznym, ktoś wyłączył kontroler domeny i poświadczenia systemu Windows nie mogły zostać uwierzytelnione. Po włączeniu kontrolera domeny błąd zniknął i wszystko działało dobrze.

Kolejna nisza tego problemu spowodowana połączeniami sieciowymi. Łączę się przez klienta VPN dla systemu Windows i ten problem pojawił się po przełączeniu się z Wi-Fi na połączenie przewodowe. Rozwiązaniem w mojej sytuacji było ręczne dostosowanie metryki adaptera.

W programie PowerShell użyj Get-NetIPInterface, aby wyświetlić wszystkie wartości metryki. Niższe liczby są tańsze i dlatego są preferowane przez okna. Zmieniłem Ethernet i VPN, a poświadczenia dotarły tam, gdzie były potrzebne, aby SSMS był szczęśliwy.

Aby skonfigurować funkcję Metryki automatyczne: W Panelu sterowania kliknij dwukrotnie opcję Połączenia sieciowe. Kliknij prawym przyciskiem myszy interfejs sieciowy, a następnie wybierz Właściwości. Kliknij Protokół internetowy (TCP / IP), a następnie wybierz Właściwości. Na karcie Ogólne wybierz opcję Zaawansowane. Aby określić metrykę, na karcie Ustawienia IP zaznacz pole wyboru Metryka automatyczna, aby je wyczyścić, a następnie wprowadź żądaną metrykę w polu Metryka interfejsu.

Źródło: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes

Natknąłem się na wariant tego problemu, oto cechy:

• Użytkownik mógł pomyślnie połączyć się z nazwaną instancją, na przykład połączenia z nią Server\Instancezakończyły się powodzeniem
• Użytkownik nie mógł połączyć się z domyślną instancją, na przykład połączenia z Servernie powiodły się ze zrzutem ekranu OP dotyczącego SSPI
• Użytkownik nie mógł połączyć się z domyślną instancją o pełnej nazwie, na przykład połączenia z Server.domain.comnieudanymi (przekroczono limit czasu)
• Użytkownik nie mógł połączyć się z adresem IP bez nazwanej instancji, na przykład połączenia z 192.168.1.134nieudanymi
• Inni użytkownicy spoza domeny (na przykład użytkownicy korzystający z VPN do sieci), ale korzystający z poświadczeń domeny, mogli pomyślnie połączyć się z domyślną instancją i adresem IP

Po wielu bólach głowy związanych z próbą ustalenia, dlaczego ten pojedynczy użytkownik nie mógł się połączyć, oto kroki, które podjęliśmy, aby naprawić sytuację:

1. Spójrz na serwer na liście SPN, używając
   setspn -l Server
   pliku. W naszym przypadku powiedziałServer.domain.com
2. Dodaj wpis do pliku hosts znajdującego się w C:\Windows\System32\drivers\etc\hosts(uruchom Notatnik jako Administrator, aby zmienić ten plik). Wpis, który dodaliśmy, to
   Server.domain.com Server

Po tym byliśmy w stanie pomyślnie połączyć się przez SSMS z domyślną instancją.

Ja również miałem ten problem na SQL Server 2014 podczas logowania z uwierzytelnianiem systemu Windows, aby rozwiązać problem, który raz uruchomiłem ponownie serwer, a następnie spróbowałem się zalogować, zadziałało to dla mnie.