Filtrage SID Active Directory : authentification sélective, détection et remédiation des approbations

Filtrage SID Active Directory : checklist d'audit de l'authentification sélective des approbations

Un audit du filtrage SID Active Directory et de l'authentification sélective des approbations répond à une seule question : si le domaine ou la forêt à l'autre bout d'une approbation est compromis, jusqu'où un attaquant peut-il progresser dans le vôtre ? Une approbation n'est pas un simple interrupteur on/off — c'est un Trusted Domain Object (TDO) qui porte plusieurs attributs de sécurité indépendants, et chacun peut s'écarter silencieusement d'une configuration par défaut sécurisée au fil de la vie de l'approbation. Cette checklist couvre les trois réglages les plus importants, les commandes exactes pour les vérifier, et comment corriger chaque anomalie sans casser l'authentification des utilisateurs légitimes. Elle s'inscrit dans une revue plus large — voir Auditer la sécurité Active Directory : que vérifier en premier et comment prouver la remédiation pour la place des approbations dans le périmètre complet.

Trois réglages font l'essentiel du travail :

• Le filtrage SID (quarantaine) — empêche un domaine approuvé compromis d'injecter un historique SID forgé pour revendiquer une appartenance à un groupe privilégié de votre côté.
• L'authentification sélective — restreint quels comptes du domaine/forêt approuvé peuvent s'authentifier sur quelles ressources de votre côté, plutôt que de faire confiance à toute la population.
• Le chiffrement de l'approbation — indique si le trafic Kerberos traversant l'approbation peut encore retomber sur RC4, ou s'il est exclusivement AES.

Où vivent réellement ces réglages

Chaque attribut d'approbation vit dans le bitmask trustAttributes du TDO. D'après le champ TrustAttributes documenté pour l'événement de sécurité Windows 4716, les bits les plus importants pour cet audit sont 0x4 (TRUST_ATTRIBUTE_QUARANTINED_DOMAIN — filtrage SID actif), 0x8 (TRUST_ATTRIBUTE_FOREST_TRANSITIVE — approbation inter-forêts) et 0x40 (TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL — assouplit le filtrage d'une approbation de forêt vers les règles d'une approbation externe). L'authentification sélective et les types de chiffrement Kerberos supportés par l'approbation sont stockés séparément, sur l'attribut msDS-SupportedEncryptionTypes du compte d'approbation interdomaine. Ces trois réglages ne dépendent pas les uns des autres — une approbation peut avoir le filtrage SID activé tout en autorisant un chiffrement RC4 seul ou une authentification à l'échelle de la forêt entière, donc chacun nécessite sa propre vérification.

Filtrage SID : vérifier que la quarantaine est réellement active

Le filtrage SID est activé par défaut à la fois sur les approbations externes et les approbations de forêt — il est explicitement désactivé pour les approbations intra-forêt (parent/enfant), où l'historique SID est attendu et digne de confiance. L'anomalie TRUST_SID_FILTERING_DISABLED se déclenche quand la quarantaine a été désactivée sur une approbation inter-forêts ou externe, ce qui résulte presque toujours d'un projet de migration qui l'a désactivée pour préserver l'historique SID et ne l'a jamais réactivée.

Vérifier l'état de la quarantaine

Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SIDFilteringForestAware, SelectiveAuthentication

SIDFilteringQuarantined = $False sur une approbation externe ou de forêt signifie que l'historique SID venant de l'autre côté est accepté sans filtrage — un administrateur compromis dans le domaine approuvé peut forger une entrée d'historique SID revendiquant l'appartenance aux Domain Admins (ou Enterprise Admins) et entrer directement via l'approbation. netdom lit et définit le même attribut :

netdom trust TrustingDomain /domain:TrustedDomain /quarantine
netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes

Corriger sans casser une migration

Authentification sélective : restreindre qui peut s'authentifier

L'authentification sélective se configure du côté sortant d'une approbation externe ou de forêt et restreint l'authentification aux seuls comptes du côté approuvé ayant explicitement reçu le droit étendu Allowed to Authenticate sur les objets ordinateur spécifiques qu'ils doivent atteindre. Sans elle, tout utilisateur authentifié du domaine ou de la forêt approuvé peut tenter de s'authentifier sur n'importe quelle ressource du côté de confiance — Kerberos continuera d'appliquer les ACL au niveau objet, mais la surface d'attaque pour les attaques par identifiants, l'énumération de ressources et le mouvement latéral est considérablement plus large.

L'anomalie TRUST_EXTERNAL_NO_SELECTIVE_AUTH signale les approbations externes fonctionnant sans elle — les approbations externes sont souvent mises en place pour une seule intégration métier (un domaine partenaire, une filiale acquise pas encore fusionnée) et laissées en authentification à l'échelle de la forêt entière parce que personne n'a délimité les octrois « Allowed to Authenticate » lors de la mise en place.

Vérifier l'état de l'authentification sélective

Get-ADTrust -Filter * | Select-Object Name, Direction, SelectiveAuthentication

Une valeur $False sur une approbation externe ou une approbation de forêt à sens unique signifie que l'approbation est grande ouverte à tous les comptes du côté approuvé. Comparez cela au besoin métier réel — si seuls trois comptes de service d'un domaine partenaire doivent atteindre un seul serveur de fichiers, l'authentification sélective plus trois octrois « Allowed to Authenticate » remplacent « tout le domaine partenaire peut atteindre tout » par une liste d'autorisation nommée et auditable.

Chiffrement de l'approbation : RC4 contre AES sur le réseau

L'attribut msDS-SupportedEncryptionTypes du compte d'approbation interdomaine détermine quels types de chiffrement Kerberos sont négociés pour les tickets traversant l'approbation, selon le même bitmask documenté par Microsoft pour les types de chiffrement de compte : 0x4 = RC4 uniquement, 0x18 = AES128 + AES256 uniquement, 0x1C = RC4 plus les deux forces AES. Une valeur 0 (non définie) retombe sur RC4_HMAC_MD5. Pour une vue plus large des endroits où le repli RC4 s'infiltre encore en dehors des approbations, voir Repli Kerberos RC4 dans Active Directory.

Vérifier les types de chiffrement de l'approbation

$trustDN = (Get-ADTrust -Filter {Name -eq "trusted.example.com"}).DistinguishedName
Get-ADObject $trustDN -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

• TRUST_RC4_ONLY se déclenche quand l'attribut résout à 0x4 — chaque ticket de service traversant l'approbation utilise RC4, le type de chiffrement à l'origine de CVE-2022-37966 et de la classe d'attaque Kerberoasting. Microsoft a indiqué prévoir de désactiver RC4 comme type de chiffrement supporté par défaut sur les contrôleurs de domaine d'ici la fin du Q2 2026, donc une approbation RC4 uniquement est aussi un problème de compatibilité future, pas seulement une lacune de durcissement.
• TRUST_AES_DISABLED se déclenche quand les bits AES (0x8/0x10) sont totalement absents de l'attribut — l'approbation n'a jamais été configurée pour AES et dépend de ce que le défaut à l'échelle du domaine résout.

Détection

Détection par journaux d'événements

Pour une vue complète des ID d'événements de sécurité Windows à prioriser au-delà des approbations, voir Supervision Active Directory : les ID d'événements de sécurité qui comptent.

Vérifications de posture PowerShell

# Vérification de posture en une passe sur toutes les approbations
Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SelectiveAuthentication

# Forcer une demande de ticket sur l'approbation et lire le type de chiffrement négocié
klist get HOST/dc01.trusted.example.com

Un résultat klist affichant RC4-HMAC alors que vous attendiez AES256-CTS-HMAC-SHA1-96 confirme que l'approbation négocie encore RC4 en pratique, pas seulement en configuration.

Remédiation du filtrage SID Active Directory et de l'authentification sélective

Durcissement étape par étape

1. Réactiver le filtrage SID sur chaque approbation externe et de forêt qui n'est pas en pleine migration : netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes.
2. Délimiter l'authentification sélective sur les approbations externes et de forêt à sens unique : l'activer du côté sortant, puis octroyer Allowed to Authenticate uniquement sur les objets ordinateur spécifiques dont les comptes du côté approuvé ont réellement besoin — pas sur toute l'OU.
3. Faire migrer les approbations vers AES uniquement : définir msDS-SupportedEncryptionTypes à 0x18 sur le compte d'approbation interdomaine, et appliquer la GPO Network security: Configure encryption types allowed for Kerberos pour restreindre à AES128/AES256 à l'échelle du domaine avant de désactiver RC4 au niveau de l'approbation, afin d'éviter de casser les membres legacy qui ne supportent encore que RC4.
4. Revérifier après la fenêtre de changement : relancer la vérification Get-ADTrust et confirmer que l'ID d'événement 4716 a journalisé la modification attendue, puis surveiller 4768/4769 pendant quelques jours pour confirmer l'absence d'échecs d'authentification inattendus depuis des appareils qui avaient encore besoin de RC4.

Mode d'échec courant à tester

Correspondance conformité

Le durcissement des approbations correspond aussi au guide français ANSSI sur la sécurité Active Directory établi (ANSSI-PA-099, section 3.2.3.1), utile si votre audit doit se rattacher à un référentiel nommé plutôt qu'à de simples bonnes pratiques internes : R24 (« Durcir la configuration des relations d'approbation AD sortantes extraforêt ») couvre la réactivation du filtrage SID — retrait de TREAT_AS_EXTERNAL et ajout de QUARANTINED_DOMAIN — sur les approbations de forêt et externes sortantes, et R25+ (« Utiliser des relations d'approbation sortantes avec authentification sélective ») couvre la délimitation de l'authentification sélective sur ces mêmes approbations. Une approbation en échec sur R24 et R25+ à la fois doit être traitée comme l'anomalie la plus prioritaire de l'audit, puisqu'elle ne dispose d'aucune des deux couches de contrôle d'accès traitées dans cet article. Le guide de l'ANSSI ne publie pas de recommandation spécifique aux approbations pour le chiffrement RC4/AES, donc traitez la vérification du chiffrement ci-dessus comme une mesure de durcissement autonome. Traitez R24/R25+ comme un moyen de communiquer la sévérité aux auditeurs et parties prenantes qui travaillent déjà avec le référentiel ANSSI, pas comme un remplacement des vérifications Get-ADTrust et msDS-SupportedEncryptionTypes sous-jacentes ci-dessus.

Comment EtcSec détecte cela

Les vérifications Trusts d'EtcSec lisent directement le bitmask trustAttributes du TDO et l'attribut msDS-SupportedEncryptionTypes du compte d'approbation interdomaine, signalant TRUST_SID_FILTERING_DISABLED et TRUST_AES_DISABLED/TRUST_RC4_ONLY de la même façon que Get-ADTrust et Get-ADObject ci-dessus, plus TRUST_EXTERNAL_NO_SELECTIVE_AUTH pour les approbations externes dépourvues du flag d'authentification sélective. Les anomalies renvoient vers l'objet d'approbation spécifique et sa direction, pour que la remédiation cible exactement la commande netdom ou PowerShell nécessaire — sans croisement manuel entre AD Domains and Trusts et un tableur. Si la dérive des approbations revient régulièrement entre deux audits, Workflow d'audit AD récurrent explique comment la détecter en continu plutôt qu'une fois par an.