Błąd „Nie można wygenerować kontekstu interfejsu SSPI“ podczas korzystania z uwierzytelniania systemu Windows w celu nawiązania połączenia z serwerem SQL
Dotyczy: SQL Server
Oryginalny numer KB: 811889
Uwaga
Przed rozpoczęciem rozwiązywania problemów zalecamy sprawdzenie wymagań wstępnych i listy kontrolnej.
Podczas zdalnego łączenia wystąpienia serwera SQL przy użyciu uwierzytelniania systemu Windows jest wyświetlany następujący komunikat o błędzie:
Głowna nazwa celu jest niepoprawna. Nie można wygenerować kontekstu interfejsu SSPI.
Często zadawane pytania
Co to jest interfejs SSPI?
Interfejs dostawcy obsługi zabezpieczeń (SSPI) to zestaw interfejsów API systemu Windows, który umożliwia delegowanie i wzajemne uwierzytelnianie za pośrednictwem dowolnej ogólnej warstwy transportu danych, takiej jak gniazda TCP/IP. Co najmniej jeden moduł oprogramowania zapewnia rzeczywiste możliwości uwierzytelniania. Każdy moduł jest nazywany dostawcą obsługi zabezpieczeń (SSP) i jest implementowany jako biblioteka dynamicznego łącza (DLL).
Czym jest protokół Kerberos?
Protokół Kerberos v5 jest standardowym pakietem zabezpieczeń branżowym i jest jednym z trzech pakietów zabezpieczeń w systemach operacyjnych Windows. Aby uzyskać więcej informacji, zobacz artykuł pt. Dostawca obsługi zabezpieczeń (SSP).
Co oznacza błąd „Nie można wygenerować kontekstu interfejsu SSPI“?
Ten błąd oznacza, że interfejs SSPI próbuje, ale nie może używać uwierzytelniania Kerberos do delegowania poświadczeń klienta za pośrednictwem protokołu TCP/IP lub nazwanych potoków do serwera SQL. W większości przypadków błędnie skonfigurowana główna nazwa usługi (SPN) powoduje ten błąd.
Czym jest główna nazwa usługi (SPN)?
Główna nazwa usługi (SPN) to unikatowy identyfikator wystąpienia usługi. Główne nazwy usługi są używane przez uwierzytelnianie Kerberos do kojarzenia wystąpienia usługi z kontem logowania usługi. Ten proces skojarzenia umożliwia aplikacji klienckiej zażądanie od usługi uwierzytelnienia konta, nawet jeśli klient nie ma nazwy konta.
Na przykład typowa główna nazwa usługi dla serwera z uruchomionym wystąpieniem serwera SQL jest następująca:
MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433
Format głównej nazwy usługi dla wystąpienia domyślnego jest taki sam jak ta nazwa dla wystąpienia nazwanego. Numer portu jest tym, co wiąże główną nazwę usługi z konkretnym wystąpieniem. Aby uzyskać więcej informacji na temat rejestrowania głównej nazwy usługi serwera SQL, zobacz artykuł pt. Rejestrowanie głównej nazwy usługi dla połączeń protokołu Kerberos.
Dlaczego interfejs SSPI używa uwierzytelniania NTLM lub Kerberos?
Uwierzytelnianie systemu Windows jest preferowaną metodą uwierzytelniania użytkowników na serwerze SQL. Klienci korzystający z uwierzytelniania systemu Windows są uwierzytelniani za pomocą protokołu NTLM lub Kerberos.
Gdy klient serwera SQL korzysta ze zintegrowanych zabezpieczeń za pośrednictwem gniazd TCP/IP na serwerze zdalnym z uruchomionym oprogramowaniem SQL Server, biblioteka sieci klienta serwera SQL używa interfejsu API SSPI do wykonywania delegowania zabezpieczeń. Klient sieci oprogramowania SQL Server wywołuje funkcję AcquireCredentialsHandle i przekazuje ciąg "negotiate" dla parametru pszPackage. Ten proces powiadamia źródłowego dostawcę zabezpieczeń o negocjowaniu delegowania. W tym kontekście ciąg „negotiate“ oznacza wypróbowanie uwierzytelniania Kerberos lub NTLM na komputerach z systemem Windows. Innymi słowy, system Windows używa delegowania protokołu Kerberos, jeśli komputer docelowy z oprogramowaniem SQL Server ma skojarzoną i poprawnie skonfigurowaną główną nazwę usługi. W przeciwnym razie system Windows używa delegowania NTLM. Jeśli klient oprogramowania SQL Server łączy się lokalnie na tej samej maszynie, na której znajduje się serwer SQL, zawsze jest używany protokół NTLM.
Dlaczego połączenie nie przechodzi w tryb failover do protokołu NTLM po napotkaniu problemów z protokołem Kerberos?
Kod sterownika serwera SQL na kliencie używa interfejsu API sieci WinSock, aby rozpoznać w pełni kwalifikowany serwer DNS serwera, gdy sterownik używa uwierzytelniania systemu Windows do nawiązywania połączenia z serwerem SQL. Aby wykonać tę operację, kod sterownika wywołuje gethostbyname i gethostbyaddr interfejsów WinSock. Jeśli są używane zintegrowane zabezpieczenia, sterownik spróbuje rozpoznać w pełni kwalifikowany serwer DNS, nawet jeśli adres IP lub nazwa hosta jest przekazywana jako nazwa serwera.
Gdy sterownik serwera SQL na kliencie rozpoznaje w pełni kwalifikowany serwer DNS serwera, odpowiedni serwer DNS jest używany do tworzenia głównej nazwy usługi dla serwera. W związku z tym problemy z rozpoznawaniem adresu IP lub nazwy hosta w pełni kwalifikowanym serwerze DNS przez usługę WinSock mogą spowodować, że sterownik serwera SQL utworzy nieprawidłową główną nazwę usługi dla serwera.
Na przykład sterownik serwera SQL po stronie klienta może służyć jako w pełni kwalifikowany serwer DNS do rozpoznawania nieprawidłowych głównych nazw usługi w następujący sposób:
MSSQLSvc/SQLSERVER1:1433MSSQLSvc/123.123.123.123:1433MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433
Gdy sterownik serwera SQL tworzy nieprawidłową główną nazwę usługi, uwierzytelnianie nadal działa, ponieważ interfejs SSPI próbuje wyszukać główną nazwę usługi w usłudze Active Directory. Jeśli interfejs SSPI nie znajdzie głównej nazwy usługi, uwierzytelnianie Kerberos nie zostanie wykonane. W tym momencie warstwa interfejsu SSPI przełącza się w tryb uwierzytelniania NTLM, a logowanie używa uwierzytelniania NTLM i zwykle kończy się powodzeniem. Jeśli sterownik serwera SQL tworzy prawidłową główną nazwę usługi, która nie jest przypisana do odpowiedniego kontenera, sterownik próbuje główną nazwę usługi, ale nie może jej używać. W takim przypadku może wystąpić błąd „Nie można wygenerować kontekstu SSPI”. Jeśli konto uruchamiania SQL Server jest kontem systemu lokalnego, odpowiednim kontenerem jest nazwa komputera. W przypadku dowolnego innego konta odpowiednim kontenerem jest konto uruchamiania SQL Server. Uwierzytelnianie używa pierwszej wyszukanej nazwy SPN, dlatego upewnij się, że żadne nazwy SPN nie są przypisane do nieprawidłowych kontenerów. Innymi słowy każda nazwa SPN musi być przypisana tylko do jednego kontenera.
Jak mogę zweryfikować metodę uwierzytelniania połączenia?
Aby określić metodę uwierzytelniania połączenia, uruchom następujące zapytanie:
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
Aby uzyskać więcej informacji, zobacz Określanie, czy mam połączenie z SQL Server przy użyciu uwierzytelniania Kerberos.
Jak utworzyć nazwy SPN dla SQL Server?
Po uruchomieniu wystąpienia aparatu bazy danych SQL Server, program SQL Server próbuje automatycznie zarejestrować nazwę SPN dla usługi SQL Server przy użyciu interfejsu API DsWriteAccountSpn. To wywołanie powiedzie się, jeśli konto usługi SQL Server ma prawa do odczytu servicePrincipalName i zapisu servicePrincipalName w usłudze Active Directory. W przeciwnym razie administrator usługi Active Directory będzie musiał ręcznie zarejestrować poprawną nazwę SPN przy użyciu programu Microsoft Kerberos Manager dla SQL Server lub wbudowanego narzędzia Setspn. Aby uzyskać więcej informacji na temat zarządzania nazwami SPN dla SQL Server, zobacz Rejestrowanie głównej nazwy usługi dla połączeń Kerberos.
Napraw błąd przy użyciu narzędzia Kerberos Configuration Manager (zalecane)
Uwaga
Ta procedura dotyczy tylko sytuacji, w których te komunikaty o błędach są odbierane przez cały czas, a nie sporadycznie.
Istnieją różne przyczyny niepowodzenia połączeń protokołu Kerberos, takie jak błędnie skonfigurowane nazwy SPN, problemy z rozpoznawaniem nazw lub niewystarczające prawa do kont uruchamiania usługi SQL Server. Microsoft Kerberos Configuration Manager (KCM) to narzędzie, które może pomóc w sprawdzeniu przyczyn błędu. Narzędzie KCM udostępnia również opcje rozwiązywania wszelkich zidentyfikowanych problemów w tym procesie.
Wykonaj następujące kroki, aby naprawić błąd przy użyciu narzędzia KCM.
Na komputerze, na którym występują problemy z łącznością, pobierz i zainstaluj narzędzie Kerberos Configuration Manager.
Uruchom plik KerberosConfigMgr.exe z folderu %SystemDrive%:\Program Files\Microsoft\Kerberos Configuration Manager. Następnie użyj konta domeny z uprawnieniami do nawiązywania połączenia z komputerem SQL Server, z którym nie możesz nawiązać połączenia.
Wybierz pozycję Połącz, pozostawiając pustą nazwę serwera i inne szczegóły dotyczące danego scenariusza, jeśli używasz narzędzia KCM na komputerze SQL Server. Wybierz pozycję Połącz, aby przeprowadzić analizę. Po zakończeniu pobierania niezbędnych informacji narzędzie KCM automatycznie przełącza się na kartę SPN i domyślnie wyświetla informacje dotyczące SQL Server, SQL Server Reporting Services, usług Analysis Services i odbiorników grupy dostępności. Aby rozwiązać ten błąd, usuń zaznaczenie wszystkich elementów z wyjątkiem SQL Server.
Przejrzyj diagnostykę z narzędzia przy użyciu kolumny Stan i wykonaj odpowiednie kroki, aby rozwiązać ten problem:
Stan Więcej informacji Akcja Dobry Zaznaczony element jest poprawnie skonfigurowany. Możesz przejść do następnego elementu w danych wyjściowych. Nie trzeba wykonywać żadnych działań Brak wymaganej nazwy SPN Ten stan jest zgłaszany, gdy brakuje nazwy SPN zidentyfikowanej w kolumnie Wymagana nazwa SPN dla konta uruchamiania SQL Server w usłudze Active Directory. 1. Wybierz pozycję Napraw, aby przejrzeć informacje w oknie dialogowym Ostrzeżenie.
2. Wybierz pozycję Tak, aby dodać brakującą nazwę SPN do usługi Active Directory.
3. Jeśli konto domeny ma uprawnienia niezbędne do aktualizacji usługi Active Directory, wymagana nazwa SPN zostanie dodana do usługi Active Directory.
4. Jeśli konto domeny nie ma niezbędnych uprawnień do aktualizacji usługi Active Directory, użyj polecenia Generuj lub wygeneruj wszystko , aby wygenerować skrypt, który pomoże administratorowi usługi Active Directory dodać brakujące nazwy SPN.
5. Po dodaniu nazw SPN uruchom ponownie narzędzie Kerberos Configuration Manager, aby sprawdzić, czy problemy z nazwą SPN zostały rozwiązane.
6. Ponadto można użyć następujących poleceń:
— SłużySETSPN -Q spnNamedo lokalizowania nazwy SPN i jej bieżących kont.
— Użyj poleceniaSETSPN -D, aby usunąć nazwę SPN z nieprawidłowego konta.Aby korzystać z konfiguracji protokołu Kerberos, należy włączyć protokół TCP Dzieje się tak, gdy protokół TCP nie jest włączony na komputerze klienckim. Aby włączyć protokół TCP/IP dla wystąpienia SQL Server, wykonaj następujące kroki:
1. W programie SQL Server Configuration Manager w okienku konsoli rozwiń węzeł Konfiguracja sieci SQL Server.
2. W okienku konsoli wybierz pozycję Protokoły jako <nazwę> wystąpienia.
3. W okienku szczegółów kliknij prawym przyciskiem myszy pozycję TCP/IP, a następnie kliknij pozycję Włącz.
4. W okienku konsoli wybierz pozycję SQL Server Services.
5. W okienku szczegółów kliknij prawym przyciskiem myszy pozycję SQL Server (<nazwa> wystąpienia), a następnie wybierz pozycję Uruchom ponownie, aby zatrzymać i ponownie uruchomić usługę SQL Server.
Aby uzyskać więcej informacji, zobacz Włączanie lub wyłączanie protokołu sieciowego serwera.Port dynamiczny Ten komunikat jest wyświetlany dla nazwanych wystąpień korzystających z portów dynamicznych (konfiguracja domyślna). W środowiskach, w których należy użyć protokołu Kerberos w celu nawiązania połączenia z SQL Server, należy ustawić nazwane wystąpienie na port statyczny i użyć tego portu podczas rejestrowania nazwy SPN. Aby skonfigurować wystąpienie SQL Server do korzystania z portu statycznego, wykonaj następujące kroki:
1. W SQL Server Configuration Manager w okienku konsoli rozwiń węzeł SQL Server Konfiguracja sieci, rozwiń węzeł Protokoły dla <nazwy> wystąpienia, a następnie kliknij dwukrotnie protokół TCP/IP.
2. W oknie dialogowym Właściwości protokołu TCP/IP przejrzyj ustawienie Nasłuchiwanie wszystkich na karcie Protokół.
3. Jeśli ustawienie Nasłuchiwanie wszystkich jest ustawione na wartość Tak, przejdź do karty Adresy IP i przewiń do dołu systemu Windows, aby znaleźć ustawienie IPAll. Usuń bieżącą wartość zawartą w portach dynamicznych TCP i ustaw żądaną wartość w polu Port TCP. Wybierz przycisk OK i uruchom ponownie wystąpienie SQL Server, aby ustawienia zostały zastosowane.
4. Jeśli ustawienie Nasłuchiwanie wszystkich jest ustawione na wartość Nie, przejdź do karty Adresy IP i sprawdź każdy z adresów IP wyświetlanych w adresie IP1, IP2. W przypadku włączonych adresów IP usuń bieżącą wartość zawartą w polu Porty dynamiczne TCP i ustaw żądaną wartość w polu Port TCP. Wybierz przycisk OK i uruchom ponownie wystąpienie SQL Server, aby ustawienia zostały zastosowane.
Aby uzyskać więcej informacji, zobacz Konfigurowanie serwera do nasłuchiwania na określonym porcie TCP.Zduplikowana nazwa SPN Może wystąpić sytuacja, gdy ta sama nazwa SPN jest zarejestrowana na różnych kontach w usłudze Active Directory. 1. Wybierz przycisk Napraw, wyświetl informacje w oknie dialogowym Ostrzeżenie i wybierz pozycję Tak, jeśli możesz dodać brakującą nazwę SPN do usługi Active Directory.
2. Jeśli konto domeny ma uprawnienia niezbędne do aktualizacji usługi Active Directory, nieprawidłowa nazwa SPN zostanie usunięta.
3. Jeśli konto domeny nie ma niezbędnych uprawnień do aktualizacji usługi Active Directory, użyj przycisku Generuj lub wygeneruj wszystko, aby wygenerować niezbędny skrypt, który można przekazać administratorowi usługi Active Directory w celu usunięcia zduplikowanych nazw SPN. Po usunięciu nazw SPN uruchom ponownie KCM, aby sprawdzić, czy problemy z nazwą SPN zostały rozwiązane.Uwaga
Jeśli konto domeny, które uruchamia narzędzie KCM, nie ma uprawnień do manipulowania nazwami SPN w usłudze Active Directory, możesz użyć odpowiedniego przycisku Generuj lub Wygeneruj wszystko w kolumnie skryptu SPN, aby wygenerować wymagane polecenia i współpracować z administratorem usługi Active Directory, aby rozwiązać problemy identyfikowane przez KCM.
Po rozwiązaniu wszystkich problemów zidentyfikowanych w narzędziu KCM uruchom ponownie narzędzie. Upewnij się, że nie zgłoszono żadnych innych problemów, a następnie ponów próbę nawiązania połączenia. Jeśli narzędzie nadal zgłasza problemy, powtórz poprzednią procedurę.
Napraw błąd bez narzędzia Kerberos Configuration Manager
Jeśli nie możesz użyć narzędzia KCM, wykonaj następujące kroki:
Krok 1. Sprawdzanie rozpoznawania nazw za pomocą polecenia ping
Kluczowym czynnikiem, który sprawia, że uwierzytelnianie Kerberos powiodło się, jest prawidłowa funkcja DNS w sieci. Tę funkcjonalność można sprawdzić na kliencie i serwerze przy użyciu narzędzia wiersza polecenia Ping. Na komputerze klienckim uruchom następujące polecenie, aby uzyskać adres IP serwera, na którym działa SQL Server (gdzie nazwa komputera to SQLServer1):
ping sqlserver1
Aby sprawdzić, czy narzędzie Ping rozpoznaje w pełni kwalifikowany system DNS programu SQLServer1, uruchom następujące polecenie:
ping -a <IPAddress>
Przykład:
C:\>ping SQLSERVER1
Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>ping -a 123.123.123.123
Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>
Gdy polecenie ping -a <IPAddress> rozpozna poprawny w pełni kwalifikowany system DNS komputera z uruchomionym programem SQL Server, rozpoznawanie po stronie klienta również zakończy się pomyślnie.
Aby uzyskać szczegółową diagnostykę, użyj polecenia cmdlet Test-NetConnection lub Test-Connection, aby przetestować łączność TCP zgodnie z wersją programu PowerShell zainstalowaną na komputerze. Aby uzyskać więcej informacji dotyczących tego polecenia cmdlet PowerShell, zobacz sekcję Przegląd polecenia cmdlet.
Uwaga
Metody rozpoznawania nazw mogą obejmować pliki DNS, WINS, Hosts i Lmhosts. Aby uzyskać więcej informacji na temat problemów z rozpoznawaniem nazw i rozwiązywaniem problemów, zapoznaj się z następującymi linkami:
Sprawdź, czy w programie SQL Server Configuration Manager i w narzędziu SQL Server Client Network istnieją aliasy docelowe SQL Server. Jeśli taki alias istnieje, upewnij się, że jest poprawnie skonfigurowany, sprawdzając nazwy serwerów, protokół sieciowy, numer portu itd. Alias programu SQL Server może spowodować wygenerowanie nieoczekiwanej nazwy SPN. Spowoduje to poświadczenie NTLM, jeśli nazwa SPN nie zostanie znaleziona lub awaria interfejsu SSPI, jeśli przypadkowo pasuje do nazwy SPN innego serwera.
Krok 2. Weryfikowanie komunikacji między domenami
Sprawdź, czy zalogowana domena może komunikować się z domeną serwera z programem SQL Server. W domenie musi być również poprawne rozpoznawanie nazw.
Upewnij się, że możesz zalogować się do systemu Windows przy użyciu tego samego konta domeny i hasła co konto uruchamiania usługi SQL Server. Na przykład błąd SSPI może wystąpić w jednej z następujących sytuacji:
- Konto domeny jest zablokowane.
- Usługa SQL Server nie została ponownie uruchomiona po zmianie hasła konta.
Jeśli domena logowania różni się od domeny serwera, na którym działa SQL Server, sprawdź relację zaufania między domenami.
Sprawdź, czy domena, do której należy serwer oraz konto domeny używane do nawiązywania połączenia znajdują się w tym samym lesie. Ten krok jest wymagany do działania interfejsu SSPI.
Krok 3. Weryfikowanie SQL Server nazw SPN przy użyciu narzędzi SQLCHECK i Setspn
Jeśli możesz zalogować się lokalnie na komputerze SQL Server i mieć dostęp administratora, użyj programu SQLCHECK. Narzędzie SQLCheck udostępnia większość informacji wymaganych do rozwiązywania problemów w jednym pliku. Aby uzyskać więcej informacji na temat korzystania z narzędzia i informacji, które zbiera, przejrzyj stronę główną narzędzia. Możesz również sprawdzić zalecane wymagania wstępne i stronę listy kontrolnej. Po wygenerowaniu pliku wyjściowego przejrzyj konfigurację nazwy SPN dla wystąpienia SQL Server w sekcji Informacje o programie SQL Server pliku wyjściowego.
Przykładowe dane wyjściowe:
Suggested SPN Exists Status
---------------------------------------------------------- ------ -------------------
MSSQLSvc/testsqlsvr.corp.com:2000 True Okay
MSSQLSvc/testsqlsvr.corp.com True Okay
MSSQLSvc/testsqlsvr:2000 False SPN does not exist.
MSSQLSvc/testsqlsvr False SPN does not exist.
Użyj powyższych danych wyjściowych, aby określić kolejne kroki (zobacz przykłady poniżej) i użyć narzędzia Setspn do podjęcia niezbędnych działań naprawczych w celu rozwiązania problemów z nazwą SPN.
| Scenariusz | Sugerowane działania |
|---|---|
| Nazwa SPN nie istnieje | Dodaj wymagane nazwy SPN dla konta usługi SQL Server. |
| Zduplikowane nazwy SPN | Usuń nazwę SPN zarejestrowaną dla usługi SQL w ramach nieprawidłowego konta. |
| Nazwa SPN w ramach nieprawidłowego konta | Usuń zarejestrowaną nazwę SPN dla usługi SQL w ramach nieprawidłowego konta, a następnie zarejestruj nazwę SPN na odpowiednim koncie usługi. |
Uwaga
Możesz przejrzeć sekcję SQL Server Information pliku wyjściowego narzędzia SQLCHECK, aby znaleźć konto usługi wystąpienia SQL Server.
Setspn to wbudowane narzędzie w nowszych wersjach systemu Windows, które ułatwia odczytywanie, dodawanie, modyfikowanie lub usuwanie nazw SPN w usłudze Active Directory. Za pomocą tego narzędzia możesz sprawdzić, czy nazwy SPN programu SQL Server są skonfigurowane zgodnie z instrukcją Rejestrowanie głównej nazwy usługi dla połączeń Kerberos. Aby uzyskać więcej informacji, zobacz Narzędzie Setspn i przykłady dotyczące sposobu jego używania.
Aby uzyskać więcej informacji na temat scenariuszy, w których SQL Server automatycznie rejestruje nazwy SPN i gdzie wymagana jest ręczna rejestracja nazwy SPN, zobacz Rejestrowanie głównej nazwy usługi dla połączeń Kerberos.
Krok 4. Sprawdzanie uprawnień konta dla konta SQL Server uruchamiania na połączonym serwerze
Jeśli użyjesz opcji Personifikuj jako opcji uwierzytelniania na stronie Zabezpieczenia połączonego serwera, od programu SQL Server wymaga się przekazanie poświadczeń przychodzących do zdalnego programu SQL Server. Konto uruchamiania SQL Server, w którym zdefiniowano serwer połączony, powinno mieć przypisane uprawnienie Konto jest zaufane w kwestii delegowania w usłudze Active Directory. Aby uzyskać więcej informacji, zobacz Włączanie zaufania kont komputerów i użytkowników w kwestii delegowania.
Uwaga
Ten krok jest wymagany tylko w przypadku rozwiązywania problemów związanych z połączonymi zapytaniami serwera.
Zobacz też
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla