Détecter et corriger l’utilisation de RC4 dans Kerberos

S’applique à: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Windows 11, ✅ Windows 10

L’authentification Kerberos dans les environnements Active Directory (AD) repose historiquement sur l’algorithme de chiffrement RC4. RC4 est un chiffrement de flux utile en raison de sa compatibilité avec les systèmes hérités. Toutefois, RC4 est maintenant considéré comme non sécurisé et est en cours d’élimination progressive.

Cet article explique comment détecter l’utilisation de RC4 dans votre domaine, auditer les comptes d’appareil et d’utilisateur qui dépendent toujours de RC4 et prendre des mesures pour corriger l’utilisation en faveur de types de chiffrement plus forts ou gérer les dépendances RC4. Utilisez ces instructions pour préparer votre environnement aux modifications à venir apportées aux paramètres Kerberos par défaut et améliorer la posture de sécurité de votre organisation.

À un niveau élevé, les administrateurs informatiques doivent prendre les mesures suivantes pour préparer les modifications par défaut à la prise en charge Kerberos pour RC4 :

Auditer l’utilisation actuelle de RC4 : utilisez les outils d’audit et les journaux des événements décrits dans cet article pour identifier les comptes, les services ou les appareils qui utilisent toujours RC4.
Traitez les anciens appareils : migrez ou remplacez des appareils non pris en charge, en particulier ceux qui exécutent Windows Server 2003 ou version antérieure, car ils ne supportent pas AES-SHA1.
Désactivez RC4 : le cas échéant, désactivez explicitement RC4.

Utilisation de RC4 dans Windows et ses risques

RC4 est généralement utilisé dans des environnements Windows lorsque les comptes ou les appareils ne prennent pas en charge des types de chiffrement plus forts tels qu'AES-SHA1. L’utilisation de RC4 peut se produire avec des systèmes hérités, des comptes créés avant l’introduction de la prise en charge d'AES-SHA1, ou lorsque les paramètres de chiffrement ne sont pas configurés explicitement. RC4 était le type de chiffrement par défaut, ce qui en fait un choix commun pour la compatibilité avec l’ancienne infrastructure. Toutefois, la dépendance à RC4 expose les environnements aux risques de sécurité, et son utilisation est activement supprimée en faveur d’algorithmes plus sécurisés.

En réponse à CVE-2022-37966, les mises à jour Windows publiées le 8 novembre 2022 ou après ont modifié le type de chiffrement par défaut dans Kerberos pour utiliser l'Advanced Encryption Standard (AES)-SHA1 au lieu de RC4 pour les comptes pour lesquels un type de chiffrement n'a pas été défini explicitement. Cette modification a entraîné une réduction significative de l’utilisation de RC4, mais RC4 est toujours utilisé par défaut pour les comptes qui ne prennent pas en charge AES-SHA1. Pour plus d’informations, consultez KB5021131.

Cette mise à jour ajoute la possibilité de définir une valeur de Registre pour contrôler le type de chiffrement pris en charge par défaut dans Kerberos. Si vous ne définissez pas cette valeur de Registre, les types de chiffrement pris en charge par défaut sont DES, RC4 et AES.

Le type de chiffrement Kerberos RC4 par défaut peut être utilisé pour effectuer une méthode d’attaque appelée Kerberoasting, qui cible les tickets de service dans Microsoft Active Directory. Dans Kerberoasting, les attaquants capturent ces tickets et fissurent leur chiffrement hors connexion pour voler les informations d’identification de l’utilisateur, ce qui peut compromettre la sécurité de l’ensemble du réseau. La modification du type de chiffrement Kerberos pour utiliser AES-SHA1 par défaut au lieu de RC4 permet de protéger les clients contre cette attaque.

Important

