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

89

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.

wprowadź opis obrazu tutaj

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.

Krawędź
źródło
Nie prowadzimy wewnętrznego serwera DNS. Ale czy chcesz wyeliminować ten problem jako problem, mówisz, że powinienem wykonać polecenie „ping -a xxxx”, czy też jest inny sposób określenia, czy istnieją duplikaty?
TheEdge
Nie jestem ekspertem, ale myślałem, że nazwy SPN i SSPI to kwestia protokołu Kerberos? Czy na pewno nie używasz protokołu Kerberos?
Dylan Smith
@DylanSmith Nie żebym mógł zobaczyć ..... Kiedy uruchomiłem SP w SQL Server (zapomnij teraz nazwę) wszystko wyszło jako NTLM. Czy wiesz, jak sprawdzam?
TheEdge
Wiem, że pytanie jest stare, więc oszczędzaj czas i uruchom to narzędzie: microsoft.com/en-us/download/…
Eduardo

Odpowiedzi:

57

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.

Slothario
źródło
1
To był mój problem. Hasło zostało zmienione. moje konto obsługuje pulę aplikacji.
Dragos Durlut
kiedy miałem ten problem, wylogowałem się i zaloguj ponownie. Rozwiązano problem.
shary.sharath
Podobny problem. To pomogło mi spojrzeć wstecz na moje działania. TQ
Reddy
24

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ń.

Matt Shepherd
źródło
22

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

Anatolijewicz
źródło
Jak to usunąć, jeśli połączenie odbywa się za pośrednictwem programu SSMS?
Geoff Dawdy
23
Cóż, najwyraźniej usunięcie Integrated Security będzie uniknąć tego błędu, ponieważ błąd występuje podczas próby logowania z poświadczeniami Windows. Niestety w większości przypadków chcesz mieć możliwość logowania się przy użyciu poświadczeń systemu Windows!
Auspex
2
@GeoffDawdy moja odpowiedź poniżej może pomóc? Było to spowodowane wygasłym hasłem, które wymagało zmiany hasła, wylogowania się i ponownego zalogowania, a potem wszystko działało normalnie.
Matt Shepherd,
3
Oszczędzaj czas i uruchom to narzędzie: microsoft.com/en-us/download/…
Eduardo,
15

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.

Abubakar Mehmood
źródło
12

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.

Don
źródło
To niedorzeczne. I zadziałało. Straciłem na to tyle czasu. Dziękuję Ci!
mcb2k3
2
Ups, to nie było to. SSMS włączył mnie, gdy nie patrzyłem, i wróciłem do mojego konta SQL Server. Ale w końcu spróbowałem przejść z używania konta Microsoft do logowania się lokalnie na używanie lokalnego konta. To załatwiło sprawę i wydaje się, że teraz działa, nawet jeśli loguję się przy użyciu mojego kodu PIN.
mcb2k3
Tak, używanie hasła zamiast kodu PIN również działało dla mnie. +1 dla Microsoft.
BrunoMartinsPro
O MÓJ BOŻE! Nie mogę uwierzyć, że to naprawdę coś zmieniło!
arni
8

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.

Alex
źródło
7

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

wprowadź opis obrazu tutaj

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/

Sarah
źródło
To rozwiązało problem. Nazwy SPN zostały zarejestrowane w niewłaściwym obiekcie użytkownika w usłudze Active Directory. Menedżer konfiguracji Kerberos dla SQL Server naprawił to dwa kliknięcia!
Craig - MSFT
6

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"

user685590
źródło
Miałem podobny problem (VPN iMac z maszyną wirtualną Windows). Rozwiązałem to, dodając serwery DNS mojej pracy do ustawień sieci Wi-Fi mojego Maca. Domyślam się, że jest lepszy sposób, ale to działa dla mnie.
Erik Pearson
5

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.

Frank, Niemcy
źródło
czy twoja odpowiedź na moim komputerze klienckim i SQL box plus ipconfig/releaseoraz ipconfig/renewna moim komputerze klienckim i nie działa dla mnie; (
AlbatrossCafe
4

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ą).

EM0
źródło
Zmieniłem instancję MS SQL Server z uruchamiania przy użyciu NT Service\MSSQLSSERVERna działanie jako zarządzane konto usługi. Po wykonaniu tej czynności SSMS może łączyć się z bazą danych lokalnie na serwerze, ale nie zdalnie z mojego laptopa. Naprawienie nazw SPN rozwiązało problem.
Hydrargyrum
4

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

mxasim
źródło
Jak wyżej SQL Server 2016.
youcantryreachingme
4

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.

Graham Walker
źródło
3

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
  1. 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>
    
  2. 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>
  1. 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

Nate S.
źródło
2

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ą.

Ramki
źródło
2

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.

Daniel Bailey
źródło
1

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ć.

Greg
źródło
Ten problem przytrafił mi się tylko wtedy, gdy dodałem certyfikat do połączenia SQL. Certyfikat został wystawiony dla FQDN, więc kiedy łączę się z FQDN \ Instance, zadziałało.
Slogmeister Extraordinaire
1

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.

CrainBramp
źródło
1

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ć.

Pytania 101
źródło
Miałem ten sam problem, ale nie dotyczy to klastra. Zmieniłem login usługi SQL Engine na konto domeny. Musiałem usunąć nazwy MSSQLSvc/SERVER_FQNName:*SPN z konta komputera, a następnie dodać je do konta użytkownika obsługującego usługę.
Slogmeister Extraordinaire
1

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.

AlbatrossCafe
źródło
Podobne doświadczenie, SQLServer 2016 na maszynie wirtualnej. Nie wiem, dlaczego połączenia zaczęły się zawodzić. Ponowne uruchomienie maszyny wirtualnej naprawiło to bez konieczności ponownego uruchamiania klienta.
youcantryreachingme
1

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.

Jeff
źródło
Oto, co zrobiłem po porównaniu setspn -L <Hostname>z serwerem, który działał. Okazało się, że wszystkie wystąpienia, które działały, nie miały zarejestrowanej nazwy SPN. Naprawdę nie wiem, co robię, ale najwyraźniej bez zarejestrowanych nazw SPN można używać NTLM. Dzięki!
BenderBoy
Pamiętaj, że nie jest to tak naprawdę rozwiązanie, jeśli chcesz używać protokołu Kerberos zamiast NTLM, jak najwyraźniej powinieneś: serverfault.com/a/384721 . W rzeczywistości to rozwiązanie zasadniczo wyłącza uwierzytelnianie Kerberos.
BenderBoy
1

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.

somu
źródło
1

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ę.

Julie
źródło
Właściwie ustawiłem mój na „TCP / IP”. Nie wiem, czy akt jego zmiany rozwiązał problem, czy konkretne ustawienie mojej sytuacji sieciowej ...
Zarepheth
1

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

Como ficou minha configuração do DNS

kbral
źródło
1

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.
S3minaki
źródło
1
Miałem tę samą wiadomość. Próbowałem połączyć się przez IP, więc zrobiłem tak, jak stackoverflow.com/users/8568873/s3minaki , czyli kroki 1-6, ale włączyłem TCP / IP zamiast Named Pipes. Również pod IPALL wyczyściłem TCP Dynamic port i zamiast tego ustawiłem TCP Port. Upewnij się, że żadna inna instancja nie uruchamia tego portu lub instancja nie uruchomi się ponownie. Potrzebowałem również użytkownika SQL, uwierzytelnianie systemu Windows nie zadziała. W SQL Manager łączysz się z xxxx \ nazwa_instancji, portnr. tj. 127.0.0.1 \ SQLEXPRESS, 1433
Tomas Hesse
1

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.

Michael Csikos
źródło
1

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.

El_01
źródło
1

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

user2442020
źródło
0

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ą.

sorrell
źródło
0

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.

harikrishna puppala
źródło