Erreur « etype non pris en charge » lors de l’accès à une ressource dans un domaine approuvé

Article
12/26/2023

Produits concernés : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 4492348

Symptômes

Un ordinateur dans un domaine enfant d’une forêt services de domaine Active Directory (AD DS) ne peut pas accéder à un service qui réside dans un autre domaine au sein de la même forêt. Si vous exécutez une trace réseau sur les communications vers et depuis l’ordinateur client, la trace contient les messages Kerberos suivants :

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}

Sur le contrôleur de domaine du domaine enfant, observateur d'événements enregistre l’entrée Événement 14 suivante :

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.

Cause

Ce problème se produit lorsque vous configurez le domaine enfant (ou simplement le client) comme suit :

Vous désactivez le type de chiffrement RC4_HMAC-MD5, en laissant les types de chiffrement AES128-CTS-HMAC-SHA1-96 et AES256-CTS-HMAC-SHA1-96 activés.
Vous désactivez l’authentification NTLM.

Types de chiffrement Kerberos

Le chiffrement RC4 est considéré comme moins sécurisé que les types de chiffrement plus récents, AES128-CTS-HMAC-SHA1-96 et AES256-CTS-HMAC-SHA1-96. Les guides de sécurité tels que le Guide d’implémentation technique de la sécurité Windows 10 fournissent des instructions pour améliorer la sécurité d’un ordinateur en le configurant pour qu’il utilise uniquement le chiffrement AES128 et/ou AES256 (voir Types de chiffrement Kerberos doivent être configurés pour empêcher l’utilisation des suites de chiffrement DES et RC4).

Un tel client peut continuer à se connecter à des services au sein de son propre domaine qui utilisent le chiffrement AES128 ou AES256. Toutefois, d’autres facteurs peuvent empêcher le client de se connecter à des services similaires dans un autre domaine approuvé, même si ces services utilisent également le chiffrement AES128 ou AES256.

À un niveau très élevé, un contrôleur de domaine (DC) est responsable de la gestion des demandes d’accès au sein de son propre domaine. Dans le cadre du processus d’authentification Kerberos, le contrôleur de domaine vérifie que le client et le service peuvent utiliser le même type de chiffrement Kerberos. Toutefois, lorsqu’un client demande l’accès à un service dans un autre domaine approuvé, le contrôleur de domaine du client doit « référencer » le client à un contrôleur de domaine dans le domaine du service. Lorsque le contrôleur de domaine génère le ticket de référence, au lieu de comparer les types de chiffrement du client et du service, il compare les types de chiffrement du client et de l’approbation.

Le problème se produit en raison de la configuration de l’approbation elle-même. Dans Active Directory, un objet de domaine a des objets de domaine approuvés (DTO) associés qui représentent chaque domaine approuvé. Les attributs d’un TDO décrivent la relation d’approbation, y compris les types de chiffrement Kerberos pris en charge par l’approbation. La relation par défaut entre un domaine enfant et un domaine parent est une approbation transitive bidirectionnelle qui prend en charge le type de chiffrement RC4. Le domaine parent et le domaine enfant ont des objets DTO qui décrivent cette relation, y compris le type de chiffrement.

Lorsque le client contacte le child.contoso.com contrôleur de domaine pour demander l’accès au service, le contrôleur de domaine détermine que le service se trouve dans le domaine contoso.comapprouvé . Le contrôleur de domaine vérifie la configuration de l’approbation pour identifier le type de chiffrement pris en charge par l’approbation. Par défaut, l’approbation prend en charge le chiffrement RC4, mais pas le chiffrement AES128 ou AES256. En revanche, le client ne peut pas utiliser le chiffrement RC4. Le contrôleur de domaine ne peut pas identifier un type de chiffrement commun. Il ne peut donc pas générer le ticket de référence, et la demande échoue.

Authentification NTLM

Après l’échec de l’authentification Kerberos, le client tente de revenir à l’authentification NTLM. Toutefois, si l’authentification NTLM est désactivée, le client n’a pas d’autre alternative. Par conséquent, la tentative de connexion échoue.

Résolution

Pour résoudre ce problème, appliquez l’une des méthodes suivantes :

Méthode 1 : Configurer l’approbation pour prendre en charge le chiffrement AES128 et AES 256 en plus du chiffrement RC4.
Méthode 2 : Configurez le client pour prendre en charge le chiffrement RC4 en plus du chiffrement AES128 et AES256.
Méthode 3 : Configurez l’approbation pour prendre en charge le chiffrement AES128 et AES 256 au lieu du chiffrement RC4.

Le choix dépend de vos besoins de sécurité et de votre besoin de minimiser les interruptions ou de maintenir la compatibilité descendante.

Méthode 1 : Configurer l’approbation pour prendre en charge le chiffrement AES128 et AES 256 en plus du chiffrement RC4

