Condividi tramite

Linee guida per la risoluzione dei problemi di autenticazione Kerberos

Questa guida fornisce i concetti fondamentali da seguire quando si risolvono i problemi di autenticazione Kerberos.

Importante

Questo articolo fornisce indicazioni generali. Potrebbe essere necessario adattare le procedure e gli esempi presentati qui per lavorare per la configurazione specifica.

Elenco di controllo per la risoluzione dei problemi

Il protocollo Kerberos si basa su diversi componenti e servizi dell'infrastruttura. Se uno di questi componenti o servizi non è disponibile o non funziona, è possibile che si verifichino problemi di autenticazione.

1. Controllare eventi e log

Controllare i registri eventi per individuare le indicazioni di un problema. Usare il Visualizzatore eventi per esaminare i log di sicurezza e di sistema nei sistemi coinvolti nell'operazione di autenticazione:

  • Client di autenticazione
  • Server o servizio di destinazione
  • Controller di dominio

In particolare, cercare gli eventi provenienti da origini che potrebbero essere correlati all'autenticazione Kerberos o ai servizi su cui si basa, ad esempio le origini seguenti:

  • Kerberos
  • Centro di distribuzione delle chiavi (KDC)
  • LSA (LsaSrv)
  • Accesso rete

Nel server di destinazione, controllare il log di sicurezza per le registrazioni di errore. Tali errori potrebbero indicare che il protocollo Kerberos viene usato quando si verifica un errore di autenticazione.

Alcuni eventi o errori indicano problemi specifici. Se uno dei computer interessati ha registrato uno degli eventi o degli errori seguenti, selezionare il collegamento per informazioni più dettagliate sulla risoluzione dei problemi.

Evento o errore Informazioni sulla risoluzione dei problemi
ID evento 4, errore KERB_AP_ERR_MODIFIED Il client non è riuscito a decrittografare il ticket di servizio. Poiché più di un problema può causare questo errore, verificare la presenza di eventi correlati. Ad esempio, questa stringa potrebbe indicare che gli orologi del client e del server di destinazione non sono sincronizzati o che il nome SPN non è univoco. In un ambiente multidominio, il nome dell'account del servizio potrebbe non essere univoco nella foresta (o in altre foreste attendibili).
Per ulteriori informazioni, vedere Il client Kerberos ha ricevuto un errore KRB_AP_ERR_MODIFIED dal server e Kerberos genera un errore KDC_ERR_S_PRINCIPAL_UNKNOWN o KDC_ERR_PRINCIPAL_NOT_UNIQUE.
ID evento 4, errore KERB_AP_ERR_SKEW Assicurarsi che gli orologi del computer siano sincronizzati
ID evento 14 Errore "Etype non supportato" durante l'accesso a una risorsa in un dominio attendibile
ID evento 16 o ID evento 27 L'ID evento KDC 16 o 27 viene registrato se DES per Kerberos è disabilitato
Errori KDC per l'ID evento 27 sui controller di dominio di Windows Server 2003
Errore 1069 Gli accessi ai servizi falliscono a causa di SPN impostati in modo errato
ID evento 5719, errore 1311 o errore 1355 ID evento 5719, Errore 1311 o Errore 1355 - Controller di dominio o dominio non trovato

Se verifichi un problema che sai come risolvere, risolvilo prima di tutto e quindi riprova ad autenticarti prima di continuare.

2. Controllare l'infrastruttura

a) Assicurarsi che l'app client e il servizio di destinazione non siano nello stesso computer

Per impostazione predefinita, se l'app client e il servizio di destinazione vengono installati in un singolo computer, Kerberos è disabilitato. Se non è possibile installare l'applicazione client e il servizio di destinazione in computer separati, è necessario modificare impostazioni specifiche relative alla sicurezza in Windows. Inoltre, potrebbe essere necessario modificare una chiave del Registro di sistema. Per altre informazioni sui problemi correlati a questo scenario e sulle impostazioni specifiche che lo interessano, vedere Messaggio di errore quando si tenta di accedere a un server in locale.

Se sono state apportate modifiche, riprovare a eseguire l'autenticazione prima di continuare.

b. Verificare che il computer client, il server di destinazione e i server di risorse siano aggiunti ai domini appropriati

Se necessario, aggiungere il computer client o il server di destinazione a un dominio appropriato. Riprovare quindi a eseguire l'autenticazione.

Annotazioni

In questo contesto, i "domini appropriati" sono domini all'interno di una singola foresta o all'interno di un set di foreste con relazioni di trust.

c. Controllare l'integrità del server di destinazione e dei relativi servizi di supporto

Assicurarsi che i servizi front-end o dell'applicazione (ad esempio i servizi Web) e i servizi back-end (ad esempio il servizio SQL Server) siano in esecuzione.

Annotazioni

È possibile che venga visualizzato un messaggio simile a "Un servizio ha generato l'errore 1069: il servizio non è stato avviato a causa di un errore di accesso". Se viene visualizzato questo messaggio, vedere Errore degli accessi al servizio a causa dell'impostazione non corretta dei nomi SPN.

d. Assicurarsi che le porte corrette siano disponibili

Controllare tutti i firewall (inclusi Windows Firewall in ogni computer) tra il computer client, il controller di dominio e il server di destinazione. Assicurarsi che il traffico sia consentito sulle porte seguenti.

Annotazioni

Questo elenco usa il formato server:porta client,porta server.

  • DHCP: 67 (UDP), 67 (UDP)
  • DNS: 49152 -65535 (TCP, UDP), 53 (TCP, UDP)
  • HTTPS, inclusa l'autenticazione basata su certificati: 443 (TCP), 443 (TCP)
  • Kerberos: 49152 -65535 (TCP, UDP), 88 (TCP, UDP)
  • Modifica della password Kerberos: 49152 -65535 (TCP), 464 (TCP, UDP)
  • LDAP, incluso il localizzatore DC: 49152 -65535 (TCP, UDP), 389 (TCP, UDP)
  • LDAP SSL: 49152 -65535 (TCP), 636 (TCP)
  • SMB: 49152 -65535 (TCP, UDP), 445 (TCP)
  • Mappatore degli endpoint RPC: 49152 -65535 (TCP), 135 (TCP)
  • RPC per LSA, SAM, NetLogon: 49152 -65535 (TCP), 49152-65535 (TCP)
  • W32Time: 49152 -65535 (UDP), 123 (UDP)

Se si apportano modifiche a qualsiasi impostazione del firewall, riprovare a eseguire l'autenticazione.

e. Verificare che i controller di dominio siano disponibili

Quando il client tenta di contattare un servizio o un'applicazione (detto "server di destinazione"), sia il client che il server di destinazione richiedono un controller di dominio per facilitare l'autenticazione, l'autorizzazione e la delega.

Sul computer client, aprire una finestra del prompt dei comandi con privilegi elevati e quindi eseguire il comando seguente:

nltest /dsgetdc:<DomainName> /force /kdc

Annotazioni

In questo comando <DomainName> rappresenta il nome del dominio del computer da cui si sta eseguendo una query.

Il nltest comando recupera un elenco di controller di dominio disponibili (anche se l'elenco potrebbe non includere tutti i controller di dominio disponibili). Registrare i nomi di dominio completi e gli indirizzi IP di questi controller di dominio da usare nelle procedure successive.

Se il client o il server di destinazione non riesce a contattare un controller di dominio, viene visualizzato un messaggio simile al seguente (a volte etichettato "errore 1355"):

il dominio specificato non esiste o non è stato possibile contattarlo.

Se viene visualizzato questo messaggio, vedere ID evento 5719, Errore 1311 o Errore 1355 - Controller di dominio o dominio non trovato per altre informazioni sulla risoluzione dei problemi. In caso contrario, continuare con questo elenco di controllo.

f. Verificare che il DNS funzioni tra il client e il server di destinazione

Nel computer client, aprire una finestra del prompt dei comandi amministrativo e quindi eseguire il comando seguente:

nslookup <TargetName>

Annotazioni

In questo comando <TargetName> rappresenta il nome NetBIOS del server di destinazione.

Se il nslookup comando risolve correttamente il nome del server di destinazione, la configurazione DNS è corretta. Se il comando non risolve il nome del server di destinazione, seguire questa procedura per controllare la configurazione della scheda di rete del computer client:

  1. Nel computer client eseguire il comando seguente:

    ipconfig /all

  2. Nell'output del comando, determina quale scheda di rete è in uso. Controllare le impostazioni dell'adattatore seguenti:

    • Indirizzo IP del client

    • Maschera di sottorete

    • Gateway predefinito

    • Suffisso DNS specifico della connessione

    • Indirizzi IP del server DNS

      Registrare gli indirizzi IP e notare quale server DNS è preferibile e quale è secondario. Queste informazioni sono utili per la risoluzione dei problemi successivi.

    Se una di queste impostazioni non è corretta, correggerle o contattare l'amministratore DNS per assistenza. Se sono state apportate modifiche, eseguire nslookup <TargetName> di nuovo.

Se DNS non funziona ancora correttamente, seguire questa procedura:

  1. Eseguire il comando seguente nel computer client:

    nslookup <ClientName> <DNSIPAddress>

    Annotazioni

    In questo comando ClientName <> rappresenta il nome NetBIOS del computer client e <DNSIPAddress> rappresenta l'indirizzo IP di uno dei server DNS che il client è configurato per l'uso. Usare prima di tutto l'indirizzo IP del server DNS preferito registrato nella procedura precedente. Se il comando non funziona, riprovare usando l'indirizzo IP del server DNS secondario del client.

    Ad esempio, se il nome del computer client è "client1" e l'indirizzo IP del server DNS preferito del client è 10.0.0.1, eseguire il comando seguente:

    nslookup client1 10.0.0.1

  2. Eseguire lo stesso comando dal server di destinazione. Ora è simile al comando seguente:

    nslookup <TargetName> <DNSIPAddress>

    Annotazioni

    In questo comando <TargetName> rappresenta il nome NetBIOS del server di destinazione e <DNSIPAddress> rappresenta l'indirizzo IP di uno dei server DNS che il server di destinazione è configurato per l'uso. Usare prima di tutto l'indirizzo IP del server DNS preferito registrato nella procedura precedente. Se il comando non funziona la prima volta che viene eseguito, riprovare a usare l'indirizzo IP del server DNS secondario del server di destinazione.

    Ad esempio, se il nome del server di destinazione è "WebServer1" e l'indirizzo IP del server DNS preferito del server di destinazione è 10.0.0.1, eseguire il comando seguente:

    nslookup WebServer1 10.0.0.1

    La tabella seguente riepiloga i possibili risultati delle nslookup query e le relative implicazioni.

    Query di destinazione
    Ha successo    		 Query di destinazione
    fallisce
    Richiesta cliente
    Riesce    		 Nessun problema DNS Problema che interessa la destinazione o almeno un server DNS
    Richiesta cliente
    Fallisce    		 Problema che interessa il client o almeno un server DNS Problema che interessa uno o più server DNS

Se i risultati della query indicano che si è verificato un problema DNS, vedere gli articoli seguenti per altre informazioni:

Se si risolve il problema DNS ma il problema Kerberos rimane, provare i metodi di risoluzione dei problemi seguenti.

g. Assicurarsi che gli orologi del computer siano sincronizzati

Il computer client o il server di destinazione può memorizzare nella cache i ticket per un uso futuro. Tuttavia, ogni ticket ha dei timestamp che ne determinano il tempo di durata (TTL). Il servizio Centro distribuzione chiavi Kerberos, che viene eseguito nei controller di dominio, imposta i timestamp.

La differenza di tempo tra il controller di dominio e il computer client o il server di destinazione deve essere inferiore a cinque minuti. In genere, se gli orologi non sono sincronizzati, Windows può risincronizzarli automaticamente. Esistono due casi in cui potrebbe essere necessario intervenire:

  • Gli orologi non sono sincronizzati da più di 48 ore.
  • L'orologio non sincronizzato non usa un controller di dominio nel proprio dominio come server di ora o non usa lo stesso server di tempo di tali controller di dominio.

Per risolvere questo problema, il computer interessato deve ricontrollare la rete per i server ora e quindi risincronizzare il proprio orologio. Per abilitare queste azioni, aprire una finestra del prompt dei comandi amministrativa e quindi eseguire il comando seguente:

w32tm /resync /computer:<Target> /rediscover

Annotazioni

In questo comando Target <> rappresenta il computer che si sta configurando. L'opzione /rediscover indica al computer di controllare la presenza di origini temporali nuove o aggiornate nella rete.

Per altre informazioni sulle opzioni disponibili per il w32tm comando, vedere Impostazioni e strumenti del servizio Ora di Windows: Parametri della riga di comando per W32Time.

Se si risincronizzano gli orologi, riprovare a eseguire l'autenticazione.

h. Controllare lo stato di Windows Update

Assicurarsi che tutti i controller di dominio, il computer client e il server di destinazione abbiano tutti gli aggiornamenti di Windows pertinenti.

Se sono stati installati aggiornamenti, riavviare i computer interessati e riprovare a eseguire l'autenticazione.

uno Controllare lo stato dell'aggiornamento dell'applicazione

Assicurarsi che le applicazioni client e server siano aggiornate nel computer client e nel server di destinazione. Se si installano aggiornamenti, riavviare i computer interessati e riprovare a eseguire l'autenticazione.

j. Riavviare i computer

Se non è già stato riavviato il computer client, il server di destinazione o il controller di dominio, riavviarli ora. Dopo il riavvio dei computer, riprovare a eseguire l'autenticazione.

Se l'infrastruttura è ok e si è ancora verificato un problema, continuare con le procedure di risoluzione dei problemi più avanzate.

3. Raccogliere dati di traccia e ticket

Le procedure seguenti usano lo strumento Monitoraggio di rete gratuito. Scaricare e installare lo strumento sia nel computer client che nel server di destinazione. Per un esempio di come usare Monitoraggio di rete per raccogliere dati di traccia e identificare i messaggi Kerberos, vedere Errori Kerberos nelle acquisizioni di rete.

a) Raccogliere tracce di rete simultanee

