Errore "Etype non supportato" durante l'accesso a una risorsa in un dominio attendibile

2025-01-15

Numero KB originale: 4492348

Sintomi

Un computer in un dominio figlio di una foresta Dominio di Active Directory Services (AD DS) non può accedere a un servizio che risiede in un dominio diverso all'interno della stessa foresta. Se si esegue una traccia di rete sulle comunicazioni da e verso il computer client, la traccia contiene i messaggi Kerberos seguenti:

6 9:35:19 AM 8/14/2018   17.8417442   192.168.1.101   192.168.1.2  KerberosV5   KerberosV5:AS Request Cname: Administrator Realm: contoso.com Sname: krbtgt/contoso.com   {TCP:4, IPv4:1}  
  
7 9:35:19 AM 8/14/2018   17.8452544   192.168.1.2   192.168.1.101  KerberosV5   KerberosV5:KRB_ERROR - KDC_ERR_ETYPE_NOSUPP (14)  {TCP:4, IPv4:1}

Nel controller di dominio del dominio figlio Visualizzatore eventi registra la voce evento 14 seguente:

Log Name: System  
Source: Microsoft-Windows-Kerberos-Key-Distribution-Center  
Event ID: 14  
Task Category: None  
Level: Error  
Keywords: Classic  
Description:  
While processing an AS request for target service krbtgt, the account Administrator did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 17 3. The accounts available etypes : 23 -133 -128. Changing or resetting the password of Administrator will generate a proper key.

Causa

Questo problema si verifica quando si configura il dominio figlio (o solo il client) come indicato di seguito:

Si disabilita il tipo di crittografia RC4_HMAC-MD5, lasciando abilitati i tipi di crittografia AES128-CTS-HMAC-SHA1-96 e AES256-CTS-HMAC-SHA1-96.
Si disabilita l'autenticazione NTLM.

Tipi di crittografia Kerberos

La crittografia RC4 è considerata meno sicura dei tipi di crittografia più recenti, AES128-CTS-HMAC-SHA1-96 e AES256-CTS-HMAC-SHA1-96. Le guide alla sicurezza, ad esempio la Guida all'implementazione tecnica della sicurezza di Windows 10, forniscono istruzioni per migliorare la sicurezza di un computer configurandola in modo da usare solo la crittografia AES128 e/o AES256 (vedere I tipi di crittografia Kerberos devono essere configurati per impedire l'uso di suite di crittografia DES e RC4).

Un client di questo tipo può continuare a connettersi ai servizi all'interno del proprio dominio che usano la crittografia AES128 o AES256. Tuttavia, altri fattori possono impedire al client di connettersi a servizi simili in un altro dominio attendibile, anche se tali servizi usano anche la crittografia AES128 o AES256.

A un livello molto elevato, un controller di dominio è responsabile della gestione delle richieste di accesso all'interno del proprio dominio. Come parte del processo di autenticazione Kerberos, il controller di dominio verifica che sia il client che il servizio possano usare lo stesso tipo di crittografia Kerberos. Tuttavia, quando un client richiede l'accesso a un servizio in un dominio attendibile diverso, il controller di dominio del client deve "fare riferimento" al client a un controller di dominio nel dominio del servizio. Quando il controller di dominio compila il ticket di riferimento, anziché confrontare i tipi di crittografia del client e del servizio, confronta i tipi di crittografia del client e l'attendibilità.

Il problema si verifica a causa della configurazione dell'attendibilità stessa. In Active Directory un oggetto dominio ha associato oggetti di dominio attendibili (TDO) che rappresentano ogni dominio considerato attendibile. Gli attributi di un TDO descrivono la relazione di trust, inclusi i tipi di crittografia Kerberos supportati dal trust. La relazione predefinita tra un dominio figlio e un dominio padre è un trust transitivo bidirezionale che supporta il tipo di crittografia RC4. Sia il dominio padre che il dominio figlio hanno TDO che descrivono questa relazione, incluso il tipo di crittografia.

Quando il client contatta il child.contoso.com controller di dominio per richiedere l'accesso al servizio, il controller di dominio determina che il servizio si trova nel dominio contoso.comattendibile. Il controller di dominio controlla la configurazione di attendibilità per identificare il tipo di crittografia supportato dal trust. Per impostazione predefinita, il trust supporta la crittografia RC4, ma non la crittografia AES128 o AES256. D'altra parte, il client non può usare la crittografia RC4. Il controller di dominio non è in grado di identificare un tipo di crittografia comune, quindi non può compilare il ticket di riferimento e la richiesta ha esito negativo.

Autenticazione NTLM

Dopo che l'autenticazione Kerberos ha esito negativo, il client tenta di eseguire il fallback all'autenticazione NTLM. Tuttavia, se l'autenticazione NTLM è disabilitata, il client non ha altre alternative. Di conseguenza, il tentativo di connessione non riesce.

Risoluzione

Per risolvere il problema, utilizzare uno dei metodi riportati di seguito:

Metodo 1: configurare l'attendibilità per supportare la crittografia AES128 e AES 256 oltre alla crittografia RC4.
Metodo 2: configurare il client per supportare la crittografia RC4 oltre alla crittografia AES128 e AES256.
Metodo 3: configurare l'attendibilità per supportare la crittografia AES128 e AES 256 anziché la crittografia RC4.

La scelta dipende dalle esigenze di sicurezza e dalla necessità di ridurre al minimo le interruzioni o mantenere la compatibilità con le versioni precedenti.

Metodo 1: Configurare l'attendibilità per supportare la crittografia AES128 e AES 256 oltre alla crittografia RC4

Questo metodo aggiunge i tipi di crittografia più recenti alla configurazione trust e non richiede alcuna modifica al client o al servizio. In questo metodo si usa lo strumento da ksetup riga di comando per configurare l'attendibilità.

Per configurare il tipo di crittografia Kerberos di un trust, aprire una finestra del prompt dei comandi in un controller di dominio nel dominio attendibile e quindi immettere il comando seguente:

ksetup /setenctypeattr <trustingdomain> RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96

Note

In questo comando, <trustingdomain> rappresenta il nome di dominio completo (FQDN) del dominio attendibile.

Nell'esempio in cui contoso.com è il dominio radice (dove risiede il servizio) e child.contoso.com è il dominio figlio (dove risiede il client), aprire una finestra del prompt dei comandi in un contoso.com controller di dominio e quindi immettere il comando seguente:

ksetup /setenctypeattr child.contoso.com RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96

Al termine di questo comando, il child.contoso.com controller di dominio può compilare correttamente il ticket di riferimento che il client può usare per raggiungere il contoso.com controller di dominio.

Poiché la relazione tra i due domini è un trust transitivo bidirezionale, configurare l'altro lato dell'attendibilità aprendo una finestra del prompt dei comandi in un child.contoso.com controller di dominio e quindi immettere il comando seguente:

ksetup /setenctypeattr contoso.com RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96

Al termine di questo comando, un contoso.com controller di dominio può compilare ticket di riferimento per tutti i client in contoso.com che non possono usare la crittografia RC4, ma devono usare le risorse in child.contoso.com.

Per altre informazioni sullo strumento ksetup, vedere ksetup.

Metodo 2: Configurare il client per supportare la crittografia RC4 oltre alla crittografia AES128 e AES256

Questo metodo comporta la modifica della configurazione del client anziché dell'attendibilità. È possibile modificare la configurazione di un singolo client o usare Criteri di gruppo per modificare la configurazione di più client in un dominio. Tuttavia, lo svantaggio principale di questa modifica di configurazione è che se la crittografia RC4 è stata disabilitata per migliorare la sicurezza, il rollback di tale modifica potrebbe non essere possibile.

Per istruzioni complete per modificare i tipi di crittografia che i client possono usare, vedere Configurazioni di Windows per il tipo di crittografia supportato da Kerberos.

Metodo 3: Configurare l'attendibilità per supportare la crittografia AES128 e AES 256 anziché la crittografia RC4

Questo metodo è simile al metodo 1 in cui si configurano gli attributi di attendibilità.

Nel caso di trust tra foreste di Windows, entrambi i lati del trust supportano AES. Pertanto, tutte le richieste di ticket nell'attendibilità usano AES. Tuttavia, un client Kerberos di terze parti che controlla il ticket di segnalazione potrebbe notificare all'utente che il ticket usa un tipo di crittografia che il client non supporta. Per continuare a consentire a tale client di controllare il ticket, aggiornarlo per supportare AES.

Quando si usa questo metodo, configurare l'attendibilità usando lo snap-in MMC Dominio di Active Directory e Trusts. Per usare questo metodo, seguire questa procedura:

In Dominio di Active Directory e trust passare all'oggetto dominio attendibile (nell'esempio).contoso.com Fare clic con il pulsante destro del mouse sull'oggetto, scegliere Proprietà e quindi trust.
Nella casella Domini che considerano attendibile il dominio (trust in ingresso) selezionare il dominio trusting (nell'esempio ). child.domain.com
Selezionare Proprietà, selezionare L'altro dominio supporta la crittografia Kerberos AES e quindi selezionare OK.

Note

Per convalidare la configurazione dell'attendibilità, selezionare Convalida nella finestra di dialogo Dominio attendibile.

Importante

Nel caso di un trust unidirezionale, il dominio attendibile elenca il dominio attendibile come trusting trust e il dominio trusting elenca il dominio attendibile come trust in uscita.

Se la relazione è un trust bidirezionale, ogni dominio elenca l'altro dominio come trust in ingresso e in uscita. In questa configurazione assicurarsi di controllare la configurazione del dominio in entrambi i domini che considerano attendibile il dominio (trust in ingresso) e i domini attendibili da questo dominio (trust in uscita). In entrambi i casi, la casella di controllo deve essere selezionata.
Nella scheda Attendibilità fare clic su OK.
Passare all'oggetto dominio per il dominio attendibile (child.contoso.com).
Ripetere i passaggi da 1 a 4 per assicurarsi che la configurazione dell'attendibilità per questo dominio rispecchi la configurazione di attendibilità per l'altro dominio (in questo caso, gli elenchi di attendibilità in ingresso e in uscita includono contoso.com).

Ulteriori informazioni

Per altre informazioni sui TDO, vedere gli articoli seguenti:

Per altre informazioni sui tipi di crittografia Kerberos, vedere gli articoli seguenti:

Condividi tramite