Rozwiązywanie problemów z błędami Kerberos i uwierzytelniania w SQL Server przy użyciu kont gMSA

Dotyczy: SQL Server w Windows

Podsumowanie

Ten artykuł ułatwia rozwiązywanie problemów z błędami uwierzytelniania protokołu Kerberos, serwera połączonego i grupy dostępności, gdy SQL Server działa w ramach konta usługi zarządzanego przez grupę (gMSA). Te błędy mają takie same przyczyny, czy konto usługi jest kontem gMSA, czy kontem użytkownika domeny. Aby przeprowadzić pełną diagnostykę, skorzystaj z następujących materiałów referencyjnych:

Skorzystaj z poniższych sekcji, aby zapoznać się z różnicami, które dotyczą wyłącznie kont usług zarządzanych grupowo (gMSA), takimi jak własność nazwy głównej usługi (SPN), delegowanie i uprawnienia punktu końcowego.

Przed rozpoczęciem zapoznaj się z wymaganiami wstępnymi i uruchom listę kontrolną szybkiego sprawdzania poprawności w temacie Rozwiązywanie problemów SQL Server z konfiguracją, uruchamianiem i błędami uwierzytelniania przy użyciu agentów gMSA.

Niepowodzenia protokołu Kerberos lub SPN

Sprawdź nazwy SPN dla konta usługi zarządzanej grupowo

  • Wyświetl listę identyfikatorów SPN w formie nazwy konta komputera. gMSA jest obiektem klasy Computer, więc nazwa konta wymaga znaku dolara na końcu.

    setspn -L CONTOSO\SQLgMSA$
setspn -Q MSSQLSvc/sql01.contoso.com:1433

  • Upewnij się, że automatyczna rejestracja nazwy SPN może zakończyć się pomyślnie. SQL Server rejestruje swoją nazwę SPN podczas uruchamiania tylko wtedy, gdy konto usługi może zapisywać własny servicePrincipalName atrybut. Jeśli konto gMSA nie ma tego uprawnienia, w dzienniku błędów programu SQL Server pojawia się informacja, że nie udało się zarejestrować SPN i administrator musi zarejestrować ten SPN ręcznie. Aby uzyskać więcej informacji, zobacz Rejestrowanie nazwy głównej usługi dla połączeń Kerberos.

  • Ponownie sprawdź właściciela SPN po zmianie konta usługi. SPN-y, które zostały zarejestrowane na poprzednim koncie, pozostają przypisane do tego konta. Przenieś je lub usuń, aby oczekiwany identyfikator SPN MSSQLSvc miał dokładnie jednego właściciela: konto gMSA, na którym jest teraz uruchomiony SQL Server.

Weryfikowanie uwierzytelniania Kerberos dla gMSA

  1. Uruchom następujące polecenie na kliencie przed ponownym testowaniem.

    klist purge

  2. Połącz się ponownie z zdalnej sesji uwierzytelnionej Windows i uruchom następujące zapytanie.

    SELECT c.auth_scheme, c.net_transport, c.client_net_address
FROM sys.dm_exec_connections AS c
WHERE c.session_id = @@SPID;

    Oczekiwany wynik: nowe zdalne połączenie uwierzytelniane przez system Windows zgłasza KERBEROS.

Informacje na temat brakujących, zduplikowanych lub nieprawidłowo przypisanych nazw SPN oraz Menedżera konfiguracji protokołu Kerberos można znaleźć w następujących materiałach:

Błędy serwera połączonego lub podwójnego przeskoku

Serwer połączony korzystający z bieżącego kontekstu zabezpieczeń kończy się niepowodzeniem, NT AUTHORITY\ANONYMOUS LOGON gdy drugi przeskok nie może delegować tożsamości użytkownika. Potrzebne są poprawne nazwy główne usług (SPN), ale same w sobie nie umożliwiają drugiego przeskoku.

Sprawdź delegację dla gMSA

  • Skonfiguruj ograniczone delegowanie dla obiektu gMSA, ustawiając msDS-AllowedToDelegateTo, lub konfigurując ograniczone delegowanie oparte na zasobach na zasobie docelowym. Delegowanie skonfigurowane na koncie użytkownika nie ma zastosowania.
  • Jeśli konto usługi zostało zmienione z konta użytkownika domeny na konto gMSA, upewnij się, że ustawienia delegowania zostały ponownie utworzone w gMSA. Delegacja nie jest przenoszona razem z identyfikatorem SPN.

Sprawdź pierwszy przeskok, zanim zaczniesz badać delegację.

SELECT ORIGINAL_LOGIN() AS original_login, SUSER_SNAME() AS execution_login, c.auth_scheme
FROM sys.dm_exec_connections AS c
WHERE c.session_id = @@SPID;

Oczekiwany wynik: pierwszy przeskok zgłasza KERBEROS.

Pełny proces diagnostyki podwójnego przeskakiwania opisano w następujących materiałach:

Błędy uwierzytelniania repliki grupy dostępności

Łączność grupy dostępności zależy od stanu punktu końcowego, adresu URL i portu, zapory, systemu DNS, CONNECT uprawnień i uwierzytelniania konta usługi. Zweryfikuj je oddzielnie od mechanizmu Kerberos po stronie klienta i używaj danych potwierdzających SPN tylko wtedy, gdy błąd wyraźnie wskazuje na Kerberos lub SSPI.

Sprawdź uprawnienia punktu końcowego dla gMSA

  • Przyznaj CONNECT w punkcie końcowym dublowania bazy danych loginowi gMSA w postaci [CONTOSO\SQLgMSA$] na każdej replice. Login utworzony dla poprzedniego konta usługi nie uprawnia do używania grupowego zarządzanego konta usługi (gMSA).
  • Jeśli repliki działają przy użyciu różnych kont gMSA, upewnij się, że każda replika ma login i uprawnienie CONNECT do każdego partnerskiego konta usługi.
SELECT ar.replica_server_name, ars.role_desc, ars.connected_state_desc, ars.synchronization_health_desc
FROM sys.availability_replicas AS ar
LEFT JOIN sys.dm_hadr_availability_replica_states AS ars ON ar.replica_id = ars.replica_id;

SELECT name, state_desc, type_desc, port
FROM sys.tcp_endpoints
WHERE type_desc = 'DATABASE_MIRRORING';

Oczekiwany wynik: punkt końcowy to STARTED, port jest osiągalny, a stan repliki przechodzi do CONNECTED.

Aby uzyskać informacje na temat rozwiązywania problemów dla punktu końcowego, zapory i łączności, które nie dotyczą konkretnie konta usługi, zobacz Replika dostępności jest odłączona w grupie dostępności Always On i Rozwiązywanie problemów z konfiguracją grup dostępności Always On.

Zbieranie danych diagnostycznych

Jeśli uwierzytelnianie nadal nie powiedzie się po wykonaniu tych kroków, zbierz dane diagnostyczne z hosta SQL Server i każdej repliki, której dotyczy problem, dla tego samego interwału awarii. Informacje o danych specyficznych dla gMSA i standardowych dziennikach programu SQL Server, które należy zebrać, można znaleźć w sekcji Zbieranie danych diagnostycznych w omówieniu rozwiązywania problemów z usługą gMSA. Użyj tych danych, aby kontynuować dochodzenie lub otworzyć zgłoszenie do działu pomocy technicznej.

Treści powiązane

  • Ostatnia aktualizacja o