ACE Dangereuses SID Orphelins Inter-Domaines Active Directory : l'abus ACL que la plupart des outils ne savent même pas résoudre

Un audit ACE dangereuses SID orphelins inter-domaines Active Directory pose une question qu'une revue ACL standard n'atteint jamais : quelles autorisations de votre annuaire sont détenues par des trustees que personne ne peut nommer ? Chaque entrée de contrôle d'accès (ACE) dans une DACL AD identifie son trustee par un identifiant de sécurité (SID), et l'outillage de revue résout presque toujours ce SID en un nom lisible avant de vous l'afficher. Mais que se passe-t-il quand le SID ne résout vers rien du tout — et que l'ACE dans laquelle il se trouve accorde le contrôle total ?

C'est une question différente de celle que pose une revue normale. Une revue normale demande « quels comptes actifs détiennent GenericAll sur le Tier 0 ? ». Celle-ci demande « quelles autorisations sont détenues par des trustees que mon annuaire ne peut pas nommer ? ». Les deux produisent des constats complètement différents, et le second est systématiquement ignoré : une entrée dont le trustee ne résout pas est facile, pour un rapport, à rendre sous forme de ligne vide, de chaîne brute, ou de rien du tout.

Ce que vérifie un audit ACE dangereuses SID orphelins inter-domaines Active Directory

Un SID n'est pas un nom. La référence Microsoft Security Identifiers décrit précisément la structure : pour un compte de domaine, « le SID d'un principal de sécurité est créé en concaténant le SID du domaine avec un identifiant relatif (RID) pour le compte ». Tout ce qui précède le segment final -RID est l'identifiant de domaine ; le dernier segment identifie le principal à l'intérieur de ce domaine.

C'est cette structure qui rend une référence cassée classifiable. Prenez un SID de trustee qui ne résout vers aucun utilisateur, groupe, ordinateur, unité d'organisation ou principal bien connu, et comparez son préfixe de domaine à votre propre SID de domaine :

Cette distinction compte à cause d'une garantie que Microsoft énonce explicitement dans la même référence : « Les SID restent toujours uniques. Les autorités de sécurité n'émettent jamais deux fois le même SID, et elles ne réutilisent jamais les SID des comptes supprimés. » Un SID local orphelin ne peut donc pas être ré-acquis en créant un nouveau compte portant le même nom — le nouveau compte obtient un nouveau RID. C'est réellement rassurant, et c'est pour cela que ce cas n'est pas une alerte maximale.

Le cas inter-domaines n'offre pas une telle garantie, car le principal peut simplement exister quelque part que vous ne pouvez pas voir. Une autorisation inter-domaines légitime se matérialise normalement dans votre annuaire sous forme d'un objet Foreign-Security-Principal — « le principal de sécurité provenant d'une source externe ». Si aucun foreignSecurityPrincipal correspondant n'existe, vous êtes soit face à une autorisation intentionnelle dont l'objet compagnon n'a jamais été créé, soit face à un reliquat d'une approbation qui a depuis été supprimée ou reconfigurée.

Les droits qui rendent un trustee non résolvable dangereux

Toutes les ACE avec un trustee cassé ne comptent pas. Celles qui comptent portent des droits qui permettent à leur détenteur de prendre le contrôle de l'objet. La référence Microsoft ADS_RIGHTS_ENUM donne les bits exacts :

Il y a ici un piège qui ruine silencieusement les scripts d'audit maison. Les bits génériques ci-dessus sont les valeurs ADSI brutes. L'énumération .NET ActiveDirectoryRights que PowerShell expose utilise à la place les valeurs mappées du service d'annuaire : GenericAll vaut 983551 (0xF01FF), pas 0x10000000. Et 0xF01FF est un composite qui inclut ReadProperty (16) et ListChildren (4).

Un script qui écrit $ace.ActiveDirectoryRights -band 'GenericAll' et traite un résultat non nul comme un contrôle total va donc signaler pratiquement toutes les ACE de lecture de l'annuaire. Le test correct est un test d'égalité contre le masque complet, plus des vérifications séparées pour les bits génériques bruts et les droits d'écriture standard :