Nel computer client seguire questa procedura:

  1. Eseguire una delle operazioni seguenti:

    • Riavviare il computer client.
    • Disconnetti dall'account che stai usando per la risoluzione dei problemi e accedi nuovamente.
    • Chiudere l'applicazione client e riaprirla.

  2. Avvia la traccia. Per fare questo, segui questi passaggi:

    1. Selezionare Start e quindi digitare netmon.
    2. Nei risultati della ricerca fare clic con il pulsante destro del mouse su Microsoft Network Monitor 3.4 e quindi scegliere Esegui come amministratore (selezionare Sì nella finestra Controllo account utente).
    3. In Monitoraggio rete selezionare Avvia.

  3. Aprire una finestra del prompt dei comandi amministrativa e quindi eseguire i comandi seguenti, in sequenza:

    ipconfig /flushdns
nbtstat -RR
klist purge
klist -li 0x3e7 purge

Nel server di destinazione seguire questa procedura:

  1. Aprire Monitoraggio di rete come amministratore e quindi selezionare Avvia.

  2. Aprire una finestra del prompt dei comandi amministrativa e quindi eseguire i comandi seguenti, in sequenza:

    ipconfig /flushdns
nbtstat -RR
klist purge
klist -li 0x3e7 purge

Provare a riprodurre il problema e quindi arrestare e salvare le tracce sia nel computer client che nel server di destinazione. A tale scopo, in Monitoraggio di rete selezionare Arresta e quindi Salva con nome.

b. Registrare le informazioni sui ticket

Dopo aver riprodotto il problema e interrotto la traccia, controllare i ticket Kerberos generati durante la registrazione dei dati di traccia. Al prompt dei comandi nel computer client e nel server di destinazione eseguire il comando seguente:

klist tickets

Questo comando genera un elenco di ticket. È possibile copiare queste informazioni in un'altra applicazione, ad esempio Blocco note, in modo da poterle usare nelle procedure di risoluzione dei problemi successive.

4. Controllare i dati di traccia per i messaggi Kerberos

È possibile usare Monitoraggio di rete per esaminare, filtrare e cercare i dati nei file di acquisizione. In particolare, cercare gli eventi etichettati usando "KerberosV5". Questi eventi forniscono informazioni sullo stato. Possono anche elencare i nomi o gli indirizzi IP dei controller di dominio contattati e il nome del servizio principale (SPN) del servizio che il client ha tentato di raggiungere.

Le descrizioni degli eventi che contengono stringhe simili alle seguenti fanno parte di funzioni Kerberos tipiche:

  • KerberosV5:KRB_Error -KDC_ERR_PREAUTH_REQUIRED
  • Richiesta KerberosV5:AS
  • Risposta KerberosV5:AS
  • Richiesta KerberosV5:TGS
  • Risposta KerberosV5:TGS
  • KerberosV5:Richiesta AP
  • Risposta KerberosV5:AP

Annotazioni

È anche possibile usare Monitoraggio di rete per controllare i dati di traccia per le informazioni sui ticket nelle richieste HTTP GET. Se le informazioni sul ticket non sono presenti nella richiesta GET, si è verificato un problema nell'uso dell'autenticazione Kerberos.

Le descrizioni degli eventi che contengono stringhe simili al seguente indicano che si è verificato un problema. L'elenco seguente include alcuni degli errori più comuni. Se vedi una di queste stringhe, prendi nota di nomi di server, indirizzi IP e SPN per un uso successivo.

  • KDC_ERR_PRINCIPAL_NOT_UNIQUE o KDC_ERR_S_PRINCIPAL_UNKNOWN. Il nome SPN richiesto è associato a più account o non è associato ad alcun account. Per informazioni sulla risoluzione di uno di questi problemi, vedere Kerberos genera l'errore KDC_ERR_S_PRINCIPAL_UNKNOWN o l'errore KDC_ERR_PRINCIPAL_NOT_UNIQUE.

  • KRB_AP_ERR_MODIFIED. Il client non è riuscito a decrittografare il ticket di servizio. Più di un problema può causare questo errore. Esamina i dati di tracciamento per individuare altri errori che accompagnano KRB_AP_ERR_MODIFIED. Controllare i registri eventi per l'ID evento 4 e altri eventi correlati, come descritto in 1. Controllare eventi e log.

  • ERB_AP_ERR_SKEW. Gli orologi del client e del server di destinazione non sono sincronizzati. Per altre informazioni, vedere Verificare che gli orologi del computer siano sincronizzati.

  • KDC_ERR_ETYPE_NOTSUPP. Uno o più componenti coinvolti nell'autenticazione usano un tipo di crittografia disabilitato per altri componenti. Controllare i registri eventi per altre informazioni sui componenti e sui tipi di crittografia coinvolti, come descritto in 1. Controllare eventi e log.

Problemi noti e soluzioni

HTTP 400 - Richiesta non valida (intestazione della richiesta troppo lunga)

Se un utente appartiene a un numero elevato di gruppi (ad esempio, più di 1.000 gruppi), Kerberos potrebbe negare l'accesso utente perché non elabora correttamente la richiesta. Per altre informazioni su questo problema, vedere gli articoli seguenti:

Problemi relativi al servizio

I problemi del servizio di solito coinvolgono l'SPN e l'account del servizio. Ad esempio, il nome SPN potrebbe non essere corretto, mancante, configurato nell'account non corretto o configurato in più account. L'elenco di controllo per la risoluzione dei problemi in questo articolo a. Raccogliere tracce di rete simultanee è riportato in precedenza in questo articolo. Se hai già identificato un problema comune relativo al nome SPN, consulta i seguenti articoli:

Problemi di Single Sign-On (SSO)

