Les contrôleurs de domaine Active Directory sont marqués « Trusted for delegation ». Voici pourquoi c’est indispensable au fonctionnement de Kerberos, pourquoi on ne peut pas le désactiver, et comment réduire concrètement les risques sans casser l’authentification.
La délégation « non restreinte » sur les contrôleurs de domaine
Problématique
Par conception, un contrôleur de domaine (DC) cumule les rôles de KDC (Key Distribution Center) et d’hôte de services AD (LDAP, GC, Netlogon, RPC, SMB, etc.). Sur son objet d’ordinateur, le bit TRUSTED_FOR_DELEGATION est activé : cela signifie que le DC est autorisé à réutiliser des tickets Kerberos présentés par des clients pour appeler d’autres services au nom de ces clients. C’est exactement ce que Kerberos attend d’un KDC et des services AD. Mais en cas de compromission d’un DC, la « délégation non restreinte » ouvre une surface d’attaque : tous les services Kerberos du domaine peuvent potentiellement être atteints avec des tickets réutilisés.
Les questions posées par la plupart des équipes sécu sont donc :
- Peut‑on supprimer ou désactiver la délégation non restreinte sur les DC ?
- Si ce n’est pas possible, quelles mesures de mitigation efficaces mettre en place ?
Réponse synthétique
| Point | Explication / Solution |
|---|---|
| Pourquoi la délégation est requise ? | Le DC agit à la fois comme KDC et serveur de services AD. Lors d’une authentification, il doit pouvoir présenter ou émettre des tickets (TGT/TGS) et effectuer des opérations de type S4U lorsque nécessaire. Sans la délégation non restreinte sur le DC, la logique Kerberos/AD échoue. Si l’on tente de décocher « Ne pas approuver cet ordinateur pour la délégation » sur un DC, la valeur userAccountControl est réécrite et le flag revient automatiquement, car c’est une invariant d’architecture. |
| Peut‑on convertir un DC en délégation restreinte ? | Non. Au 29 septembre 2025, il n’existe pas de « DC à délégation restreinte ». L’unique variante pertinente est le RODC (Read‑Only Domain Controller) : il n’a pas le flag « Trusted for delegation », mais il est limité par design (lecture seule, cache d’identifiants contrôlé, aucune écriture AD). |
| Mesures de mitigation recommandées | Segmentation & tiering : isolez tous les DC en Tier 0 réseau, zéro usage applicatif, seuls les outils d’admin autorisés. Comptes protégés : placez les identités à haut privilège dans Protected Users, cochez « Compte sensible et ne peut pas être délégué », utilisez Authentication Policies & Silos. Kerberos Armoring (FAST) : activez FAST pour encapsuler et protéger les échanges Kerberos. Mises à jour & LSASS Protection : patch cycle serré, RunAsPPL sur LSASS, durcissement LSA. RODC sur les sites non sécurisés : pas de délégation non restreinte et politique de réplication des mots de passe stricte. Surveillance : journalisez 4768/4769 et corrélez S4U2Self/S4U2Proxy inhabituels ; chassez les abus de délégation. |
| Alternatives pour les applications | Ne placez pas d’applications sur DC : hébergez-les sur des serveurs membres et utilisez KCD « constrained delegation » (liste de SPN autorisés) ou RBCD (Resource‑Based Constrained Delegation) pour des topologies inter‑domaines/forêts. |
Pourquoi les DC sont « Trusted for delegation »
Sur l’attribut userAccountControl d’un DC, deux bits clés existent :
SERVER_TRUST_ACCOUNT(0x2000) : type compte d’ordinateur « contrôleur de domaine ».TRUSTED_FOR_DELEGATION(0x80000) : l’ordinateur est approuvé pour la délégation non restreinte.
Le KDC stocke, émet et valide des TGT/TGS. Dans une forêt avec plusieurs DC, un DC doit pouvoir agir au nom d’un client lorsqu’il contacte d’autres services AD (LDAP/GC, réplication, etc.). Ce fonctionnement implique intrinsèquement la délégation. Essayer de la désactiver revient à retirer un engrenage essentiel du protocole : au mieux, l’authentification se dégrade, au pire elle tombe en panne.
Peut‑on désactiver la délégation non restreinte sur un DC ?
Non. Même si l’on force une écriture LDAP pour retirer TRUSTED_FOR_DELEGATION, le rôle DC et les services AD réappliquent cet état attendu. C’est un comportement de sécurité/fiabilité : un DC doit toujours pouvoir traiter les flux Kerberos et présenter les tickets nécessaires. Le seul « quasi‑équivalent » est d’utiliser un RODC, conçu pour des sites moins sûrs : pas d’écriture AD, cache d’identifiants contrôlé, pas de délégation non restreinte. En pratique : si vous avez besoin d’un DC sans délégation non restreinte, c’est que vous avez besoin d’un RODC, pas d’un DC complet.
Mesures de réduction de risque détaillées
Segmentation, tiering et hygiène d’administration
- Isoler Tier 0 : VLAN/zone dédiée aux DC et bastions. Filtrer strictement le trafic entrant/sortant (LDAP, LDAPS, Kerberos, RPC/SMB, WMI) et refuser tout flux user‑land.
- Postes d’admin dédiés (PAW) : pas de navigation Web ni email depuis les comptes d’admin. MFA fort et durcissements (VBS, HVCI, SmartScreen).
- Contrôles d’accès réseau : seules les jump‑boxes/bastions approuvés peuvent RDP/WinRM vers les DC.
- JEA/JIT : Just Enough Administration et élévation just‑in‑time (PIM/PAM) pour réduire l’exposition temporelle des privilèges.
- Interdire tout logiciel tiers sur DC : pas d’agent applicatif non indispensable, pas d’outils de dev, pas d’applications métiers.
Protéger les identités et comptes sensibles
- Protected Users : placez Domain Admins, Enterprise Admins, KRBTGT et opérateurs hautement privilégiés dans ce groupe pour empêcher la délégation et certaines formes d’authentification faibles.
- Compte sensible et ne peut pas être délégué : activez l’attribut sur tous les comptes privilégiés (y compris comptes de secours).
- Authentication Policies & Silos : limitez où (quels hôtes) les comptes sensibles peuvent s’authentifier ; associez des GPO durs et des durées de ticket réduites.
- gMSA (Group Managed Service Accounts) : pour les services applicatifs, évitez les mots de passe statiques et stockages en clair ; gMSA réduit fortement le risque de vol d’identifiants.
- Hygiène SPN : les SPN ne doivent pas être portés par des comptes à privilèges ; évitez d’attribuer des SPN à des comptes humains.
Durcissement Kerberos et contrôles cryptographiques
- Kerberos Armoring (FAST) :
- Sur Contrôleur de domaine : GPO « KDC support for claims, compound authentication and Kerberos armoring » → Enabled (d’abord en mode Supported), puis basculer en Always provide claims et Fail unarmored authentications une fois le parc client prêt.
- Sur Clients/serveurs membres : GPO « Kerberos client support for claims, compound authentication and Kerberos armoring » → Enabled.
- Désactiver RC4 et DES : n’autoriser que AES128/AES256. Sur les comptes de service, réglez
msDS-SupportedEncryptionTypesà24(AES128 + AES256). - Tickets plus courts : ajustez « Kerberos Policy » (GPO de domaine) : TGT 4 h, TGS 8 h (exemples), renouvellement au besoin selon vos SLA.
- LDAP signing & channel binding : « Domain controller : LDAP server signing requirements » → Require signing ; « LDAP server channel binding » → Require.
- SMB signing : obligatoire côté DC ; envisagez SMB Encryption pour les liens inter‑sites sensibles.
Mises à jour, LSASS et durcissements LSA
- Patch management : appliquez systématiquement les mises à jour Kerberos/LSA/NTLM/LDAP.
- LSASS en PPL :
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL=1(redémarrage requis) pour bloquer les injecteurs non signés Microsoft. - Audit des chargements SSP : refusez tout Security Support Provider non approuvé (
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages).
RODC pour sites non sécurisés
Dans les agences et sites à faible sécurité physique :
- Déployez des RODC et définissez une Password Replication Policy (PRP) stricte (listes Allowed et Denied).
- Assurez-vous que les comptes administratifs du domaine sont dans la liste Denied de tous les RODC.
- Surveillez les événements de cache/dé‑cache d’identifiants et les demandes anormales vers les RODC.
Surveillance et détection des abus de délégation
Activez l’audit avancé :
- Kerberos Authentication Service (4768) et Kerberos Service Ticket Operations (4769) : succès et échecs.
- Événements complémentaires utiles : 4648 (logon avec identifiants explicites), 4672 (droits spéciaux), 5140 (accès partage), 4662/5136 (modifications AD), 4928/4929 (appartenance groupes locaux), 1102 (effacement des logs).
Indicateurs à surveiller :
- Pic de 4769 émis par un DC pour un même service cible inhabituel.
- Émissions S4U2Self/S4U2Proxy inattendues (corrélation entre comptes de service et services autorisés).
- Création/modification d’attributs de délégation (KCD/RBCD) sur des objets computer ou service account sans RFC de changement.
Alternatives applicatives : KCD et RBCD bien configurés
| Mécanisme | Cas d’usage | Configuration | Points d’attention |
|---|---|---|---|
| Constrained Delegation (KCD) | Monodomaine ; service A délègue vers liste restreinte de SPN | Sur le compte du service A : SPN exacts autorisés (onglet « Délégation ») | Limiter au minimum ; privilégier comptes gMSA ; auditer périodiquement la liste des SPN |
| Resource‑Based Constrained Delegation (RBCD) | Inter‑domaines/forêts ; le service cible définit qui peut déléguer | Attribut msDS-AllowedToActOnBehalfOfOtherIdentity sur la ressource | Utiliser des groupes dédiés ; retirer systématiquement les droits après projet ; surveiller toute écriture sur l’attribut |
Procédures pas‑à‑pas (PowerShell & GPO)
Inventorier les DC et vérifier leurs rôles
# Liste des DC
Get-ADDomainController -Filter * |
Select-Object HostName,Site,IPv4Address,IsGlobalCatalog,IsReadOnly
# Lister tous les DC RODC
Get-ADComputer -LDAPFilter '(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=67108864))' `
-Properties dNSHostName |
Select-Object dNSHostName Détecter toute « délégation non restreinte » hors DC
Cet audit est crucial : il trouve les serveurs membres qui seraient, par erreur, « Trusted for delegation ».
# Machines "Trusted for delegation" qui ne sont PAS des DC
Get-ADComputer -LDAPFilter '(&(objectCategory=computer)
(userAccountControl:1.2.840.113556.1.4.803:=524288)
(!(userAccountControl:1.2.840.113556.1.4.803:=8192)))' `
-Properties dNSHostName,operatingSystem |
Select-Object dNSHostName,operatingSystem
Marquer les comptes privilégiés comme « non déléguables »
# Exemple : tous les membres de Domain Admins ne peuvent pas être délégués
Get-ADGroupMember "Domain Admins" -Recursive |
Where-Object {$_.objectClass -eq 'user'} |
ForEach-Object { Set-ADAccountControl $_ -AccountNotDelegated $true }
# Ajouter des comptes au groupe "Protected Users"
Add-ADGroupMember -Identity "Protected Users" -Members user1,user2 Forcer AES uniquement sur les comptes de service
# AES128 (0x08) + AES256 (0x10) = 24
Set-ADUser svc_app -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 }
Activer Kerberos Armoring (FAST)
Déploiement progressif recommandé :
- Activer côté DC en Supported puis valider la compatibilité des clients.
- Activer côté clients/serveurs membres.
- Passer côté DC en Always provide claims et Fail unarmored une fois le parc prêt.
Activer LSASS en Protected Process
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL /t REG_DWORD /d 1 /f
Configurer la délégation restreinte côté ressources (RBCD)
# Autoriser le serveur WEB1 à déléguer vers le service hébergé sur APPSRV1
Set-ADComputer -Identity "APPSRV1" -PrincipalsAllowedToDelegateToAccount "WEB1$"
Checklist de mise en conformité rapide
- ✅ DC uniquement en Tier 0, bastion d’admin, flux réseau minimaux.
- ✅ Aucun logiciel tiers non indispensable sur DC.
- ✅ Comptes à privilèges : Protected Users + « non déléguables » + APS.
- ✅ Kerberos : FAST armoring, AES‑only, tickets courts, RC4/DES bannis.
- ✅ LDAP signing et channel binding obligatoires.
- ✅ RODC sur sites non sécurisés avec PRP restrictive.
- ✅ Audit 4768/4769 + détection S4U anormale.
- ✅ Hygiène SPN/gMSA et revue mensuelle des délégations KCD/RBCD.
Exemples de politiques GPO utiles
| Emplacement GPO | Paramètre | Valeur recommandée | Impact |
|---|---|---|---|
| Computer → Policies → Admin Templates → System → KDC | KDC support for claims, compound authentication and Kerberos armoring | Enabled (puis Fail unarmored) | Protège l’échange Kerberos contre l’abus de tickets |
| Computer → Policies → Windows Settings → Security Settings → Account Policies → Kerberos | Maximum lifetime (TGT/TGS) | TGT 4 h, TGS 8 h (exemple) | Réduit la fenêtre de réutilisation de tickets |
| Security Options | Domain controller : LDAP server signing requirements | Require signing | Empêche le downgrade LDAP clair |
| Security Options | LDAP server channel binding | Require | Évite l’usurpation de session LDAP TLS |
Points d’audit complémentaires
- Inventaire des DC : confirmez que seuls les hôtes prévus portent le rôle de DC ; tout serveur « surpris » doit être retiré.
- Audit des comptes de service : SPN uniquement sur gMSA ou comptes serviciels sans privilèges étendus.
- Durée de vie des tickets : évitez les durées excessives ; dosez en fonction des contraintes applicatives.
- KRBTGT double rotation : en cas de suspicion de compromission, deux rotations successives du secret krbtgt pour invalider les TGT forgés.
Scénarios d’attaque et parades
| Scénario | Vecteur | Détection | Parades |
|---|---|---|---|
| Abus de délégation via un serveur membre mal configuré | Machine « Trusted for delegation » hors DC | Audit LDAP des userAccountControl ≠ DC | Retirer le flag, basculer en KCD/RBCD, gMSA |
| Rejeu de tickets depuis un DC compromis | Exfiltration de TGT/TGS, S4U abusif | Pic 4768/4769, accès anormal à des SPN | Tier 0, LSASS PPL, FAST, rotation krbtgt, EDR |
| Élévation via modification RBCD | Écriture msDS-AllowedToActOnBehalfOfOtherIdentity | Événements 5136 sur l’attribut, corrélation admin | Contrôle de changement, permissions minimales, surveillance |
Foire aux questions
Un DC sans « Trusted for delegation », est‑ce possible ?
Non pour un DC complet ; c’est structurel. Si vos contraintes l’exigent, déployez un RODC.
Mettre les applications sur un DC : acceptable ?
Non. Les DC ne doivent héberger aucune application métiers ; c’est une règle d’hygiène et de réduction de surface d’attaque.
La délégation non restreinte sur des serveurs membres : jamais ?
Évitez absolument ; utilisez KCD/RBCD. Les rares cas hérités doivent être traités en priorité de remédiation.
Réduire la durée des tickets casse‑t‑il les applis ?
Pas en général si l’on reste dans des valeurs raisonnables (ex. TGT 4 h/TGS 8 h). Testez sur un pilote avant déploiement global.
RODC partout ?
Non. Un RODC est adapté aux sites non sécurisés. Sur les datacenters et cœurs de réseau, conservez des DC complets.
Plan d’action en dix jours
- J1–J2 : inventaire DC/RODC/SPN, identification des machines « Trusted for delegation » hors DC.
- J3–J4 : mise en place de l’audit 4768/4769, tableaux de bord et alertes.
- J5–J6 : bascule des serveurs fautifs vers KCD/RBCD, conversion des comptes de service en gMSA, AES‑only.
- J7 : activation FAST en mode Supported sur DC + clients pilotes.
- J8 : LSASS PPL, LDAP signing & channel binding, revue des GPO.
- J9–J10 : durées de tickets ajustées, documentation, transfert aux opérations.
En résumé
La délégation non restreinte fait partie intégrante du rôle de contrôleur de domaine. On ne peut pas la désactiver sans rendre Kerberos inopérant. La bonne stratégie consiste à réduire l’exposition des DC (tiering, durcissements, patch), à protéger les identités (Protected Users, APS, comptes non déléguables), à durcir Kerberos (FAST, AES‑only, tickets courts), à déployer des RODC sur les sites à risque et à surveiller activement toute activité de délégation anormale. Pour les applications, remplacez la délégation non restreinte par KCD ou RBCD correctement gouvernés. C’est cette défense en profondeur qui neutralise l’impact d’une éventuelle compromission tout en maintenant la disponibilité d’Active Directory.
Annexes : commandes utiles
# Exporter les délégations KCD d'un compte de service
Get-ADUser svc_app -Properties msDS-AllowedToDelegateTo |
Select-Object Name,@{n='KCD';e={$_."msDS-AllowedToDelegateTo"}}
# Lister les objets avec RBCD configurée
Get-ADComputer -Filter * -Properties PrincipalsAllowedToDelegateToAccount |
Where-Object { $_.PrincipalsAllowedToDelegateToAccount } |
Select-Object Name,PrincipalsAllowedToDelegateToAccount
# Activer l'audit Kerberos
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable Dernière vérification du périmètre fonctionnel : 29 septembre 2025.