Patch Tuesday d’avril 2025 : votre Active Directory est-il prêt pour la validation du PAC ?

 I. Présentation

Dans cet article, nous allons voir comment analyser et anticiper les effets du Patch Tuesday d'avril 2025 au niveau du PAC de Kerberos, afin de prévenir toute interruption ou anomalie en production.

Ce patch corrige les vulnérabilités CVE-2024-26248 et CVE-2024-29056. Ces failles de sécurité nécessitent une gestion minutieuse pour garantir la stabilité et la sécurité de votre environnement Active Directory.

II. À propos du correctif PAC

Le correctif cumulatif de sécurité a pour but de renforcer le mécanisme d’authentification Kerberos en rendant obligatoire la validation du PAC (Privilege Attribute Certificate). Auparavant facultative et relevant principalement des bonnes pratiques de sécurité (hardening), cette validation devient désormais obligatoire. Elle a été imposée par Microsoft via le patch cumulatif d’avril 2025.

• Patch Tuesday d'avril 2025 : ce que vous devez savoir

A. Comprendre le PAC de Kerberos

Le PAC correspond à des informations supplémentaires intégrées au ticket Kerberos. Son rôle est d'informer le service destinataire (par exemple, un serveur de fichiers) d’effectuer une validation complémentaire auprès du contrôleur de domaine (DC), afin d’éviter toute falsification potentielle du ticket.

Ainsi, lorsqu’un utilisateur présente un ticket Kerberos contenant le PAC, le serveur destinataire est tenu de vérifier auprès du DC que les informations d'autorisation contenues dans ce ticket, telles que l’appartenance à un groupe spécifique, sont effectivement valides. Cela permet d'assurer une sécurité accrue et limite le risque d'usurpation d'identité ou d’élévation abusive de privilèges.

Ce mécanisme est illustré par la capture ci-dessous :

B. Illustration du processus

Lors de l'authentification, le serveur KDC (Kerberos Distribution Center) d'Active Directory distribue un ticket contenant des informations sur les groupes auxquels appartient l'utilisateur. Par exemple, si l'utilisateur est membre du groupe "RH", le serveur de fichiers lui accordera l'accès basé sur cette information. Cependant, cela ouvre la possibilité à une vulnérabilité de type "Silver Ticket", où un attaquant pourrait falsifier le ticket pour obtenir un accès non autorisé aux ressources.

Le mécanisme du PAC intervient pour résoudre ce problème : une signature est ajoutée au ticket Kerberos, et le serveur de fichiers, avant d'accorder l'accès, interroge le contrôleur de domaine pour vérifier l'appartenance de l'utilisateur au groupe mentionné dans le ticket. Cette validation renforce la sécurité du système en limitant les risques d'accès non autorisé.

C. Problématique avec les systèmes anciens

Dans ce processus de validation du PAC, certains systèmes anciens (tels que des serveurs de fichiers, anciens systèmes d'exploitation, applications, Citrix, etc.) pourraient ne pas être compatibles avec ce nouveau mode de validation.

Ces systèmes risquent de rejeter le ticket Kerberos lors de l'authentification, ce qui peut entraîner des interruptions de service. C'est pourquoi notre plan de déploiement prévoit d’identifier ces cas spécifiques à l’avance pour éviter toute perturbation.

D. Phase de déploiement du renforcement PAC

Malheureusement, nous nous retrouvons déjà dans la situation de mise en application : le Patch Tuesday d’avril 2025 ayant été publié par Microsoft le mardi 8 avril 2025. Ainsi, ce correctif, comme précisé précédemment, force la signature PAC et il empêche son contournement.

• Que se passe-t-il ?

Les mises à jour de sécurité Windows publiées au cours de cette phase supprimeront la prise en charge des sous-clés de registre (telles que PacSignatureValidationLevel et CrossDomainFilteringLevel) et appliqueront pleinement le comportement sécurisé de validation PAC.

• Impact :

Aucun retour au mode de compatibilité n'est disponible, il est donc essentiel que votre environnement soit entièrement mis à jour et conforme avant l'arrivée de cette phase.

- Sous-clé de registre :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

- Valeur : PacSignatureValidationLevel

- Données : 2 (mode compatibilité)

Deux scénarios sont possibles :

• Vous avez déjà installé le patch sans ajouter de clé de compatibilité. À ce moment-là, il faudra analyser les events et si votre infrastructure n’utilise pas de systèmes obsolètes, il y a des chances pour que vous ne soyez pas impacté.
• Vous n'avez pas encore passé le patch sur les DC où vous maintenez la clé de registre en mode compatibilité, il faudra alors effectuer l’analyse. Cela vous permettra de savoir si vos environnements acceptent le PAC ou s’il sera rejeté.

E. Comment identifier les problèmes ?

Les journaux suivants permettent de détecter l'anomalie liée aux incompatibilités avec le patch de sécurité.

Voici les ID d'événements système critiques à surveiller :

• ID d'événement 21 : événements d'information lors de la connexion au ticket réseau.
• ID d'événement 22 : erreurs indiquant un refus d'authentification lors de la rencontre de contrôleurs de domaine non corrigés.
• ID d'événement 23 : avertissements et erreurs lorsque le retour au comportement précédent se produit.
• ID d’événements 5842 et 5843 : échec de connexion Netlogon pour le service Kerberos

Note : malheureusement ces évènements ne se produisent qu'en cas d'échec, si vous avez déjà appliqué le patch et vous n'avez pas remarqué ces évènements, c'est que tout va bien. Si vous avez mis en place la clé de compatibilité sur la valeur « 2 », vous ne pourriez pas remarquer ces évènements car la clé autorise le mode compatibilité et aucun refus ne sera produit, vous devriez alors la forcer en mode appliqué « 3 » ce qui pourra générer des problèmes, nous allons voir comment anticiper cela.

III. PAC : votre infrastructure est-elle prête ?

Si vous avez des doutes concernant la mise en place du patch, la seule possibilité qui nous reste sous le coude est de tester le mode appliqué sur un contrôleur de domaine (DC) moins sollicité. Cela permet de surveiller le trafic et d'analyser les tickets Kerberos pour vérifier si le mécanisme PAC fonctionne correctement.

Si vous n'avez pas encore appliqué le Patch Tuesday d'avril, commencez par ajouter la clé suivante dans votre registre Active Directory en mettant la valeur sur 3 (mode appliqué) :

- Sous-clé de registre :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

- Valeur : PacSignatureValidationLevel

- Données : 3 (mode appliqué)

A. Présentation de mon lab

Voici un schéma qui représente l'environnement utilisé pour la suite de cette démonstration.

Dans mon laboratoire, j'ai intégré un serveur Linux dans le domaine pour simuler des serveurs de fichiers de type ONTAP ancienne génération. Le partage de fichiers est monté comme une cible sur un DFS, porté sur le nom de domaine Active Directory.

Le client accède à la ressource via une GPO qui mappe le partage, exposé sur un serveur Windows. L'accès aux fichiers se fait en plusieurs fragments, forçant ainsi les requêtes PAC (Pre-Authentication Data) de Linux vers l'Active Directory.

Configuration de mon groupe partagé sur Linux :

Explications :

Avec une redirection via Ubuntu sur DFS, le serveur Linux doit présenter la signature PAC du ticket Kerberos à l'AD. En mode compatibilité, aucun événement ne sera visible. Par conséquent, il est nécessaire de passer en mode appliqué pour observer les effets, bien que cela puisse perturber temporairement la production. Cependant, sans cela, il est impossible de s'assurer que le renforcement PAC fonctionne correctement.

Si vous avez plusieurs contrôleurs de domaine (DC), vous pouvez minimiser le risque de coupure en ne testant que sur quelques serveurs à risque. Heureusement, certains serveurs n'effectuent pas d'authentification en permanence, ce qui vous permet de tester pendant cette période.

B. Procédure pour tester la signature PAC

Voici maintenant quelques étapes à appliquer pour tester la signature PAC.

• Modifier la clé de registre : passez la valeur de PacSignatureValidationLevel en mode appliqué (valeur 3).
• Capturer le trafic avec Wireshark : ouvrez Wireshark et choisissez l'interface réseau du DC ou du serveur Linux pour écouter le trafic. Entrez l'adresse IP du serveur censé vérifier la signature PAC (dans notre cas, la machine Linux avec Kerberos), puis commencez la capture.

Le filtre suivant sera appliqué dans Wireshark :

ip.addr == 192.168.1.148 && kerberos

• Purgez le ticket Kerberos : avant de vous connecter au partage, purgez les tickets Kerberos en exécutant la commande suivante, connectez-vous ensuite au partage DFS à partir d'un poste client.

klist purge

Une fois que vous vous êtes connecté au partage et que vous avez observé les connexions Kerberos AS-REQ et AS-REP dans Wireshark, arrêtez la capture de trafic.

• Analyser les paquets Kerberos dans Wireshark : dans Wireshark, recherchez "PAC"- dans les détails des paquets capturés.

• Développez la section « Kerberos », puis la partie « padata ». Vérifiez si une signature PAC est présente dans les échanges.

Cela vous garantira que votre serveur supporte bien le renforcement PAC et ne posera aucun problème de compatibilité avec les nouvelles vérifications de sécurité.

Explication du paquet Kerberos illustré ci-dessus :

• pvno : indique la version du protocole Kerberos utilisé (ici, version 5).
• msg-type : spécifie le type du message Kerberos échangé entre le client et le serveur KDC (Key Distribution Center). Cela détermine la nature du message, par exemple, s'il s'agit d'une demande ou d'une réponse de ticket.
• padata : contient des données de pré-authentification nécessaires avant que le ticket Kerberos soit émis. Dans ce cas, il contient une structure appelée PA-PAC-REQUEST. Cette structure est utilisée pour demander au KDC de valider le PAC et d'inclure les informations d'attribut de privilège dans le ticket d'authentification.

Le cas échéant, l'accès sera refusé et un événement portant le numéro 22 sera généré dans le journal système.

IV. Conclusion

Tout comme le renforcement de SAM-R et le retrait de RC4 dans le passé, la roadmap de Microsoft continue de viser à renforcer la sécurité en supprimant les anciens protocoles obsolètes. Les entreprises sont tenues de prendre en compte ces évolutions et de s'adapter dès maintenant, plutôt que d'attendre la dernière minute.

Si vous vous retrouvez dans une situation où vous ne pouvez pas patcher certains serveurs en raison d'une incompatibilité avec le mécanisme PAC, sachez qu'à ce jour, Microsoft n'a pas fourni de solution de contournement officielle pour ce problème. Dans ce cas, vous pouvez envisager d'utiliser un protocole NTLM pour les applications legacy ou de créer un compte de service SPN et générer un fichier keytab, selon les besoins de votre environnement.

En fin de compte, anticiper ces changements et les appliquer de manière proactive permet de renforcer la sécurité de votre infrastructure Active Directory, tout en minimisant les risques liés aux nouvelles vulnérabilités.

En complément de cet article, vous pouvez lire la documentation de Microsoft à ce sujet.