Délégation contrainte et RBCD en toute sécurité dans AD

Une fois la délégation non contrainte supprimée, la délégation qui subsiste est de type délimité : la délégation Kerberos contrainte (KCD) et la délégation contrainte basée sur les ressources (RBCD). Toutes deux sont légitimes et souvent nécessaires. Toutes deux deviennent aussi des primitives d'usurpation d'identité lorsqu'elles sont configurées de façon laxiste ou que les mauvaises personnes peuvent les modifier. Les attaquants utilisent des outils comme Rubeus et Impacket pour demander des tickets S4U ; ce guide se concentre sur le versant défensif, c'est-à-dire les choix de configuration et les audits qui déterminent si ces requêtes rapportent quoi que ce soit d'utile.

Il suppose que vous connaissez déjà les trois modèles présentés dans le guide de référence sur la délégation. Nous entrons ici dans les extensions Kerberos qui les sous-tendent, les paramètres qui rendent chacun d'eux risqué et un audit reproductible de qui peut écrire la RBCD sur vos objets ordinateurs.

Comment S4U fait fonctionner la délégation

Les deux modèles délimités reposent sur deux extensions Kerberos, désignées collectivement sous le nom de Service for User (S4U) :

• S4U2Self permet à un service de demander un ticket pour lui-même au nom de n'importe quel utilisateur, sans les identifiants de cet utilisateur. Cette extension existe pour qu'un service puisse connaître les appartenances aux groupes d'un utilisateur.
• S4U2Proxy permet à un service de prendre un ticket qu'il détient pour un utilisateur (le ticket « de preuve ») et de l'échanger contre un ticket vers un service différent, toujours sous l'identité de cet utilisateur.

Le KDC contrôle S4U2Proxy au regard de la configuration de délégation : msDS-AllowedToDelegateTo sur le frontal pour la KCD, ou msDS-AllowedToActOnBehalfOfOtherIdentity sur le service dorsal pour la RBCD. Deux détails déterminent le degré de dangerosité d'une configuration donnée.

La transition de protocole

