Partager via


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

Numéro de 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, l’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 utiliser uniquement le chiffrement AES128 et/ou AES256 (consultez les 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 « faire référence » au 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 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 associé des objets de domaine approuvés qui représentent chaque domaine qu’il approuve. 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 parent et le domaine enfant ont des objets TDO 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 d’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, de sorte qu’il ne peut pas générer le ticket de référence et la demande échoue.

Authentification NTLM

Une fois l’authentification Kerberos défaillante, le client tente de revenir à l’authentification NTLM. Toutefois, si l’authentification NTLM est désactivée, le client n’a aucune autre alternative. Par conséquent, la tentative de connexion échoue.

Résolution

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

  • Méthode 1 : Configurez 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 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

Note

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

Dans l’exemple dans lequel contoso.com se trouve 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 avec succès le ticket de référence que le client peut utiliser pour atteindre le contoso.com contrôleur de 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 générer des tickets de référence pour tous les clients qui contoso.com 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 de modifier la configuration du client au lieu de l’approbation. Vous pouvez modifier la configuration d’un seul client ou utiliser la stratégie de groupe pour modifier la configuration de plusieurs clients dans un domaine. Toutefois, le principal inconvénient 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 pour modifier les types de chiffrement que les clients peuvent utiliser, consultez Configurations Windows pour le type de chiffrement pris en charge par Kerberos.

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 dans laquelle 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 domaine Active Directory s et approbations. Pour utiliser cette méthode, procédez comme suit :

  1. Dans domaine Active Directory s et approbations, accédez à l’objet de domaine approuvé (dans l’exemple,contoso.com). Cliquez avec le bouton droit sur l’objet, sélectionnez Propriétés, puis sélectionnez Approbations.

  2. Dans la zone Domaines qui approuvent ce domaine (approbations entrantes), sélectionnez le domaine d’approbation (dans l’exemple). child.domain.com

  3. Sélectionnez Propriétés, sélectionnez L’autre domaine prend en charge le chiffrement Kerberos AES, puis sélectionnez OK.

    Capture d’écran des propriétés d’un domaine enfant et du Fenêtre Propriétés inclut la case à cocher Kerberos AES Encryption.

    Note

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

    Important

    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 en tant qu’approbation entrante et sortante. Dans cette configuration, veillez à vérifier la configuration du domaine dans les deux 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.

  4. Sous l’onglet Approbations , cliquez sur OK.

  5. Accédez à l’objet de domaine pour le domaine d’approbation (child.contoso.com).

  6. 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’approbation entrantes et sortantes incluent contoso.com).

Plus d’informations

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

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