Cette méthode ajoute les types de chiffrement les plus récents à la configuration d’approbation et ne nécessite aucune modification du client ou du service. Dans cette méthode, vous utilisez l’outil ksetup en ligne de commande pour configurer l’approbation.

Pour configurer le type de chiffrement Kerberos d’une approbation, ouvrez une fenêtre d’invite de commandes sur un contrôleur de domaine dans le domaine approuvé, puis entrez la commande suivante :

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

Remarque

Dans cette commande, <trustingdomain> représente le nom de domaine complet (FQDN) du domaine d’approbation.

Dans l’exemple dans lequel contoso.com est le domaine racine (où réside le service) et child.contoso.com le domaine enfant (où réside le client), ouvrez une fenêtre d’invite de commandes sur un contoso.com contrôleur de domaine, puis entrez la commande suivante :

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

Une fois cette commande terminée, le child.contoso.com contrôleur de domaine peut générer correctement le ticket de référence que le client peut utiliser pour atteindre le contrôleur de contoso.com domaine.

Étant donné que la relation entre les deux domaines est une approbation transitive bidirectionnelle, configurez l’autre côté de l’approbation en ouvrant une fenêtre d’invite de commandes sur un child.contoso.com contrôleur de domaine, puis entrez la commande suivante :

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

Une fois cette commande terminée, un contoso.com contrôleur de domaine peut créer des tickets de référence pour tous les clients dans contoso.com qui ne peuvent pas utiliser le chiffrement RC4, mais doivent utiliser des ressources dans child.contoso.com.

Pour plus d’informations sur l’outil ksetup, consultez ksetup.

Méthode 2 : Configurer le client pour prendre en charge le chiffrement RC4 en plus du chiffrement AES128 et AES256

Cette méthode implique la modification de la configuration du client au lieu de l’approbation. Vous pouvez modifier la configuration d’un seul client ou utiliser stratégie de groupe pour modifier la configuration de plusieurs clients dans un domaine. Toutefois, l’inconvénient main de cette modification de configuration est que si vous avez désactivé le chiffrement RC4 afin d’améliorer la sécurité, la restauration de cette modification peut ne pas être possible.

Pour obtenir des instructions complètes sur la modification des types de chiffrement que les clients peuvent utiliser, consultez Configurations Windows pour le type de chiffrement kerberos pris en charge.

Méthode 3 : Configurer l’approbation pour prendre en charge le chiffrement AES128 et AES 256 au lieu du chiffrement RC4

Cette méthode ressemble à la méthode 1 en ce que vous configurez les attributs d’approbation.

Dans le cas des approbations de forêt Windows, les deux côtés de l’approbation prennent en charge AES. Par conséquent, toutes les demandes de ticket sur l’approbation utilisent AES. Toutefois, un client Kerberos tiers qui inspecte le ticket de référence peut vous avertir que le ticket utilise un type de chiffrement que le client ne prend pas en charge. Pour continuer à autoriser un tel client à inspecter le ticket, mettez-le à jour pour prendre en charge AES.

Lorsque vous utilisez cette méthode, configurez l’approbation à l’aide du composant logiciel enfichable MMC Domaines et approbations Active Directory. Pour utiliser cette méthode, procédez comme suit :

Dans Domaines et approbations Active Directory, accédez à l’objet domaine approuvé (dans l’exemple).contoso.com Cliquez avec le bouton droit sur l’objet, sélectionnez Propriétés, puis Sélectionnez Approbations.
Dans la zone Domaines qui approuvent ce domaine (approbations entrantes), sélectionnez le domaine d’approbation (dans l’exemple, child.domain.com).
Sélectionnez Propriétés, Sélectionnez L’autre domaine prend en charge le chiffrement Kerberos AES, puis sélectionnez OK.

Remarque

Pour valider la configuration de l’approbation, sélectionnez Valider dans la boîte de dialogue domaine d’approbation.

Importante

Dans le cas d’une approbation unidirectionnelle, le domaine approuvé répertorie le domaine d’approbation en tant qu’approbation entrante, et le domaine d’approbation répertorie le domaine approuvé comme approbation sortante.

Si la relation est une approbation bidirectionnelle, chaque domaine répertorie l’autre domaine comme approbation entrante et sortante. Dans cette configuration, veillez à case activée la configuration du domaine dans les domaines qui approuvent ce domaine (approbations entrantes) et les domaines approuvés par ce domaine (approbations sortantes). Dans les deux cas, la case à cocher doit être cochée.
Sous l’onglet Approbations , cliquez sur OK.
Accédez à l’objet de domaine pour le domaine d’approbation (child.contoso.com).
Répétez les étapes 1 à 4 pour vous assurer que la configuration d’approbation pour ce domaine reflète la configuration d’approbation pour l’autre domaine (dans ce cas, les listes d’approbations entrantes et sortantes incluent contoso.com).

Plus d’informations

Pour plus d’informations sur les DPO, consultez les articles suivants :

Pour plus d’informations sur les types de chiffrement Kerberos, consultez les articles suivants :

Share via