Avec une KCD « Kerberos only », S4U2Proxy ne réussit que si le ticket de preuve est transférable (forwardable), ce qui signifie en pratique que l'utilisateur s'est réellement authentifié en Kerberos auprès du frontal. Avec « Use any authentication protocol » (l'indicateur TRUSTED_TO_AUTH_FOR_DELEGATION, 0x1000000), le frontal peut obtenir un ticket transférable pour n'importe quel utilisateur par le seul biais de S4U2Self. L'utilisateur n'a jamais besoin de se présenter.

Autrement dit, quiconque contrôle un compte frontal doté de la transition de protocole peut usurper à tout moment l'identité de n'importe quel utilisateur non protégé, Domain Admins compris, auprès de chaque SPN de sa liste d'autorisation. La transition de protocole est nécessaire pour l'authentification par formulaire, l'ouverture de session par certificat ou carte à puce gérée par l'application, et certaines passerelles SSO. Elle n'est pas nécessaire pour un site intranet utilisant l'authentification Windows intégrée.

La RBCD et les tickets transférables

Pour la RBCD, le KDC accepte un ticket de preuve non transférable dès lors que le service dorsal fait confiance au frontal. Un attaquant qui contrôle n'importe quel compte doté d'un SPN (un compte d'ordinateur qu'il a créé suffit) et qui peut écrire la RBCD sur un ordinateur cible peut donc usurper l'identité d'utilisateurs auprès de cette cible. C'est pourquoi l'hygiène de la RBCD porte essentiellement sur les autorisations d'écriture, et pourquoi ms-DS-MachineAccountQuota compte autant ici.

La substitution du nom de service

Le SPN d'un ticket de service n'est pas protégé par le chiffrement du ticket. Un ticket émis pour cifs/fs01 est tout aussi valable pour host/fs01, http/fs01 ou ldap/fs01 si ces services s'exécutent sous le même compte — et sur un compte d'ordinateur, c'est le cas de tous. Délimitez en conséquence : une entrée qui pointe vers un service quelconque d'un contrôleur de domaine équivaut en pratique à une délégation vers l'ensemble du DC.

Mesurer : inventorier la délégation délimitée

Collectez les deux modèles dans chaque domaine, y compris l'indicateur de transition de protocole.

Import-Module ActiveDirectory

# KCD : comptes frontaux dotés de msDS-AllowedToDelegateTo
Get-ADObject -LDAPFilter '(msDS-AllowedToDelegateTo=*)' `
    -Properties samAccountName, objectClass, msDS-AllowedToDelegateTo, userAccountControl |
    Select-Object samAccountName, objectClass,
        @{n='ProtocolTransition';e={[bool]($_.userAccountControl -band 0x1000000)}},
        @{n='Targets';e={$_.'msDS-AllowedToDelegateTo' -join '; '}}

# RBCD : ressources dorsales et comptes autorisés à leur déléguer
Get-ADComputer -LDAPFilter '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)' `
    -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object Name,
        @{n='AllowedFrom';e={$_.PrincipalsAllowedToDelegateToAccount -join '; '}}

PrincipalsAllowedToDelegateToAccount est la vue lisible, fournie par le module ActiveDirectory, du descripteur de sécurité msDS-AllowedToActOnBehalfOfOtherIdentity : inutile de l'analyser à la main. La RBCD peut aussi être définie sur des comptes utilisateurs et de service ; pour une couverture complète, exécutez le même filtre avec Get-ADObject.

Signalez comme critiques :

• Toute cible KCD ou ressource RBCD qui est un contrôleur de domaine, un serveur AD CS ou un autre actif Tier 0.
• Tout frontal doté de la transition de protocole sans que ce besoin soit documenté.
• Toute entrée RBCD qui pointe vers un compte d'ordinateur créé par un utilisateur ordinaire (vérifiez mS-DS-CreatorSID sur le frontal).
• Toute délégation configurée sur un compte utilisateur à mot de passe statique.

Auditer : qui peut écrire la RBCD

Une entrée RBCD connue ne représente que la moitié du tableau. L'autre moitié, c'est qui pourrait en ajouter une demain. Recherchez les droits suivants sur les objets ordinateurs, en particulier les serveurs et les machines Tier 0 :

• GenericAll, GenericWrite, WriteDacl ou WriteOwner sur l'objet, ou sa propriété.
• WriteProperty sur toutes les propriétés, ou sur l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity (schemaIDGUID 3f78c3e5-f79a-46bd-a0b8-9d18116ddc79).
• WriteProperty sur le jeu de propriétés Account Restrictions (4c164200-20c0-11d0-a768-00aa006e0529), couramment accordé au compte qui a joint une machine au domaine et qui inclut cet attribut.

$rbcdAttr   = [guid]'3f78c3e5-f79a-46bd-a0b8-9d18116ddc79'
$acctRestr  = [guid]'4c164200-20c0-11d0-a768-00aa006e0529'
$expected   = 'NT AUTHORITY\\SYSTEM|\\Domain Admins$|\\Enterprise Admins$|BUILTIN\\Administrators|\\Key Admins$|\\Enterprise Key Admins$|NT AUTHORITY\\SELF'

Get-ADComputer -Filter * -SearchBase 'OU=Servers,DC=corp,DC=example,DC=com' |
    ForEach-Object {
        $dn  = $_.DistinguishedName
        $acl = Get-Acl -Path "AD:\$dn"
        $acl.Access | Where-Object {
            $_.AccessControlType -eq 'Allow' -and
            $_.IdentityReference -notmatch $expected -and (
                $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner' -or
                ($_.ActiveDirectoryRights -match 'WriteProperty' -and
                 $_.ObjectType -in @([guid]::Empty, $rbcdAttr, $acctRestr))
            )
        } | Select-Object @{n='Computer';e={$dn}}, IdentityReference, ActiveDirectoryRights, ObjectType, IsInherited
    } | Export-Csv .\rbcd-writers.csv -NoTypeInformation

Examinez aussi $acl.Owner pour chaque objet : un propriétaire peut toujours réécrire la DACL. Les ACE héritées révèlent une délégation trop large au niveau des UO ; corrigez-les au niveau de l'UO plutôt qu'objet par objet. Pour une vue en graphe de l'ensemble du domaine, le guide sur la gestion des chemins d'attaque montre comment interroger les mêmes relations dans BloodHound.

Notez l'exclusion de SELF ci-dessus. Dans les configurations par défaut, un compte d'ordinateur peut écrire la RBCD sur son propre objet : c'est sans danger en soi, mais c'est exactement ce qu'exploitent des chaînes de relais comme KrbRelayUp, qui relaient l'authentification de la machine vers LDAP et écrivent la RBCD en tant que machine. La correction ne passe pas par une modification d'ACL, mais par la signature LDAP et la liaison de canal sur chaque DC.

Imposer : configurer la délégation délimitée en toute sécurité

KCD « Kerberos only »

Lorsque les utilisateurs atteignent le frontal en Kerberos, utilisez la KCD sans transition de protocole, avec la plus petite liste de SPN qui fonctionne.

Set-ADComputer -Identity WEB01 -Replace @{
    'msDS-AllowedToDelegateTo' = @('MSSQLSvc/sql01.corp.example.com:1433','MSSQLSvc/sql01.corp.example.com')
}
Set-ADAccountControl -Identity (Get-ADComputer WEB01) -TrustedToAuthForDelegation $false

Si la transition de protocole est réellement nécessaire, exécutez le frontal sous un gMSA, placez-le dans un tier dédié, restreignez l'administration locale de ses hôtes et assurez-vous que la liste des SPN ne contient aucun DC, serveur AD CS ou serveur de gestion.

RBCD

Définissez la RBCD avec le paramètre dédié pour que le descripteur de sécurité soit bien formé, et préférez un groupe lorsque plusieurs frontaux ont besoin d'accès, afin que les changements portent sur l'appartenance et non sur le descripteur.

$front = Get-ADGroup 'GG-SQL01-Delegation-Frontends'
Set-ADComputer -Identity SQL01 -PrincipalsAllowedToDelegateToAccount $front

Effacez les entrées obsolètes avec Set-ADComputer -Identity <name> -PrincipalsAllowedToDelegateToAccount $null.

Protéger les identités qui ne doivent jamais être usurpées

Chaque compte Tier 0 doit être dans Protected Users ou porter l'indicateur « Account is sensitive and cannot be delegated ». Dans les deux cas, le KDC refuse les tickets S4U pour ces utilisateurs, ce qui neutralise la plupart des abus de délégation même lorsqu'un frontal est compromis. Définissez également l'indicateur NOT_DELEGATED, y compris sur le compte Administrator intégré et sur les comptes bris de glace qui pourraient ne pas être dans Protected Users : il est appliqué par le KDC indépendamment de l'appartenance aux groupes et survit à un nettoyage accidentel des groupes. Maintenez les DC à jour pour CVE-2020-17049 (le problème Bronze Bit), qui permettait à un frontal compromis de contourner ces deux protections en altérant l'indicateur forwardable.

Vérifier

• Relancez l'inventaire. Chaque entrée KCD et RBCD correspond à une demande de changement et à un responsable ; aucune entrée ne cible un hôte Tier 0.

• Relancez l'audit des droits d'écriture sur les UO de serveurs et Tier 0. Les seuls rédacteurs non standard sont des groupes de provisionnement documentés.

• Confirmez que les comptes privilégiés portent NOT_DELEGATED ou appartiennent à Protected Users. Cette requête ne doit rien renvoyer :

  PowerShell

  # Protected Users a le RID 525 ; les membres imbriqués comptent aussi
  $protected = (Get-ADGroupMember -Identity "$((Get-ADDomain).DomainSID)-525" -Recursive).SID.Value
  Get-ADUser -Filter 'AccountNotDelegated -eq $false' -SearchBase '<admin OU>' |
      Where-Object { $_.SID.Value -notin $protected }

• Activez une SACL sur les écritures de msDS-AllowedToActOnBehalfOfOtherIdentity et msDS-AllowedToDelegateTo à la racine du domaine (audit Directory Service Changes) et déclenchez une alerte sur l'événement 5136 pour l'un ou l'autre attribut.

• Sur les DC, l'événement 4769 comporte un champ Transited Services renseigné pour les requêtes S4U2Proxy. Établissez une référence des frontaux qui y apparaissent ; un nouveau venu mérite une investigation. La référence des ID d'événements liste les autres champs utiles à collecter.

Ce que cela casse

• Supprimer la transition de protocole casse les applications qui authentifient les utilisateurs par formulaire, par certificats clients gérés dans l'application ou par des revendications issues d'un IdP externe, puis appellent un service dorsal Kerberos. Elles échouent au second saut avec des erreurs d'accès anonyme ou refusé.
• Réduire les listes de SPN casse l'accès par alias : si les utilisateurs atteignent sql01 par son nom court et que seul le SPN FQDN est listé, la délégation échoue. Incluez les deux formes lorsque les clients utilisent les deux.
• Ajouter les administrateurs à Protected Users ou leur appliquer NOT_DELEGATED signifie qu'ils ne peuvent plus utiliser sous leur propre identité les applications qui délèguent, comme les consoles Web qui interrogent des services dorsaux avec l'identité de l'utilisateur. Ils doivent utiliser un compte standard pour ces outils.
• Resserrer la délégation sur les UO retire aux comptes du support ou de déploiement la possibilité de modifier des attributs d'ordinateurs qu'ils manipulaient jusque-là, ce qui peut casser les scripts de réinstallation qui réinitialisent ou réécrivent les objets ordinateurs.

Pour aller plus loin : la thématique Délégation, l'entrée du glossaire délégation contrainte basée sur les ressources, et l'audit des ACL Active Directory pour la revue plus large des autorisations dont cet audit fait partie.