Single Sign-On è un metodo di autenticazione che consente agli utenti di accedere usando un set di credenziali a più sistemi o applicazioni all'interno di una singola intranet. Per funzionare correttamente, sia il servizio di destinazione (o il componente front-end del servizio di destinazione) che il client deve avere le impostazioni corrette. Per informazioni su come risolvere questi problemi, vedere Risoluzione dei problemi relativi all'accesso Single Sign-On Kerberos.

Problemi di delega

Quando il servizio di destinazione include componenti front-end e back-end separati, Kerberos può delegare le credenziali client (incluse le autorizzazioni di accesso) a un account del servizio. In termini semplici, il client accede al servizio front-end e quindi il servizio front-end accede al servizio back-end per conto del client.

Kerberos supporta tre tipi di delega:

  • Delega non vincolata. Dopo che il client accede al servizio front-end, il servizio front-end può accedere a qualsiasi altro servizio per conto del client. Questa configurazione è la più semplice da implementare, ma è anche la meno sicura. Non consigliamo la delega non vincolata perché non limita i servizi con cui l'account autenticato può interagire.
  • Delega vincolata. Il servizio front-end gestisce un elenco di servizi a cui può accedere per conto di un client.
  • Delega vincolata basata sulle risorse (RBCD). Il servizio back-end gestisce una lista di autorizzazione di servizi front-end che possono richiedere l'accesso al servizio back-end per conto di un cliente.

Annotazioni

Se si verifica un problema quando si usa la delega vincolata insieme a CIFS, vedere La delega vincolata per CIFS non riesce con l'errore ACCESS_DENIED.

Importante

  • Non configurare la delega vincolata e il Controllo Basato sui Ruoli (RBCD) sullo stesso gruppo di server front-end e back-end.

    La delega vincolata e RBCD sono configurazioni diverse e si escludono a vicenda. Quando un servizio front-end richiede un ticket a un servizio back-end, il KDC controlla innanzitutto il servizio front-end per verificare la delega vincolata. Se la delega vincolata non è configurata per il servizio front-end, il KDC controlla il servizio back-end per la delega vincolata basata sulle risorse. A causa di questa sequenza, la delega vincolata ha la precedenza sulla delega basata sulle risorse.

  • Per impostazione predefinita, Microsoft Edge non supporta la delega senza vincoli. Se usi la delega Kerberos a doppio hop senza vincoli, vedere Autenticazione a doppio hop Kerberos senza vincoli con Microsoft Edge (Chromium) per ulteriori informazioni sulla configurazione necessaria.

  • La delega non vincolata non è consigliata perché non limita i servizi con cui l'account autenticato può interagire.

Tipi di topologia supportati

I diversi tipi di delega pongono requisiti diversi nella topologia. Nella tabella seguente sono elencati tre tipi comuni di topologia e quali tipi di delega (se presenti) sono supportati per ogni tipo.

Tipo di topologia Delega non vincolata Delega vincolata RBCD
Tutti i servizi risiedono in un singolo dominio Supportato (non consigliato) Sostenuto Sostenuto
I servizi front-end e back-end si trovano in domini diversi Supportato (non consigliato) Non supportato Sostenuto
I servizi front-end e back-end si trovano in foreste diverse (attendibili) Supportato* (non consigliato) Non supportato Sostenuto*

* Assicurarsi che l'account del servizio front-end possa autenticarsi attraverso la relazione di attendibilità con il controller di dominio attendibile.

Risoluzione dei problemi relativi a tipi di delega specifici

I dettagli di configurazione per la delega variano a seconda del tipo di delega in uso e del tipo di account usato dal servizio front-end. Per risolvere ulteriormente i problemi di delega, vedere gli articoli seguenti, in base alle esigenze:

Uso di uno scenario di test di analisi dei log per risolvere i problemi di autenticazione Kerberos

Per i test e la risoluzione dei problemi avanzati di Kerberos, vedere Usare uno scenario di test di analisi dei log per risolvere i problemi di autenticazione Kerberos.

  • Last updated on