Microsoft envisage de désactiver l’utilisation de RC4 comme type de chiffrement pris en charge par défaut pour les contrôleurs de domaine Active Directory d’ici la fin du deuxième trimestre 2026. Pour en savoir plus sur la préparation de la désactivation de RC4, consultez Comment gérer l’utilisation du KDC Kerberos de RC4 pour les modifications d’émission de ticket de compte de service liées à CVE-2026-20833.

Prerequisites

Avant de commencer, vous devez respecter les conditions préalables suivantes :

Vous avez besoin d’autorisations pour accéder aux journaux des événements de sécurité sur les contrôleurs de domaine, comme être membre du groupe Administrateurs du domaine ou équivalent.
Si vous souhaitez exécuter les commandes et les scripts PowerShell dans cet article, vous devez installer le module ActiveDirectory sur l’appareil sur lequel vous exécutez les commandes.

Auditer l’utilisation de RC4

Des détails sur l’utilisation de RC4 sont stockés dans les journaux des événements de sécurité sur Kerberos Centres de distribution de clés (KDCS) pour les Windows Server 2019 et versions ultérieures. L’utilisation de RC4 dans les journaux d’événements a également été ajoutée à Windows Server 2016 dans la mise à jour cumulative de janvier 2025. Les ID d’événement suivants identifient l’utilisation et les comptes RC4 qui sont uniquement en mesure d’utiliser RC4 :

ID d’événement 4768, qui concerne le ticket d’authentification Kerberos demandé.
ID d’événement 4769, qui concerne le ticket de service Kerberos demandé.

Champs du journal des événements pour l’utilisation de RC4

Dans chaque entrée pour les ID d’événement 4768 et 4769, il existe plusieurs champs qui fournissent des informations sur les types de chiffrement pris en charge par le compte et le type de chiffrement utilisé pour le ticket. Voici un exemple de capture d’écran. La liste suivante décrit les champs pertinents dans ces deux événements.

Une capture d'écran de l'observateur d'événements montrant les détails de l'identifiant d'événement Kerberos 4768, y compris les types de chiffrement et les informations de compte.

Sections Informations sur le compte et informations sur le service :
- MSDS-SupportedEncryptionTypes : est un attribut Active Directory qui désigne les types de chiffrement pris en charge par le compte. Si msDS-SupportedEncryptionTypes n’est pas défini pour le compte, le KDC applique la valeur de DefaultSupportedEncryptionTypes. Ce champ est parfois appelé msds-SET.
  
  Cette valeur est une valeur traitée, ce qui signifie que certains comptes ont des conditions supplémentaires spécifiées en dehors de la msDS-SupportedEncryptionTypes valeur définie dans la base de données AD. Par exemple, sur Windows Server 2022 et versions antérieures, msDS-SupportedEncryptionTypes affiche toujours data Encryption Standard (DES) et RC4 pour garantir la compatibilité avec les contrôleurs de domaine plus anciens, quels que soient vos paramètres. À compter de Windows Server 2025, seuls les algorithmes AES-SHA1 et plus forts sont affichés. Il est normal si la valeur traitée pour ces principaux de sécurité ne correspond pas exactement à ce qui se trouve dans l'attribut Active Directory.
  
  Ce champ est renseigné uniquement pendant la recherche de compte. La recherche de compte remplit ce champ avec les informations de compte et de service lors d’un événement avec l’ID 4768 et les répertorie dans les informations de service lors d’un événement avec l’ID 4769. Pour plus d’informations, consultez les fanions des types de chiffrement pris en charge.
- Clés disponibles : clés disponibles pour le compte dans AD. Le mot de passe est haché avec les algorithmes affichés. La population de ce champ est soumise aux mêmes restrictions que msDS-SupportedEncryptionTypes. RC4 est affiché indépendamment de l’utilisation.
Section Informations sur le contrôleur de domaine . Cette section utilise également des valeurs traitées et suit les mêmes instructions décrites précédemment.
- MSDS-SupportedEncryptionTypes : inclut les types de chiffrement pris en charge pour le contrôleur de domaine msDS-SupportedEncryptionTypes.
- Clés de compte : inclut des clés de compte pour le contrôleur de domaine.
Section Informations réseau :
- Types de chiffrement annoncés : énumération des types de chiffrement que l’ordinateur client signale comme pris en charge pour l’opération actuelle.
Section Informations supplémentaires :
- Type de chiffrement de session : type de chiffrement utilisé pour la clé de session de ticket.

Vous pouvez utiliser les champs msDS-SupportedEncryptionTypes ou Advertized Etypes pour déterminer si un client ou une machine cible ne prend pas en charge l'AES-SHA1 ou prend uniquement en charge le RC4.

Développez cette section pour afficher une table qui mappe le type de chiffrement à l’algorithme utilisé.

Valeur décimale	Valeur hexadécimale	Types de chiffrement pris en charge
0	0x0	Non défini : valeur par défaut RC4_HMAC_MD5
1	0x1	DES_CBC_CRC
2	0x2	DES_CBC_MD5
3	0x3	DES_CBC_CRC, DES_CBC_MD5
4	0x4	RC4
5	0x5	DES_CBC_CRC, RC4
6	0x6	DES_CBC_MD5, RC4
7	0x7	DES_CBC_CRC, DES_CBC_MD5, RC4
8	0x8	AES 128
9	0x9	DES_CBC_CRC, AES 128
10	0xA	DES_CBC_MD5, AES 128
11	0xB	DES_CBC_CRC, DES_CBC_MD5, AES 128
12	0xC	RC4, AES 128
13	0xD	DES_CBC_CRC, RC4, AES 128
14	0xE	DES_CBC_MD5, RC4, AES 128
15	0xF	DES_CBC_CRC, DES_CBC_MD5, RC4, AES 128
16	0x10	AES 256
17	0x11	DES_CBC_CRC, AES 256
18	0x12	DES_CBC_MD5, AES 256
19	0x13	DES_CBC_CRC, DES_CBC_MD5, AES 256
20	0x14	RC4, AES 256
Vingt-et-un	0x15	DES_CBC_CRC, RC4, AES 256
22	0x16	DES_CBC_MD5, RC4, AES 256
23	0x17	DES_CBC_CRC, DES_CBC_MD5, RC4, AES 256
Vingt-quatre	0x18	AES 128, AES 256
25	0x19	DES_CBC_CRC, AES 128, AES 256
26	0x1A	DES_CBC_MD5, AES 128, AES 256
27	0x1B	DES_CBC_CRC, DES_CBC_MD5, AES 128, AES 256
28	0x1C	RC4, AES 128, AES 256
29	0x1D	DES_CBC_CRC, RC4, AES 128, AES 256
30	0x1E	DES_CBC_MD5, RC4, AES 128, AES 256
31	0x1F	DES_CBC_CRC, DES_CBC_MD5, RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96

Développez cette section pour afficher une table qui mappe les valeurs dans les événements au type de chiffrement des tickets émis.

Valeur de type	Type de chiffrement
0x1	DES_CBC_CRC
0x3	DES_CBC_MD5
0x11	AES128-CTS-HMAC-SHA1-96
0x12	AES256-CTS-HMAC-SHA1-96
0x17	RC4-HMAC
0x18	RC4-HMAC-EXP

Pour une analyse plus approfondie de msDS-SupportedEncryptionTypes et des types de chiffrement, consultez notre article de blog Déchiffrer la sélection des types de chiffrement Kerberos pris en charge.

Utiliser PowerShell pour auditer l’utilisation de RC4

La recherche manuelle des journaux d’événements pour identifier l’utilisation de RC4 est une tâche fastidieuse. Pour un audit plus efficace, il existe deux scripts PowerShell que vous pouvez télécharger pour vous aider :

List-AccountKeys.ps1 pour interroger les journaux des événements afin d’énumérer les clés de chiffrement disponibles pour les comptes.
Get-KerbEncryptionUsage.ps1 pour identifier les types de chiffrement Kerberos en cours d’utilisation, avec des options de filtrage pour des algorithmes spécifiques comme RC4.

Microsoft publié ces scripts en tant que open source et ils sont disponibles dans Microsoft dépôt Kerberos-Crypto GitHub. Vous pouvez également identifier l'utilisation de RC4 à l'aide d'une solution SIEM (Security Information and Event Management), comme Microsoft Sentinel, ou un transfert de Windows intégré, comme décrit dans notre billet de blog So, vous pensez que vous êtes prêt à appliquer AES pour Kerberos ?.

Téléchargez les deux scripts PowerShell répertoriés à partir du dépôt Kerberos-Crypto GitHub Microsoft.
Ouvrez une session PowerShell en tant qu’administrateur sur un contrôleur de domaine ou connectez-vous à distance à l’aide de l’applet de commande Enter-PSSession sur un appareil que vous utilisez pour gérer les contrôleurs de domaine.

Exécutez le script List-AccountKeys.ps1 avec la commande suivante. Ce script interroge le journal des événements de sécurité et énumère les clés disponibles pour les comptes qu’il trouve.

.\List-AccountKeys.ps1

Dans cet exemple de sortie, vous pouvez voir l’heure à laquelle l’événement s’est produit, le nom du compte, le type de compte et les clés du compte. Dans ce cas, vous pouvez voir que les clés AES-SHA1 sont disponibles et qu’elles supportent l’utilisation d’AES-SHA1.

Time                  Name         Type  Keys
----                  ----         ----  ----
1/21/2025 2:00:10 PM  VM01$      Machine {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}
1/21/2025 2:00:10 PM  AdminUser     User {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}
1/21/2025 6:50:34 PM  VM01$      Machine {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}
1/21/2025 6:50:34 PM  AdminUser     User {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}
1/21/2025 6:50:34 PM  VM01$      Machine {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}

Exécutez le script Get-KerbEncryptionUsage.ps1 avec la commande suivante. Ce script interroge les mêmes événements pour voir l’utilisation Kerberos trouvée dans l’environnement.

.\Get-KerbEncryptionUsage.ps1

Time       : 1/21/2025 2:00:10 PM
Requestor  : ::1
Source     : AdminUser@CONTOSO.COM
Target     : VM01$
Type       : TGS
Ticket     : AES256-SHA96
SessionKey : AES256-SHA96

Time       : 1/21/2025 2:00:10 PM
Requestor  : 192.168.1.1
Source     : AdminUser
Target     : krbtgt
Type       : AS
Ticket     : AES256-SHA96
SessionKey : AES256-SHA96

Ce script inclut des options de filtrage pour des algorithmes spécifiques et peut être filtré pour une utilisation RC4, comme illustré dans l’exemple suivant :

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4

Options pour gérer l’utilisation de RC4

Si vous constatez que vous utilisez toujours RC4, il existe quelques choses que vous pouvez faire en fonction de la raison pour laquelle RC4 a été utilisé.

Un compte d’utilisateur utilise RC4, car il n’a pas de clés AES-SHA1

Si un compte d’utilisateur a été créé avant la prise en charge des clés AES-SHA1 dans Windows Kerberos et que le mot de passe n’a jamais été réinitialisé une fois la prise en charge ajoutée, le compte est manquant AES-SHA1 clés. La prise en charge de AES-SHA1 dans Windows Kerberos a été ajoutée dans Windows Server 2003. La modification du mot de passe du compte génère ces clés.

Vous n’avez pas besoin de définir de valeur pour msDS-SupportedEncryptionTypes les comptes d’utilisateur sans nom de principal de service (SPN). La configuration de l’appareil détermine le type de chiffrement pour les demandes de ticket de service et les clés de session.

La valeur msDS-SupportedEncryptionTypes traitée n’inclut pas les bits AES-SHA1

Si la valeur traitée msDS-SupportedEncryptionTypes n’inclut pas AES-SHA1, cela peut être le résultat d’une poignée de conditions.

Cas : les types de chiffrement pris en charge par la machine source et/ou cible n’incluent pas AES-SHA1. Dans ce cas, confirmez la configuration de la stratégie et mettez-la à jour afin qu’elle inclut AES-SHA1. Vous pouvez afficher l'msDS-SupportedEncryptionTypes configuré dans les propriétés du compte dans Utilisateurs et ordinateurs Active Directory console ou à l’aide de PowerShell.
- Pour Utilisateurs et ordinateurs Active Directory, vérifiez que la vue Advanced Features est activée, puis ouvrez les propriétés du compte d’ordinateur et accédez à l’onglet Attribute Editor. Recherchez l’attribut msDS-SupportedEncryptionTypes :
- Pour PowerShell, exécutez la commande suivante pour récupérer l’attribut msDS-SupportedEncryptionTypes . Veillez à remplacer <computer account name> par le nom réel du compte que vous souhaitez vérifier.
```
$accountName = "<computer account name>"
$parameters = @{
     Filter     = "Name -eq '$($accountName)' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')"
     Properties = "msDS-SupportedEncryptionTypes"
}

Get-ADObject @parameters | FL "DistinguishedName","msDS-SupportedEncryptionTypes","Name","ObjectClass"
```
  Voici un exemple de sortie. La valeur de msDS-SupportedEncryptionTypes est en décimal au lieu d’hexadécimal, que vous pouvez convertir en utilisant le tableau fourni dans la section des champs du journal des événements pour l’utilisation de RC4.
```
DistinguishedName             : CN=vm01,CN=Computers,DC=contoso,DC=com
msDS-SupportedEncryptionTypes : 28
Name                          : vm01
ObjectClass                   : computer
```
Si la msDS-SupportedEncryptionTypes valeur dans AD pour la machine source et/ou cible n’est pas définie, le KDC revient à la DefaultDomainSupportedEncTypes valeur, comme décrit dans le deuxième cas.

Pour déterminer les valeurs qui conviennent le mieux à votre environnement, nous vous recommandons de lire Active Directory Série de sécurité renforcée - Partie 4 – Imposition de l'AES pour Kerberos | Microsoft Community Hub. Après avoir trouvé la combinaison appropriée pour votre environnement, redémarrez l’ordinateur et mettez à jour ses msDS-SupportedEncryptionTypes attributs dans la base de données AD.
Cas : la msDS-SupportedEncryptionTypes valeur dans AD pour l’ordinateur source n’est pas définie et le KDC revient à la DefaultDomainSupportedEncTypes valeur. Ce cas est plus complexe et nécessite une compréhension holistique de votre environnement à résoudre. La DefaultDomainSupportedEncTypes valeur est utilisée pour définir les types de chiffrement pris en charge par défaut pour les appareils qui n’ont pas de valeur msDS-SupportedEncryptionTypes. Il existe deux approches pour résoudre cette situation :
- Définissez la valeur spécifique msDS-SupportedEncryptionTypes dans les propriétés du compte pour vous assurer qu’elle ne revient pas à la DefaultDomainSupportedEncTypes valeur.
- Vous pouvez également définir la DefaultDomainSupportedEncTypes valeur pour inclure AES-SHA1.
La méthode correcte dépend de votre tolérance de risque individuelle, car la mise à jour de la DefaultDomainSupportedEncTypes valeur modifie le comportement de tous les comptes qui n’ont pas de valeur.

Un dispositif ne prend pas en charge AES-SHA1

Pour les appareils Windows, la dernière version de Windows qui ne prenait pas en charge AES-SHA1 était Windows Server 2003, qui est out du support. Vous devez migrer vers une version de Windows prenant en charge AES-SHA1. Pour les comptes créés avant AES-SHA1 prise en charge, réinitialisez les mots de passe pour générer des clés de chiffrement modernes, telles qu’AES-SHA1. Pour les comptes qui ne prennent pas en charge SHA-1, configurez manuellement les types de chiffrement pris en charge pour inclure RC4.

Conseil / Astuce

Si vous disposez d’un appareil tiers qui ne prend pas en charge AES-SHA1, contactez stillneedrc4@microsoft.com avec des informations sur l’appareil et le scénario.

Limiter ou désactiver l’utilisation RC4

La modification du type de chiffrement Kerberos par défaut a entraîné une réduction significative de l’utilisation de RC4. Toutefois, si vous souhaitez réduire davantage l’utilisation de RC4, vous pouvez limiter l’utilisation de RC4 par stratégie de groupe ou désactiver RC4 entièrement dans votre domaine.

Caution

À compter de Windows Server 2025, les contrôleurs de domaine n'émettent pas de tickets d'octroi de tickets RC4. Bien que vous puissiez vous authentifier auprès d’appareils hérités avec RC4, l’appareil hérité n’est pas en mesure de s’authentifier à l’aide de Kerberos. Vous devez utiliser des versions antérieures de Windows Server pour vos contrôleurs de domaine.

Pour limiter ou désactiver l’utilisation de RC4 :

Créez un objet de stratégie de groupe (GPO) à l’aide de la console de gestion des stratégies de groupe. Pour plus d’informations, consultez Gestion des stratégies de groupe.
Modifiez l’objet de stratégie de groupe et accédez à Configuration de l'ordinateur>Stratégies>Paramètres Windows>Paramètres de sécurité>Stratégies locales>Options de sécurité.
Recherchez le paramètre de stratégie sécurité réseau : configurez les types de chiffrement autorisés pour Kerberos. Double-cliquez sur la politique pour ouvrir ses propriétés.
Spécifiez les types de chiffrement que vous souhaitez autoriser. Voici quelques exemples :
- Pour autoriser uniquement AES-SHA1, cochez les cases pour AES128_HMAC_SHA1 et AES256_HMAC_SHA1.
- Pour autoriser AES-SHA1 et RC4, cochez les cases pour AES128_HMAC_SHA1, AES256_HMAC_SHA1 et RC4_HMAC_MD5.
  
  Une capture d’écran de la sécurité du réseau : Configurer les types de chiffrement autorisés pour les paramètres de stratégie Kerberos dans Windows avec RC4 sélectionné et mis en surbrillance.
Appliquez la stratégie de groupe (GPO) aux unités d’organisation (OU) ou groupes appropriés qui contiennent les appareils auxquels vous voulez appliquer la stratégie. Vérifiez qu’il se propage aux appareils cibles, puis redémarrez les appareils pour appliquer les nouveaux paramètres.
Une fois la stratégie appliquée, surveillez les événements d’authentification pour vous assurer qu’aucun échec d’authentification inattendu ne se produit. Vous pouvez utiliser les scripts PowerShell mentionnés dans la section Utiliser PowerShell pour auditer l’utilisation de RC4 pour vérifier que RC4 n’est plus utilisé.

Vous pouvez également désactiver RC4 sur les contrôleurs de domaine en définissant la valeur de Registre suivante, qui autorise AES128_HMAC_SHA1 uniquement et AES256_HMAC_SHA1:

Clé :HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC
Nom de la valeur : DefaultDomainSupportedEncTypes
Entrez : REG_DWORD
Données de valeur : 0x18

Identifier les échecs d’authentification après la désactivation de RC4

Lorsque RC4 est désactivé, l’authentification peut échouer pour certains systèmes. Cette section traite des scénarios courants et des indicateurs pour identifier un problème potentiel provoqué par la désactivation de RC4. Voici deux scénarios courants où des échecs d’authentification peuvent se produire :

Server Message Block (SMB) : lorsque vous tentez d’accéder à un partage à l’aide de SMB et RC4 est la seule valeur pour msDS-SupportedEncryptionTypes, une défaillance d’authentification génère une erreur réseau, comme illustré dans la capture d’écran suivante :

Windows Management Instrumentation (WMI) : lorsque vous tentez de créer une session PowerShell distante à l’aide de l’applet de commande New-PSSession, qui utilise WMI et RC4 est la seule valeur pour msDS-SupportedEncryptionTypes, un échec d’authentification génère un message d’erreur, comme illustré dans l’exemple suivant :

New-PSSession : [vm01.contoso.com] Connecting to remote server vm01.contoso.com failed with the following
error message : WinRM cannot process the request. The following error with errorcode 0x80090342 occurred
while using Kerberos authentication: An unknown security error occurred.

Possible causes are:
   -The user name or password specified are invalid.
   -Kerberos is used when no authentication method and no user name are specified.
   -Kerberos accepts domain user names, but not local user names.
   -The Service Principal Name (SPN) for the remote computer name and port does not exist.
   -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
   -Check the Event Viewer for events related to authentication.
   -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration
setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. For more
information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:6
+ $s = New-PSSession vm01.contoso.com
+      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession],
     PSRemotingTransportException
     + FullyQualifiedErrorId : err ,PSSessionOpenFailed

Pour effectuer l’un de ces scénarios, procédez comme suit :

Essayez d’effectuer une demande directe de ticket de service à ce point d'accès à l’aide de la commande klist Windows, pour obtenir de plus amples détails sur l'erreur en cas d'échec. L’exemple suivant montre une demande de ticket de service au service HOST sur vm01.contoso.com.

Ouvrez une session PowerShell et exécutez la commande suivante à partir d’un appareil qui tente de s’authentifier auprès de l’appareil cible :
```
klist get HOST/vm01.contoso.com
```
Voici un exemple de sortie montrant que KDC ne prend pas en charge le type de chiffrement demandé :
```
Current LogonId is 0:0xd6ed18
Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x80090342

klist failed with 0xc00002fd/-1073741059: The encryption type requested is not supported by the KDC.
```

Ouvrez l’ID d’événement 4769 sur le KDC pour la même requête, vous verrez le code d’erreur 0xE, qui correspond au nom d’erreur KDC_ERR_ETYPE_NOTSUPP. Cette erreur signifie que le KDC ne prend pas en charge le type de chiffrement. Vous pouvez mettre en corrélation d’autres erreurs dans l’annexe C : Messages d’erreur Kerberos et LDAP.

A Kerberos service ticket was requested.

Account Information:
    Account Name:       adele@CONTOSO.COM
    Account Domain:     CONTOSO.COM
    Logon GUID:     {00000000-0000-0000-0000-000000000000}
    MSDS-SupportedEncryptionTypes:  -
    Available Keys: -

Service Information:
    Service Name:       HOST/vm01.contoso.com
    Service ID:     NULL SID
    MSDS-SupportedEncryptionTypes:  -
    Available Keys: -

Domain Controller Information:
    MSDS-SupportedEncryptionTypes:  -
    Available Keys: -

Network Information:
    Client Address:     ::ffff:192.168.1.112
    Client Port:        60090
    Advertized Etypes:  -

Additional Information:
    Ticket Options:     0x40810000
    Ticket Encryption Type: 0xFFFFFFFF
    Session Encryption Type:    0x2D
    Failure Code:       0xE
    Transited Services: -

Suivez les étapes de la section La valeur msDS-SupportedEncryptionTypes traitée n’inclut pas les bits AES-SHA1 pour déterminer le type de chiffrement pris en charge pour l’appareil cible. Dans cet exemple, la valeur msDS-SupportedEncryptionTypes pour vm01.contoso.com est 0x4, indiquant que seul RC4 est configuré pour le compte.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-02-06