$mask = [int]$ace.ActiveDirectoryRights
$isDangerous =
    (($mask -band 0x10000000) -ne 0) -or          <# ADS_RIGHT_GENERIC_ALL   #>
    (($mask -band 0x40000000) -ne 0) -or          <# ADS_RIGHT_GENERIC_WRITE #>
    (($mask -band 0x000F01FF) -eq 0x000F01FF) -or <# contrôle total (mappé)  #>
    (($mask -band 0x00040000) -ne 0) -or          <# WRITE_DAC               #>
    (($mask -band 0x00080000) -ne 0)              <# WRITE_OWNER             #>

Microsoft en a lui-même livré un exemple

La preuve la plus convaincante que les références SID cassées sont une condition systémique plutôt qu'une curiosité vient de la documentation Microsoft elle-même sur ce que adprep /domainprep fait à votre annuaire.

La référence Active Directory domain-wide schema updates liste les opérations effectuées lors de la préparation d'un contrôleur de domaine Windows Server 2016. L'opération 85 est décrite comme modifiant le contexte de nommage du domaine « pour permettre à domain\Key Admins et rootdomain\Enterprise Key Admins de modifier l'attribut msds-KeyCredentialLink ». La colonne des permissions enregistre ensuite ce qui s'est réellement passé :

(OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Key Admins)
(OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Enterprise Key Admins in root
 domain, but in nonroot domains resulted in a bogus domain-relative ACE with a
 nonresolvable -527 SID)

Relisez cette dernière clause. Microsoft documente que dans chaque domaine non-racine d'une forêt multi-domaines, cette opération a laissé derrière elle une ACE dont le trustee est un SID non résolvable. Enterprise Key Admins est un groupe au niveau forêt qui vit dans la racine de la forêt ; l'opération a construit le SID relativement au domaine local, produisant une référence -527 vers un principal que ce domaine ne possède pas.

Deux autres opérations nettoient ensuite derrière elle — et elles ne sont pas livrées ensemble, ce qui détermine si votre domaine a reçu l'un des correctifs ou les deux. L'opération 87 se trouve dans la même table Windows Server 2016 (opérations 82-88, après lesquelles l'attribut revision sur CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System est fixé à 15) ; elle supprime « l'ACE accordant le contrôle total au groupe Enterprise Key Admins domain-relative incorrect » et en ajoute une correcte. L'opération 89 est listée dans une table différente — les mises à jour Windows Server (Semi-Annual Channel) à l'échelle du domaine, qui font passer ce même attribut revision à 16 — et elle va plus loin, en supprimant l'entrée large (A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;Enterprise Key Admins) et en la remplaçant par (OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Enterprise Key Admins) — le contrôle total sur le contexte de nommage, restreint à un accès en écriture sur un seul attribut. C'est cette valeur de revision qui indique lequel des deux nettoyages votre domaine a réellement reçu.

Ces chaînes SDDL se décodent via la référence Microsoft ACE Strings : A est une ACE d'autorisation d'accès, OA une ACE spécifique à un objet, CI la marque comme héritable par les conteneurs, et RPWPCRLCLOCCDCRCWDWOSDDTSW concatène read property, write property, control access, list children, list object, create child, delete child, read control, write DAC, write owner, delete, delete tree et self-write. C'est le contrôle total sous un autre nom — y compris les deux droits qui permettent à un détenteur de réécrire la DACL et de s'emparer de la propriété.

🚨 Danger : si votre forêt a été préparée avec les médias Windows Server 2016 d'origine et que les opérations de nettoyage ultérieures n'ont jamais été exécutées, une ACE -527 accordant des droits étendus sur tout un contexte de nommage de domaine peut encore se trouver dans un domaine enfant, pointant vers rien.

Pourquoi les deux cas n'ont pas le même poids

Un SID local orphelin et un SID inter-domaines se ressemblent dans une DACL — un trustee non résolvable — mais ils méritent des priorités différentes.

SID local orphelin. Personne ne peut exercer cette autorisation via une connexion normale. Comme AD ne recycle pas les RID, récupérer le SID exact nécessiterait de l'injecter dans le sIDHistory d'un compte, ce qui présuppose déjà l'accès privilégié que l'attaquant chercherait à obtenir grâce à cette autorisation. C'est un élément de nettoyage et un problème de piste d'audit, pas un chemin actif. Le laisser en l'état lui permettra de survivre à l'incident qui l'a créé, élargissant silencieusement le rayon d'impact de toute future migration.

SID inter-domaines. Celui-ci est actif si le domaine référencé devient un jour accessible. La documentation Microsoft sur le SID filtering énonce clairement le mécanisme : « dans certaines circonstances, il est possible pour des attaquants ou des administrateurs malveillants ayant compromis un contrôleur de domaine dans un domaine approuvé d'utiliser l'attribut SID history (sIDHistory) pour associer des SID à de nouveaux comptes utilisateur, s'octroyant ainsi des droits non autorisés. » L'évaluation de la posture des comptes de Microsoft Defender for Identity reformule la version au niveau forêt : « Si vous avez une approbation de forêt sans SID Filtering activé (aussi appelé Quarantine), il est possible d'injecter un SID d'une autre forêt, qui sera ajouté au jeton utilisateur lors de l'authentification et utilisé pour les évaluations d'accès. »

Mises bout à bout, une ACE inter-domaines obsolète devient une autorisation pré-positionnée. Un attaquant qui contrôle — ou rétablit plus tard — le domaine référencé n'a besoin de modifier aucunement votre DACL. L'autorisation est déjà écrite. Il lui faut seulement un jeton portant ce SID. C'est le même raisonnement sur les frontières de confiance que celui couvert dans Attaques sur les approbations Active Directory et l'audit du filtrage SID et de l'authentification sélective des approbations ; la différence est qu'ici l'autorisation survit à la suppression de l'approbation, car supprimer une approbation ne nettoie pas les ACL.

Deux autres droits dans le même angle mort

Les références SID cassées partagent un angle mort avec deux autres schémas de permissions que les revues standard ignorent pour une raison différente : ce ne sont pas des GenericAll, donc les audits fondés sur des mots-clés ne les voient jamais.

Auto-appartenance sur les groupes. L'écriture validée Self-Membership, GUID bf9679c0-0de6-11d0-a285-00aa003049e2, est documentée comme « permission d'écriture validée permettant de mettre à jour l'appartenance d'un groupe en ajoutant/retirant son propre compte ». Son nom d'affichage dans l'éditeur ACL est Add/Remove self as member, et elle ne s'applique qu'à la classe Group. Accordée sur un groupe privilégié, c'est une escalade en une seule étape qui n'implique jamais qu'un tiers écrive member — le principal s'ajoute lui-même. La référence Microsoft Dsacls confirme le périmètre : la permission WS n'a « de sens que sur les objets de groupe et lorsque {ObjectType | Property} est 'member' ». C'est cette famille de droits qui rend l'imbrication dangereuse de groupes pire qu'il n'y paraît.

Enterprise Key Admins sur msDS-KeyCredentialLink. Selon Active Directory security groups, Enterprise Key Admins porte le RID bien connu 527, est un groupe Global dans CN=Users, n'a aucun membre par défaut, et est protégé par AdminSDHolder. L'attribut qu'il régit, msDS-KeyCredentialLink (schemaIdGuid 5b47d60f-6090-40b2-9f37-2a4de88f3063), « contient du matériel de clé et des informations d'usage » et a été « implémenté pour la première fois sur Windows Server 2016 ».

L'accès en écriture à cet attribut constitue à lui seul toute l'attaque Shadow Credentials. Dans la recherche originale Shadow Credentials d'Elad Shamir : « si vous pouvez écrire dans la propriété msDS-KeyCredentialLink d'un utilisateur, vous pouvez obtenir un TGT pour cet utilisateur » et « vous pouvez récupérer le hash NT de cet utilisateur ». Les prérequis sont un contrôleur de domaine Windows Server 2016, un certificat Server Authentication sur celui-ci, et un niveau fonctionnel Windows Server 2016 — et le credential implanté « persisterait même si l'utilisateur/ordinateur changeait son mot de passe ». Nous couvrons la technique elle-même dans Shadow Credentials : abus de msDS-KeyCredentialLink.

La question d'audit est plus étroite que l'attaque. Enterprise Key Admins est livré vide. Ce que vous vérifiez, c'est si l'ACE du groupe sur votre contexte de nommage de domaine est le RPWP restreint sur 5b47d60f-… que l'opération 89 installe, ou l'entrée de contrôle total non restreinte laissée par la préparation d'origine — et si le trustee résout réellement.

Détection

Auditer ce risque nécessite deux passes : un balayage ponctuel des DACL existantes, et un audit des changements pour que les nouvelles références cassées soient détectées dès leur apparition.

Balayer les DACL existantes à la recherche de trustees dangereux non résolvables

Demandez les SID bruts plutôt que les noms de compte. Demander d'emblée des objets NTAccount à .NET lève une exception précisément sur les entrées que vous recherchez : SecurityIdentifier.Translate lève IdentityNotMappedException lorsque « certaines ou toutes les références d'identité n'ont pas pu être traduites ».

Import-Module ActiveDirectory

$domainSid = (Get-ADDomain).DomainSID.Value
$root      = (Get-ADRootDSE).defaultNamingContext

Get-ADObject -SearchBase $root -LDAPFilter '(objectClass=*)' -Properties nTSecurityDescriptor |
  ForEach-Object {
    $dn = $_.DistinguishedName
    $_.nTSecurityDescriptor.GetAccessRules(
        $true, $true, [System.Security.Principal.SecurityIdentifier]) |
      Where-Object { $_.AccessControlType -eq 'Allow' } |
      ForEach-Object {
        $mask = [int]$_.ActiveDirectoryRights
        $dangerous =
            (($mask -band 0x10000000) -ne 0) -or
            (($mask -band 0x40000000) -ne 0) -or
            (($mask -band 0x000F01FF) -eq 0x000F01FF) -or
            (($mask -band 0x00040000) -ne 0) -or
            (($mask -band 0x00080000) -ne 0)
        if (-not $dangerous) { return }

        $sid = $_.IdentityReference
        try {
            $null = $sid.Translate([System.Security.Principal.NTAccount])
            return
        } catch [System.Security.Principal.IdentityNotMappedException] { }

        $scope = if ($sid.Value.StartsWith("$domainSid-")) {
                     'Orphaned local SID'
                 } else {
                     'Cross-domain SID'
                 }

        [pscustomobject]@{
            ObjectDN = $dn
            Trustee  = $sid.Value
            Rights   = $_.ActiveDirectoryRights
            Scope    = $scope
        }
      }
  } | Sort-Object Scope, ObjectDN | Format-Table -AutoSize

Exécutez d'abord ce script sur une seule OU. Un balayage complet du contexte de nommage lit chaque descripteur de sécurité du domaine, et ce n'est pas quelque chose à lancer sur un DC de production pendant les heures ouvrées.

Vérifier les deux schémas spécifiques

Les deux requêtes ci-dessous demandent des trustees SecurityIdentifier pour la même raison que le balayage : la propriété .Access traduit vers NTAccount et lève IdentityNotMappedException précisément sur les ACE qui font l'objet de cet article.

$root    = (Get-ADRootDSE).defaultNamingContext
$sidType = [System.Security.Principal.SecurityIdentifier]

<# Key Admins (-526) et Enterprise Key Admins (-527) sur le NC du domaine :
   restreint, ou contrôle total ? Faites correspondre sur le RID, pas sur le
   nom — dans un domaine non-racine, le trustee erroné est précisément celui
   qui ne résoudra pas vers "Key Admins", donc un filtre sur le nom manque
   silencieusement le constat. #>
(Get-ADObject $root -Properties nTSecurityDescriptor).nTSecurityDescriptor.GetAccessRules(
    $true, $true, $sidType) |
  Where-Object { $_.IdentityReference.Value -match '-52[67]$' } |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

<# Autorisations d'auto-appartenance sur les groupes : l'écriture validée, ou un DS_SELF non restreint #>
$selfMembership = [guid]'bf9679c0-0de6-11d0-a285-00aa003049e2'
Get-ADGroup -Filter * -Properties nTSecurityDescriptor | ForEach-Object {
    $g = $_
    $g.nTSecurityDescriptor.GetAccessRules($true, $true, $sidType) |
      Where-Object {
        $_.AccessControlType -eq 'Allow' -and (
          $_.ObjectType -eq $selfMembership -or
          ($_.ObjectType -eq [guid]::Empty -and
           ([int]$_.ActiveDirectoryRights -band 0x8) -ne 0)
        )
      } |
      Select-Object @{n='Group';e={$g.DistinguishedName}},
                    IdentityReference, ActiveDirectoryRights
}

Un ObjectType de 5b47d60f-6090-40b2-9f37-2a4de88f3063 sur la première requête est la forme restreinte et attendue. Un ObjectType vide avec un masque de contrôle total est l'entrée non restreinte qui aurait dû être remplacée — et un trustee -527 que vous ne pouvez faire correspondre à aucun groupe Enterprise Key Admins actif est le cas non résolvable lui-même.

Détecter les nouvelles occurrences à leur apparition

La référence Microsoft de l'événement 5136 expose les prérequis et les règles de lecture. L'événement appartient à la sous-catégorie Audit Directory Service Changes, et « pour générer cet événement, l'objet modifié doit avoir une entrée appropriée dans la SACL : l'audit de l'action 'Write' pour des attributs spécifiques » — activer seulement la sous-catégorie ne suffit pas, la SACL doit exister sur les objets qui vous intéressent.

Attendez-vous à des paires, pas à des occurrences isolées : « pour une opération de changement, vous verrez généralement deux événements 5136 pour une seule action, avec des champs Operation Type différents : 'Value Deleted' puis 'Value Added' ». La recommandation même de Microsoft est d'alerter sur l'événement Value Added et d'utiliser le Correlation ID pour récupérer la valeur précédente depuis son événement jumeau.

Un détail de cette même page fait aussi office de diagnostic pour tout cet article : « Event Viewer essaie automatiquement de résoudre les SID et d'afficher le nom du compte. Si le SID ne peut pas être résolu, vous verrez les données source dans l'événement. » Un SID brut là où vous attendiez un nom, voilà l'indice révélateur — dans un événement, comme dans un rapport ACL.

Remédiation

1. Confirmez que le nettoyage adprep a été exécuté. Dans chaque domaine non-racine, inspectez la DACL du NC de domaine à la recherche d'ACE dont le trustee se termine par -527. Si vous trouvez une entrée de contrôle total — surtout une qui ne résout pas — vous êtes face à l'état pré-opération-87/89. L'attribut revision sur CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System indique jusqu'où la préparation est allée : 15 signifie que les opérations 82-88 sont terminées, 16 signifie que l'opération 89 l'est aussi.

2. Classifiez avant de supprimer. Pour chaque trustee non résolvable, comparez le préfixe de domaine à votre SID de domaine et aux SID de chaque domaine que vous approuvez. Un SID inter-domaines correspondant à un partenaire d'approbation actuel est probablement une autorisation intentionnelle dont l'objet foreignSecurityPrincipal manque, et le supprimer cassera quelque chose. Un SID qui ne correspond à aucune approbation actuelle est une référence obsolète.

3. Supprimez par SID, pas par nom. C'est là que l'outillage vous résiste. La référence Microsoft Dsacls documente /R comme prenant un trustee spécifié « sous la forme User@Domain ou Domain\User » — une forme nominale qui, par définition, n'existe pas pour un SID qui ne résout pas. Utilisez PowerShell et transmettez directement un SecurityIdentifier à l'API :

$dn  = 'DC=child,DC=corp,DC=local'
$sid = [System.Security.Principal.SecurityIdentifier]'S-1-5-21-1004336348-1177238915-682003330-527'

$acl = Get-Acl -Path "AD:\$dn"
$acl.GetAccessRules($true, $false, [System.Security.Principal.SecurityIdentifier]) |
  Where-Object { $_.IdentityReference -eq $sid } |
  ForEach-Object { $null = $acl.RemoveAccessRuleSpecific($_) }

Set-Acl -Path "AD:\$dn" -AclObject $acl

Remarquez le $false pour les droits hérités : une ACE héritée ne peut pas être supprimée au niveau de l'enfant, seulement au niveau de l'objet qui la définit. Corrigez le parent et laissez l'héritage se propager.

4. Restaurez le périmètre prévu, ne vous contentez pas de supprimer. Lorsque l'entrée était Enterprise Key Admins sur le NC de domaine, l'état cible est documenté : une ACE objet accordant RPWP restreinte à 5b47d60f-6090-40b2-9f37-2a4de88f3063, héritable par les conteneurs. Supprimer sans remplacer retire une permission que le provisioning Windows Hello for Business attend.

5. Gardez le SID filtering activé — et ne le confondez pas avec le quarantining. Une ACE inter-domaines n'est exploitable que si un SID étranger peut atteindre votre jeton d'accès, et c'est le SID filtering qui l'en empêche. Sur une approbation de forêt, le filtrage est structurel, pas optionnel : MS-PAC précise qu'une approbation inter-forêts « ne permet pas aux SID locaux à sa forêt de traverser une approbation inter-forêts », et que les SID ForestSpecific sont « filtrés pour les frontières d'approbation QuarantinedWithinForest, CrossForest, External et QuarantinedExternal ». Defender for Identity, cité plus haut, traite l'absence de ce filtrage comme le constat. Le SID filter quarantining est un mode distinct, plus strict, et les avertissements de Microsoft ne concernent que lui : ne pas appliquer le quarantining « aux approbations à l'intérieur d'une forêt qui n'utilise pas le niveau fonctionnel de forêt Windows Server 2003, car cela retire des SID requis pour la réplication Active Directory », et il « ne doit pas être appliqué aux approbations de forêt ». Lisez cela comme une instruction concernant le drapeau quarantine — jamais comme une autorisation à désactiver le SID filtering.

6. Placez une SACL sur les objets qui comptent pour vous. L'événement 5136 en a besoin. Au minimum : l'objet NC de domaine, CN=AdminSDHolder,CN=System, CN=Keys, et chaque groupe et OU Tier 0. Auditer les écritures sur nTSecurityDescriptor et msDS-KeyCredentialLink transforme la prochaine occurrence en alerte au lieu d'un constat découvert un an plus tard. L'article AdminSDHolder, la porte dérobée SDProp explique pourquoi ce conteneur en particulier mérite une surveillance permanente.

7. Intégrez cela à la revue récurrente. Les trustees orphelins s'accumulent au fil d'opérations ordinaires — comptes de service décommissionnés, acquisitions closes, approbations retirées. Traitez ce balayage comme un élément de l'audit de sécurité Active Directory permanent, pas comme un projet de remédiation ponctuel.

Comment EtcSec détecte cela

EtcSec répartit le problème des références cassées sur deux checks, précisément parce que les deux cas portent un risque différent. ORPHANED_SID_DANGEROUS_ACE signale les ACE d'autorisation portant GenericAll, contrôle total, WriteDACL, WriteOwner ou GenericWrite à un trustee dont le préfixe de domaine correspond au domaine audité mais qui ne résout vers aucun principal actif — le cas probable de compte supprimé, noté High. CROSS_DOMAIN_SID_DANGEROUS_ACE signale les mêmes droits détenus par un trustee provenant entièrement d'un autre domaine, noté Critical, car cette référence devient exploitable dès l'instant où le domaine référencé redevient accessible. Les deux excluent délibérément les trustees administratifs intégrés et les ACE de refus, afin que le résultat reflète l'exposition et non la forme normale de l'annuaire.

À leurs côtés, ACL_SELF_MEMBERSHIP signale l'écriture validée Add/Remove-self-as-member sur les objets groupe — restreinte aux groupes uniquement, et excluant délibérément le contrôle total pour ne pas simplement re-signaler ce que ACL_GENERICALL a déjà trouvé. ENTERPRISE_KEY_ADMINS_FULL_ACCESS signale le trustee -527 détenant soit un contrôle total non restreint, soit un accès en écriture à msDS-KeyCredentialLink sur les objets de domaine, la condition que les opérations 87 et 89 existent pour corriger. ACL_WRITEDACL et ACL_WRITEOWNER couvrent les deux mêmes droits lorsque le trustee résout effectivement, et TRUST_SID_FILTERING_DISABLED couvre le contrôle côté approbation qui détermine si une référence inter-domaines peut un jour atteindre un jeton.

Combinés aux checks plus larges d'abus ACL et DCSync et à l'audit des permissions DPAPI, tombstone et schéma, ces checks referment l'écart entre « qui détient des droits dangereux » et « quels droits dangereux sont détenus par des principals que personne ne peut nommer ».