Problemen met SQL Server Kerberos en authenticatiefouten met gMSA’s oplossen

Van toepassing op: SQL Server op Windows

Overzicht

Dit artikel helpt u bij het oplossen van kerberos-, gekoppelde server- en beschikbaarheidsgroepverificatiefouten wanneer SQL Server wordt uitgevoerd onder een door een groep beheerd serviceaccount (gMSA). Deze fouten hebben dezelfde oorzaken of het serviceaccount een gMSA- of een domeingebruikersaccount is. Gebruik de volgende verwijzingen voor een volledig diagnostisch pad:

Gebruik de volgende secties voor de verschillen die alleen van toepassing zijn op gMSA's, zoals het eigendom, delegering en eindpuntmachtigingen van de service-principalnaam (SPN).

Voordat u begint, controleert u de vereisten en voert u de controlelijst voor snelle validatie uit in Probleemoplossing SQL Server installatie-, opstart- en verificatiefouten met gMSA's.

fouten met Kerberos of SPN

SPN's voor de gMSA controleren

  • Maak een lijst met SPN's met de computeraccountvorm van de naam. Een gMSA is een computerklasseobject, dus voor de accountnaam is een afsluitend dollarteken vereist.

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

  • Controleer of automatische SPN-registratie mogelijk is. SQL Server registreert de SPN alleen bij het opstarten als het serviceaccount naar een eigen servicePrincipalName kenmerk kan schrijven. Als de gMSA niet over deze machtiging beschikt, meldt het SQL Server foutenlogboek dat de SPN niet kan worden geregistreerd en moet een beheerder deze handmatig registreren. Zie Een service-principalnaam registreren voor Kerberos-verbindingen voor meer informatie.

  • Controleer het eigendom van SPN opnieuw nadat een serviceaccount is gewijzigd. SPN's die zijn geregistreerd op het vorige account, blijven op dat account staan. Verplaats of verwijder ze zodat de verwachte MSSQLSvc SPN precies één eigenaar heeft: de gMSA waaronder SQL Server nu wordt uitgevoerd.

Kerberos-verificatie voor de gMSA verifiëren

  1. Voer de volgende opdracht uit op de client voordat u de test opnieuw uitvoert.

    klist purge

  2. Maak opnieuw verbinding vanaf een externe Windows geverifieerde sessie en voer de volgende query uit.

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

    Verwacht resultaat: een nieuwe externe verbinding met Windows-verificatie vermeldt KERBEROS.

Zie de volgende verwijzingen voor ontbrekende, dubbele of verkeerd geplaatste SPN's en voor Kerberos-Configuration Manager:

Fouten met gekoppelde servers of double-hop

Een gekoppelde server die gebruikmaakt van de huidige beveiligingscontext mislukt met NT AUTHORITY\ANONYMOUS LOGON wanneer bij de tweede hop de gebruikersidentiteit niet kan worden gedelegeerd. U hebt juiste SPN's nodig, maar ze schakelen de tweede hop niet zelf in.

Delegatie controleren voor de gMSA

  • Configureer beperkte delegatie voor het gMSA-object door msDS-AllowedToDelegateTo in te stellen, of door resourcegebaseerde beperkte delegatie op de bestemming te configureren. Delegering die is geconfigureerd voor een gebruikersaccount, is niet van toepassing.
  • Als u het serviceaccount van een domeingebruikersaccount hebt gewijzigd in een gMSA, controleert u of de delegeringsinstellingen opnieuw zijn gemaakt op de gMSA. Delegatie gaat niet mee met de SPN.

Controleer de eerste hop voordat u delegatie onderzoekt.

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;

Verwacht resultaat: de eerste hop rapporteert KERBEROS.

Zie de volgende verwijzingen voor het volledige diagnostische pad met dubbele hops:

Authenticatiefouten van replica’s van beschikbaarheidsgroepen

Connectiviteit van beschikbaarheidsgroepen is afhankelijk van eindpuntstatus, URL en poort, firewall, DNS, CONNECT machtiging en verificatie van serviceaccounts. Valideer deze afzonderlijk van client Kerberos en gebruik alleen SPN-bewijs wanneer de fout specifiek Kerberos of SSPI aangeeft.

Eindpuntmachtigingen voor de gMSA controleren

  • Verleen CONNECT op het databasespiegelingseindpunt aan de gMSA-login in de vorm [CONTOSO\SQLgMSA$] op elke replica. Een aanmelding die is gemaakt voor het vorige serviceaccount, autoriseert de gMSA niet.
  • Als replica's worden uitgevoerd onder verschillende gMSA's, controleert u of elke replica een aanmelding en CONNECT machtiging heeft voor elk partnerserviceaccount.
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';

Verwacht resultaat: het eindpunt is STARTED, de poort is bereikbaar en de replicastatus wordt voortgezet naar CONNECTED.

Zie Beschikbaarheidsreplica is losgekoppeld binnen een Always On-beschikbaarheidsgroep en Problemen met de configuratie van Always On-beschikbaarheidsgroepen oplossen voor het oplossen van problemen met eindpunten, firewalls en connectiviteit die niet specifiek zijn voor het serviceaccount.

Diagnostische gegevens verzamelen

Als de verificatie nog steeds mislukt nadat u deze stappen hebt voltooid, verzamelt u diagnostische gegevens van de SQL Server host en elke betrokken replica voor hetzelfde foutinterval. Zie Diagnostische gegevens verzamelen in het overzicht van het oplossen van problemen met gMSA voor het verzamelen van gMSA-specifieke gegevens en standaardlogboeken SQL Server. Gebruik deze gegevens om door te gaan met het onderzoek of om een ondersteuningsaanvraag te openen.

Verwante onderwerpen

  • Laatst bijgewerkt om