Risolvere i problemi di Kerberos e gli errori di autenticazione di SQL Server con gli account del servizio gestiti di gruppo (gMSA)

Si applica a: SQL Server su Windows

Sommario

Questo articolo consente di risolvere gli errori di autenticazione di Kerberos, dei server collegati e dei gruppi di disponibilità quando SQL Server è in esecuzione con un account del servizio gestito di gruppo (gMSA). Questi errori hanno le stesse cause, sia che l'account del servizio sia un gMSA sia che sia un account utente del dominio. Per un percorso di diagnostica completo, usare i riferimenti seguenti:

Usa le sezioni seguenti per le differenze che si applicano solo ai gMSA, ad esempio la proprietà del nome dell'entità servizio (SPN), la delega e le autorizzazioni degli endpoint.

Prima di iniziare, esamina i prerequisiti ed esegui la checklist di convalida rapida in Risolvere i problemi di installazione, avvio e autenticazione di SQL Server con i gMSA.

Errori Kerberos o SPN

Controllare gli SPN per il gMSA

  • Elenca gli SPN nel formato del nome dell'account del computer. Un gMSA è un oggetto della classe computer, quindi il nome dell'account deve terminare con un simbolo di dollaro.

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

  • Verificare che la registrazione automatica del nome SPN abbia esito positivo. SQL Server registra il proprio SPN all'avvio solo se l'account del servizio può scrivere nel proprio attributo servicePrincipalName. Se il gMSA non dispone di tale autorizzazione, il log degli errori di SQL Server indica che non è stato possibile registrare l'SPN e quindi un amministratore deve registrarlo manualmente. Per altre informazioni, vedi Registrare un Service Principal Name per le connessioni Kerberos.

  • Verifica nuovamente il proprietario dell'SPN dopo una modifica dell'account di servizio. Gli SPN registrati nell'account precedente rimangono su tale account. Spostali o rimuovili in modo che l'SPN previsto MSSQLSvc abbia esattamente un solo proprietario: il gMSA con cui ora viene eseguito SQL Server.

Verificare l'autenticazione Kerberos per l'account gMSA

  1. Eseguire il comando seguente nel client prima di eseguire il nuovo test.

    klist purge

  2. Riconnettiti da una sessione remota autenticata tramite Windows ed esegui la query seguente.

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

    Risultato previsto: una nuova connessione remota autenticata tramite Windows riporta KERBEROS.

Per informazioni su SPN mancanti, duplicati o in posizione errata e su Kerberos Gestione configurazione, consultare i riferimenti seguenti:

Errori del server collegato o doppio hop

Un server collegato che usa il contesto di sicurezza corrente non riesce con NT AUTHORITY\ANONYMOUS LOGON quando il secondo hop non può delegare l'identità dell'utente. Sono necessari SPN corretti, ma da soli non abilitano il secondo hop.

Verificare la delega per il gMSA

  • Configurare la delega vincolata nell'oggetto gMSA impostando msDS-AllowedToDelegateToo configurando la delega vincolata basata su risorse nella destinazione. La delega configurata in un account utente non si applica.
  • Se l'account del servizio è stato modificato da un account utente di dominio a un gMSA, verificare che le impostazioni di delega siano state ricreate nel gMSA. La delega non viene trasferita insieme all'SPN.

Verificare il primo hop prima di analizzare la delega.

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;

Risultato previsto: il primo hop segnala KERBEROS.

Per il percorso di diagnostica a doppio hop completo, vedere i riferimenti seguenti:

Errori di autenticazione della replica del gruppo di disponibilità

La connettività del gruppo di disponibilità dipende dallo stato dell'endpoint, dall'URL e dalla porta, dal firewall, dal DNS, CONNECT dalle autorizzazioni e dall'autenticazione dell'account di servizio. Convalidarli separatamente da Kerberos client e usare l'evidenza SPN solo quando l'errore indica specificamente Kerberos o SSPI.

Controllare le autorizzazioni dell'endpoint per il gMSA

  • Concedi CONNECT sull'endpoint del mirroring del database all'account di accesso gMSA nel formato [CONTOSO\SQLgMSA$] in ogni replica. Un accesso creato per l'account di servizio precedente non autorizza il gMSA.
  • Se le repliche vengono eseguite con gMSA diversi, verificare che ogni replica disponga di un accesso e dell'autorizzazione CONNECT per ogni account di servizio partner.
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';

Risultato previsto: l'endpoint è STARTED, la porta è raggiungibile e lo stato della replica avanza fino a CONNECTED.

Per la risoluzione dei problemi relativi a endpoint, firewall e connettività che non riguarda specificamente l'account del servizio, vedere La replica di disponibilità è disconnessa in un gruppo di disponibilità Always On e Risolvere i problemi relativi alla configurazione dei gruppi di disponibilità Always On.

Raccogliere i dati di diagnostica

Se l'autenticazione ha ancora esito negativo dopo aver completato questi passaggi, raccogliere i dati di diagnostica dall'host SQL Server e da ogni replica interessata per lo stesso intervallo di errore. Per informazioni specifiche su gMSA e sui log standard di SQL Server da raccogliere, vedere Raccogliere dati diagnostici nella panoramica sulla risoluzione dei problemi di gMSA. Usa questi dati per continuare l'analisi o per aprire una richiesta di supporto.

Contenuti correlati

  • Ultimo aggiornamento: