Sommaire
TogglePrésentation
Cet article présente les améliorations apportées au PAC (Privilege Attribute Certificate), un élément essentiel dans le processus d’accès aux ressources dans un environnement utilisant le protocole Kerberos.
Protocole Kerberos et PAC (C’est quoi le PAC ?)
Avant de parler du PAC, nous allons d’abord présenter le processus d’authentification Kerberos.
Pour accéder à une ressource via l’authentification Kerberos, 3 phases sont nécessaires :
- La première consiste en l’authentification du client souhaitant accéder à un service, et se termine par l’obtention d’un ticket TGT.
- La seconde est la demande d’un ticket de service que l’on présentera au service et s’appelle le ticket TGS.
- La troisième phase est l’accès au service en lui-même
Ci-dessous une illustration du processus d’authentification Kerberos permettant d’accéder à un service :


Figure 1 : Processus d’authentification Kerberos
Le PAC est un composant des tickets Kerberos (TGT et TGS) et contient les informations relatives aux autorisations du client qui veut accéder au service notamment : les identificateurs de sécurité, l’appartenance à un groupe, les informations de profil utilisateur et les informations autour du mot de passe (PWD Last Set, PWD Can Change, etc…).
Il permet aux services d’appliquer les politiques d’accès sans avoir besoin de demander les droits de l’utilisateur au domaine à chaque fois (Ce qui améliore les performances du processus d’autorisation).
A ce stade, nous voyons très bien que la falsification du contenu du PAC peut entraîner une élévation de privilèges.
A propos de la validation PAC
La validation du PAC (Privilege Attribute Certificate) est un mécanisme de sécurité conçu pour prévenir l’usurpation de ce dernier. Elle empêche un attaquant d’accéder à un système ou à ses ressources sans autorisation en utilisant un PAC falsifié.
Lorsqu’un ticket de service (TGS) est présenté à un serveur, celui-ci doit s’assurer que le PAC n’a pas été altéré ou forgé. Pour cela, le serveur peut faire appel au contrôleur de domaine (DC) via le protocole netLogon, qui compare le contenu du PAC avec les informations réellement détenues dans l’annuaire Active Directory.
!!! La validation PAC (Privilege Attribute Certificate) peut ne pas être exécutée dans les contextes suivants :
- Lorsque le service s’exécute sous le compte de service « Local Service » ou « Network Service »
- Lorsque le service s’exécute dans un contexte de sécurité disposant du privilège SeTcbPrivilege (Act as part of the operating system)
Présentation du renforcement du PAC depuis 2021
La validation PAC a été considérablement renforcée depuis 2021, ci-dessous le tableau récapitulatif des changements majeurs :

Nous allons maintenant détailler les différentes améliorations apportées à travers ces mises à jour.
Améliorations de la validation PAC au 9 novembre 2021
Le processus d’authentification amélioré ajoute de nouvelles informations sur le demandeur d’origine aux certificats PAC des tickets TGT (Ticket-Granting Tickets) de Kerberos. Plus tard, quand un ticket de service Kerberos est généré pour un compte, le nouveau processus d’authentification vérifie que le compte qui a demandé le ticket TGT est le même que celui référencé dans le ticket de service.
Plus concrètement, le champ PAC_requestor est ajouté dans la structure PAC du TGT, il contient le SID du demandeur du ticket TGT. Lorsque la demande du ticket TGS est effectuée, le champ Clientname est comparé au champ PAC_requestor du TGT pour s’assurer qu’un TGT valide n’a pas été utilisé pour générer un TGS (pour un compte avec des privilèges élevés). Dans le cas échéant, le TGS est rejeté.
Ci-dessous un schéma simplifié du nouveau processus d’obtention du ticket TGS :

Figure 2 : Nouveau PAC
Le déploiement se fait en trois phases via la clé de régistre PacRequestorEnforcement (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Kdc)
- Phase 1 (nov 2021) : Ajout de la clé de régistre PacRequestorEnforcement
- Phase 2 (juillet 2022) : Modifie la valeur par défaut de la clé de régistre, qui correspond à l’exigence de la validation du demandeur lors du processus d’authentification
- Phase 3 (octobre 2022) : Suppression de la clé de régistre
Améliorations de la validation PAC au 8 novembre 2022
Cette mise à jour introduit une phase de déploiement initial dans laquelle le KDC est contraint d’ajouter systématiquement les signatures PAC_KDC_SIGNATURE et PAC_SERVER_SIGNATURE dans les tickets TGS.
- PAC_KDC_SIGNATURE : générée par le KDC à l’aide de la clé secrète du compte krbtgt, elle garantit que le PAC provient bien du KDC du domaine.
- PAC_SERVER_SIGNATURE : également générée par le KDC, mais en utilisant la clé Kerberos du compte de service cible (ex : machine, SQL, etc.), afin que le service puisse valider le PAC à réception.
À ce stade, la vérification stricte des signatures n’est pas encore en vigueur ; cette phase se limite à l’ajout des signatures dans les tickets.
Ci-dessous la chronologie permettant l’application progressive :
- Phase 1 (Nov 2022) : Ajoute des signatures PAC à la mémoire tampon PAC Kerberos et des mesures pour traiter la vulnérabilité de contournement de sécurité dans le protocole Kerberos. La signature PAC est contrôlée par la clé de régistre KrbtgtFullPacSignature
- Phase 2 (Dec 2022) : la phase d’audit est activée permettant de loguer les informations et d’autoriser l’authentification même si la signature est manquante ou incorrecte
- Phase 3 (Juin 2023) : Cette phase supprime la possibilité de désactiver l’ajout de la signature PAC
- Phase 4 (Juillet 2023) : Active le mode défaut à l’état Activé et donne la possibilité de passer en mode audit
- Phase 5 (Octobre 2023) : Désactive la possibilité de passer en mode audit et supprime la clé de régistre KrbtgtFullPacSignature
Améliorations de la validation PAC au 9 Avril 2024
Les précédentes mises à jour imposaient la présence des signatures dans le PAC, cette dernière sera focus sur la validation de ces signatures. Comme de coutume, l’application est progressive et détaillée comme suit :
- Phase 1 (9 avril 2024) : Cette phase active le nouveau comportement lié à la validation du PAC mais ne l’applique pas par défaut. L’application peut être gérée via la clé de régistre (PacSignatureValidationLevel, CrossDomainFilteringLevel et AuditKerberosTicketLogonEvents)
- Phase 2 (janvier 2025) : Cette mise à jour applique le nouveau comportement de validation PAC par défaut, le mode appliqué peut être remplacé par le mode compatibilité
- Phase 3 (avril 2025) : la prise en charge du mode compatibilité est activée et les clés de régistre sont supprimés (PacSignatureValidationLevel, CrossDomainFilteringLevel)
Conclusion
Le protocole Kerberos a encore de beaux jours devant lui, Microsoft n’ayant pas l’intention d’abandonner Active Directory, comme en témoigne l’ajout de nouvelles fonctionnalités dans Windows 2025. Des améliorations continueront probablement d’être apportées au fil de la découverte de nouvelles vulnérabilités. J’espère que cet article vous a aidé à mieux comprendre le fonctionnement de l’authentification Kerberos, les évolutions liées à la validation du PAC, et qu’il vous servira de base pour appréhender les développements futurs.
Annexes
En plus des liens contenus dans l’article, ci-dessous quelques ressources pour aller plus loin :
- Patch Tuesday d’avril 2025 : votre AD est-il prêt pour les changements ?
- [MS-APDS]: Kerberos PAC Validation | Microsoft Learn
- Exploration du protocole KERBEROS – Déchiffrer le PAC – Rémi VERNIER
Article écrit par Guylaine BIMONG


