Délégation dans AD : repérer et corriger les risques

La délégation Kerberos permet à un service frontal d'agir au nom d'un utilisateur auprès d'un service dorsal — le cas classique est une application Web qui interroge un serveur SQL Server sous l'identité de l'utilisateur connecté plutôt que sous la sienne. C'est une fonctionnalité légitime et parfois nécessaire, mais chacune de ses trois implémentations crée une relation de confiance qui, placée sur le mauvais serveur ou le mauvais compte, offre à un attaquant qui compromet cette seule machine un moyen d'usurper l'identité d'autres utilisateurs, souvent y compris des administrateurs.

Ce guide explique en quoi les trois types de délégation diffèrent, comment inventorier chaque relation de délégation de votre domaine et comment verrouiller les comptes qui ne devraient jamais pouvoir être délégués.

Les trois types de délégation

La délégation non contrainte

Lorsqu'un utilisateur s'authentifie via Kerberos auprès d'un serveur approuvé pour la délégation non contrainte, le client envoie une copie transférée de son TGT avec le ticket de service, et le serveur la met en cache en mémoire. Ce serveur peut désormais rejouer le TGT pour demander des tickets vers n'importe quel service, sous l'identité de cet utilisateur, indéfiniment (jusqu'à l'expiration du TGT). Si un Domain Admin s'authentifie un jour sur cette machine — ne serait-ce que pour parcourir un partage de fichiers —, son TGT reste en mémoire, à la portée du premier venu.

Par défaut, tous les contrôleurs de domaine sont approuvés pour la délégation non contrainte (nécessaire à leur fonctionnement normal). La règle essentielle : aucun serveur autre qu'un contrôleur de domaine ne doit porter cet indicateur. C'était un réglage hérité courant sur les serveurs d'impression, les anciens serveurs IIS et les serveurs d'applications mal configurés, et cela reste l'un des points d'appui les plus précieux qu'un attaquant puisse trouver.

La délégation contrainte

Introduite avec Windows Server 2003, la délégation contrainte limite le frontal à l'usurpation de l'identité des utilisateurs auprès d'une liste explicite de SPN dorsaux, définie via msDS-AllowedToDelegateTo sur le compte frontal. Elle prend également en charge la « transition de protocole » (TRUSTED_TO_AUTH_FOR_DELEGATION), qui permet au frontal d'obtenir un ticket au nom d'un utilisateur même sans saut Kerberos préalable — utile pour les applications Web qui authentifient les utilisateurs par formulaire ou par un autre moyen mais doivent quand même déléguer vers un service dorsal. C'est plus sûr que la délégation non contrainte, mais toujours risqué : quiconque contrôle le compte frontal peut usurper l'identité de n'importe quel utilisateur (administrateurs compris) auprès de chaque service de cette liste d'autorisation.

La délégation contrainte basée sur les ressources (RBCD)

Introduite avec Windows Server 2012, la RBCD inverse l'endroit où la confiance est configurée : au lieu que le frontal déclare où il peut déléguer, c'est la ressource dorsale qui déclare quels comptes frontaux sont autorisés à agir en son nom, via msDS-AllowedToActOnBehalfOfOtherIdentity. C'est plus souple (fonctionne à travers les frontières de domaines/forêts, ne nécessite pas de droits Domain Admin pour la configuration — seulement un accès en écriture à l'objet ordinateur cible), mais cette souplesse est aussi le risque : quiconque dispose de GenericWrite/WriteProperty sur un objet ordinateur peut s'accorder des droits RBCD pour usurper l'identité d'utilisateurs auprès de celui-ci, y compris via les privilèges de création de comptes d'ordinateurs que de nombreux utilisateurs détiennent par défaut (ms-DS-MachineAccountQuota).

Trouver la délégation dans votre domaine

Réalisez un inventaire complet avant de décider quoi corriger. Il doit s'agir d'un audit récurrent, pas d'un exercice ponctuel.

# Délégation non contrainte — ordinateurs et utilisateurs (doit être vide hormis les DC)
Get-ADComputer -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation, servicePrincipalName |
    Select-Object Name, DistinguishedName

Get-ADUser -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation |
    Select-Object Name, DistinguishedName

# Délégation contrainte — comptes dont msDS-AllowedToDelegateTo est renseigné
Get-ADComputer -Filter * -Properties msDS-AllowedToDelegateTo, TrustedToAuthForDelegation |
    Where-Object { $_."msDS-AllowedToDelegateTo" } |
    Select-Object Name, msDS-AllowedToDelegateTo, TrustedToAuthForDelegation

Get-ADUser -Filter * -Properties msDS-AllowedToDelegateTo, TrustedToAuthForDelegation |
    Where-Object { $_."msDS-AllowedToDelegateTo" } |
    Select-Object Name, msDS-AllowedToDelegateTo, TrustedToAuthForDelegation

# Délégation contrainte basée sur les ressources — PrincipalsAllowedToDelegateToAccount est la
# vue décodée, par le module ActiveDirectory, du descripteur msDS-AllowedToActOnBehalfOfOtherIdentity
Get-ADComputer -LDAPFilter '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)' `
    -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object @{n='Computer';e={$_.Name}},
        @{n='DelegatedFrom';e={$_.PrincipalsAllowedToDelegateToAccount -join '; '}}

Tout résultat de délégation non contrainte hors de l'UO Domain Controllers doit être traité comme une non-conformité critique appelant une remédiation immédiate. Pour les résultats de délégation contrainte et RBCD, confrontez chacun à une demande de changement : la délégation doit être documentée, délibérée et revue, et non le vestige d'une preuve de concept oubliée.

Supprimer la délégation indésirable

# Supprimer la délégation non contrainte d'un compte d'ordinateur qui n'est pas un DC
Set-ADComputer -Identity "APP01" -TrustedForDelegation $false

# Supprimer les entrées de délégation contrainte
Set-ADComputer -Identity "APP02" -Clear msDS-AllowedToDelegateTo

# Effacer la RBCD sur une ressource
Set-ADComputer -Identity "SQL01" -Clear msDS-AllowedToActOnBehalfOfOtherIdentity

Protéger les comptes privilégiés : « sensible et ne peut pas être délégué »

Quelle que soit la délégation existant ailleurs dans le domaine, les comptes privilégiés doivent être explicitement exclus de toute délégation à l'aide de l'indicateur NOT_DELEGATED (bit de userAccountControl, présenté comme « Account is sensitive and cannot be delegated » dans ADUC). Cela empêche tout service — même une délégation contrainte configurée légitimement — d'obtenir un ticket permettant d'usurper l'identité de ce compte.

# Appliquer à un compte privilégié
Set-ADAccountControl -Identity "adm-t0-famette" -AccountNotDelegated $true

# Appliquer à chaque membre de Domain Admins et Enterprise Admins
"Domain Admins", "Enterprise Admins" | ForEach-Object {
    Get-ADGroupMember -Identity $_ -Recursive |
        Where-Object { $_.objectClass -eq 'user' } |
        ForEach-Object { Set-ADAccountControl -Identity $_.SamAccountName -AccountNotDelegated $true }
}

Vérifier

Get-ADUser -Identity "adm-t0-famette" -Properties userAccountControl |
    Select-Object Name, @{n='NotDelegated';e={
        [bool]($_.userAccountControl -band 0x100000)
    }}

L'appartenance à Protected Users (traitée dans Tier 0 et accès à privilèges) offre une protection encore plus forte, qui se recoupe avec la précédente : elle bloque purement et simplement NTLM et la délégation non contrainte/contrainte pour le compte, sans qu'il soit nécessaire de définir séparément l'indicateur NOT_DELEGATED, et durcit en outre la durée de vie des tickets Kerberos et les exigences de chiffrement.

Pourquoi la délégation non contrainte sur un serveur qui n'est pas un DC est critique

Cela mérite d'être répété à part, car c'est la mauvaise configuration de délégation la plus lourde de conséquences : un serveur compromis approuvé pour la délégation non contrainte devient un piège à identifiants qui récolte le TGT de chaque administrateur dès que celui-ci s'y connecte — sans qu'il soit nécessaire d'exploiter la machine de l'administrateur. Associé à une sensibilisation des équipes d'infrastructure à la délégation non contrainte, ce point doit figurer en permanence dans toute revue de sécurité AD et être vérifié à chaque provisionnement d'un nouveau serveur, pas seulement lors des audits périodiques.

Ce que cela casse

• Les applications Web qui utilisent la délégation Kerberos pour interroger des bases de données dorsales sous l'identité de l'utilisateur connecté (fréquent avec SharePoint, SSRS et les applications intranet sur mesure) reposent sur la délégation contrainte : supprimer une entrée de msDS-AllowedToDelegateTo sans la remplacer par l'entrée correctement délimitée casse la fonctionnalité « exécuter en tant qu'utilisateur », ce qui oblige l'application à se replier sur le contexte d'un compte de service ou à échouer purement et simplement.
• Les serveurs liés SQL Server configurés pour l'authentification déléguée (plutôt que des identifiants stockés) cessent de fonctionner si les entrées de délégation du compte de service SQL sont effacées ; auditez-les et redéfinissez-les en délégation contrainte avec des SPN explicites plutôt que de les supprimer entièrement.
• Les serveurs d'impression et anciens proxys applicatifs auxquels on avait accordé la délégation non contrainte comme solution générique en dépendaient souvent sans le dire ; retirer l'indicateur peut se traduire par des erreurs intermittentes d'« accès refusé » dans les scénarios de double saut (par exemple un utilisateur qui parcourt un partage via un serveur d'impression devant ensuite s'authentifier plus loin) — testez pendant une fenêtre de maintenance et soyez prêt à reconfigurer en délégation contrainte correctement délimitée.
• La RBCD utilisée pour un accès légitime à des ressources inter-domaines (par exemple un scénario de migration ou une application multiforêt) cassera si elle est effacée sans avoir d'abord reprovisionné la relation dans le cadre d'une gestion des changements documentée.

Pour aller plus loin : Durcissement de Kerberos pour les techniques de falsification de tickets auxquelles les abus de délégation s'enchaînent souvent, et Tier 0 et accès à privilèges pour le tiering des comptes qui tient les comptes de service délégables à l'écart des identifiants Tier 0. Voir aussi DCSync pour ce que fait un attaquant après avoir obtenu le TGT d'un Domain Admin par un abus de délégation.