Principaux de securite etrangers AD : classer les SID avant nettoyage

Ce que représentent les principaux de securite etrangers AD

Les principaux de securite etrangers AD sont des objets de substitution qui permettent à un domaine de représenter des identités de sécurité qu'il ne stocke pas sous forme d'utilisateurs ou de groupes locaux ordinaires. Leur présence est un fait d'inventaire. Elle ne démontre ni une attaque, ni une autorisation dangereuse, ni une relation d'approbation défaillante. Examinez le SID de chaque objet et les groupes qui l'utilisent avant de décider si quelque chose doit changer.

La spécification Microsoft du conteneur Foreign Security Principals dans MS-ADTS explique le cas AD DS : le contexte de nommage du domaine contient un conteneur d'objets foreignSecurityPrincipal représentant des principaux de domaines approuvés extérieurs à la forêt, ce qui leur permet de rejoindre des groupes du domaine. Cet article traite d'AD DS, et non des règles distinctes du conteneur AD LDS.

Il existe également un cas normal lié aux SID bien connus. L'explication historique des FSP de Microsoft, mise à jour le 24 mai 2016, décrit pourquoi l'ajout d'une identité bien connue à l'attribut member d'un groupe peut créer un objet de substitution : la référence d'appartenance exige un nom distinctif existant. L'archive recommande d'examiner memberOf avant de supprimer un FSP. Elle documente l'appartenance aux groupes ; elle ne démontre pas que chaque référence dans une ACL crée un FSP.

Les sources techniques et le comportement du collecteur ont été examinés le 4 octobre 2026. Les commandes ci-dessous sont des exemples fondés sur la documentation, destinés à un administrateur autorisé ; elles n'ont pas été exécutées sur un domaine client.

Comment classer le SID et ses dépendances

Commencez par trois résultats possibles : identité bien connue, identité externe résolue et indéterminé. Ce sont des décisions de revue, et non des niveaux de gravité déduits d'un nombre d'objets. Conservez le SID dans le dossier même lorsqu'un outil affiche un nom lisible. Les noms servent à contacter les responsables ; le SID est l'identité référencée.

La référence actuelle de Microsoft sur les identificateurs de sécurité répertorie les identités bien connues suivantes :

Il s'agit d'un ensemble d'exemples, et non d'une table de correspondance exhaustive. Rapprochez tout autre SID de la référence Microsoft avant de lui attribuer une étiquette. Bien connu signifie identité reconnue, et non accès automatiquement approprié. Une appartenance très large peut toujours mériter une revue, mais supprimer son objet de substitution ne remplace pas l'examen de la décision d'appartenance.

Pour un SID de compte de domaine, identifiez le domaine émetteur et demandez à l'administrateur responsable de ce domaine de confirmer le principal exact. Consignez le domaine source, l'identité actuelle, le responsable métier et l'objectif de son appartenance. Une résolution de nom réussie ne prouve pas, à elle seule, que le groupe reste nécessaire. Une résolution échouée ne prouve pas, à elle seule, que le principal a été supprimé.

Rendez l'incertitude explicite. Le dossier de revue doit répondre à quatre questions : la collecte s'est-elle terminée, quels groupes utilisent l'objet, le partenaire d'approbation concerné peut-il être contacté et qui peut approuver la décision métier ? Une question sans réponse maintient l'objet dans la catégorie indéterminée.

Détection : inventorier le SID, memberOf et le contexte d'approbation

Étape 1 : collecter les objets indépendamment du nombre

Utilisez un poste d'administration Windows autorisé doté du module PowerShell ActiveDirectory. Choisissez délibérément un contrôleur de domaine et consignez le poste, le domaine, l'heure de collecte et les erreurs éventuelles. La documentation Microsoft de Get-ADRootDSE expose defaultNamingContext ; utilisez-le pour construire le DN du conteneur propre au domaine au lieu de copier le chemin d'un autre domaine.

L'inventaire suivant adapte les paramètres documentés de requête LDAP de Get-ADObject. Le filtre est fixe, les attributs supplémentaires sont explicites et $null pour ResultSetSize évite de limiter volontairement le nombre de résultats.

Import-Module ActiveDirectory
$dc = 'dc01.corp.example'
$root = Get-ADRootDSE -Server $dc -ErrorAction Stop
$base = 'CN=ForeignSecurityPrincipals,' + $root.defaultNamingContext
$fsps = @(Get-ADObject -Server $dc -SearchBase $base -SearchScope Subtree `
    -LDAPFilter '(objectClass=foreignSecurityPrincipal)' `
    -Properties objectSID,memberOf -ResultPageSize 256 `
    -ResultSetSize $null -ErrorAction Stop)
$fsps | Select-Object DistinguishedName,ObjectGUID,objectSID,memberOf

Pour un client LDAP, la requête équivalente utilise ce conteneur comme base de recherche, une portée de sous-arbre, (objectClass=foreignSecurityPrincipal) comme filtre et distinguishedName, objectGUID, objectSid et memberOf comme attributs demandés. Terminez la pagination, préservez les attributs multivalués et conservez les échecs séparément des résultats vides. Ne fabriquez pas de chaînes SID à partir des noms affichés.

Ne passez pas au nettoyage si la requête échoue, est interrompue ou si le compte ne peut pas lire les propriétés requises. Un inventaire vide issu d'une lecture terminée et un inventaire indisponible sont deux résultats différents. Pour plusieurs domaines, répétez la collecte avec le contexte propre à chaque domaine et conservez ces dossiers séparément.

Étape 2 : examiner les groupes qui utilisent l'objet

La référence de schéma Microsoft de memberOf le définit comme les noms distinctifs des groupes auxquels l'objet appartient. Traitez les références renvoyées comme la liste initiale des groupes utilisateurs, et non comme un rapport d'accès effectifs. Suivez séparément l'imbrication des groupes et les dépendances des ressources avant de juger l'impact.

Sélectionnez un FSP par son DN consigné, et non en prenant la première ligne. Cet exemple utilise les paramètres documentés d'identité et de propriétés supplémentaires de Get-ADGroup pour examiner chaque groupe renvoyé :

$fspDn = Read-Host 'Exact FSP distinguished name from the inventory'
$fsp = Get-ADObject -Identity $fspDn -Server $dc `
    -Properties objectSID,memberOf -ErrorAction Stop
foreach ($groupDn in $fsp.memberOf) {
    Get-ADGroup -Identity $groupDn -Server $dc `
        -Properties member,memberOf,managedBy,description -ErrorAction Stop |
        Select-Object DistinguishedName,GroupScope,GroupCategory, `
            member,memberOf,managedBy,description
}

Vérifiez que les valeurs member du groupe contiennent le DN exact du FSP. Demandez au responsable du groupe quelle application ou ressource en dépend, si une acquisition ou une migration est toujours en cours et comment tester l'accès prévu. managedBy et la description peuvent fournir des indices de contact ; ils ne remplacent pas la confirmation d'un responsable identifié. Un champ de responsable vide est une tâche de suivi, et non une autorisation de supprimer.

Étape 3 : résoudre sans transformer les échecs en verdict d'orphelin

Microsoft documente SecurityIdentifier.Translate et son IdentityNotMappedException lorsque les références d'identité ne peuvent pas être traduites. Cet exemple conserve l'échec comme élément de preuve :

$sid = [System.Security.Principal.SecurityIdentifier]$fsp.objectSID
try {
    $account = $sid.Translate([System.Security.Principal.NTAccount])
    [pscustomobject]@{ SID = $sid.Value; Account = $account.Value }
} catch {
    [pscustomobject]@{ SID = $sid.Value; LookupError = $_.Exception.Message }
}

La résolution utilise le contexte Windows du poste d'administration. Elle n'accepte pas de contrôleur de domaine partenaire sélectionné et ne démontre pas le bon fonctionnement de la relation d'approbation. Conservez le poste et l'erreur, identifiez le domaine émetteur attendu, vérifiez la résolution de noms et la connectivité requise avec ses administrateurs, puis confirmez si le SID exact y existe toujours. Examinez les partenaires inaccessibles et les relations d'approbation retirées avant d'employer le mot orphelin. N'affaiblissez pas les paramètres d'approbation pour faire réussir une résolution.

La documentation Microsoft de Get-ADTrust fournit cette commande exacte d'énumération :

Get-ADTrust -Filter *

Utilisez les objets de domaine approuvé renvoyés comme contexte, en consignant le domaine interrogé. Leur présence constitue une preuve de configuration, et non un test de connectivité de bout en bout ou une preuve qu'un SID étranger particulier peut être résolu. Une fois une véritable identité externe identifiée, l'audit du filtrage SID et de l'authentification sélective des relations d'approbation fournit la revue distincte des contrôles d'approbation.

Si la question est plutôt de savoir si un bénéficiaire d'autorisation non résolu détient un droit dangereux, utilisez l'audit des ACE dangereuses pour les bénéficiaires non résolus et inter-domaines. Celui-ci examine les autorisations DACL ; cet inventaire classe les objets FSP existants et les groupes qui les utilisent. Aucune de ces revues ne remplace l'autre.

Remédiation : supprimer uniquement une référence dont l'inutilité est prouvée (Remediation)

Étape 1 : approuver la classification et le périmètre

Conservez les appartenances bien connues et externes nécessaires. Laissez les objets indéterminés inchangés tant que des questions de collecte, de connectivité ou de responsabilité restent ouvertes. Pour une référence potentiellement retirée, conservez le SID exact, le DN et le GUID du FSP, les DN des groupes qui l'utilisent, la confirmation du partenaire, la décision du responsable et les tests applicatifs pertinents. Convenez d'une fenêtre de changement et d'un retour arrière capable de restaurer l'appartenance prévue.

Rendez la décision précise : quelle appartenance à un groupe est inutile, pourquoi, et quels accès doivent perdurer ensuite ? Si un seul groupe utilisateur a retiré sa dépendance, supprimez uniquement cette appartenance. D'autres groupes peuvent encore avoir besoin du même objet de substitution. Ne faites pas de la suppression d'objet la première étape d'une revue des appartenances.

Étape 2 : prévisualiser un changement d'appartenance approuvé

La documentation Microsoft de Set-ADGroup permet de supprimer une valeur de propriété précise par son nom d'affichage LDAP et prend en charge WhatIf et la confirmation. Cet exemple adapté cible un seul DN member sur un contrôleur de domaine accessible en écriture :

$groupDn = Read-Host 'Exact approved consuming group distinguished name'
Get-ADGroup -Identity $groupDn -Server $dc -Properties member -ErrorAction Stop
Set-ADGroup -Identity $groupDn -Server $dc -Remove @{member=$fspDn} -WhatIf

Examinez d'abord la cible et l'appartenance sauvegardée. WhatIf prévisualise l'opération ; il ne teste pas l'accès de l'application et ne garantit pas la réussite d'une écriture ultérieure. Ce n'est qu'après l'approbation de cette suppression exacte par le responsable que vous pouvez exécuter le changement individuel avec confirmation et relire le groupe :

Set-ADGroup -Identity $groupDn -Server $dc -Remove @{member=$fspDn} `
    -Confirm:$true -ErrorAction Stop
Get-ADGroup -Identity $groupDn -Server $dc -Properties member -ErrorAction Stop

Étape 3 : valider l'accès avant un éventuel nettoyage d'objet

Confirmez que l'appartenance approuvée a changé, tenez compte de la réplication et du contexte d'authentification de l'environnement, et faites vérifier par le responsable applicatif l'accès prévu ainsi que la dépendance retirée. Une écriture réussie n'est pas un test d'accès. Consignez les résultats réels dans le dossier de changement plutôt que de déclarer une réussite à partir d'un nombre d'inventaire plus faible.

Collectez de nouveau les appartenances du FSP et examinez les dépendances restantes. Un memberOf vide ne démontre pas, à lui seul, qu'un SID n'est utilisé ni dans les ACL de ressources ni dans la configuration applicative. Si l'inutilité de l'objet lui-même est prouvée, son nettoyage est une action distincte, explicitement approuvée. La référence Microsoft de Remove-ADObject documente la suppression d'un objet unique ; prévisualisez le GUID consigné uniquement après ces vérifications :

Remove-ADObject -Identity $fsp.ObjectGUID -Server $dc -WhatIf

Cette prévisualisation n'effectue aucune suppression. Ne la transformez pas en pipeline sur le conteneur et ne supprimez pas le conteneur lui-même. Conservez ensemble la décision de nettoyage, le plan de restauration et la vérification finale des accès.

Comment EtcSec détecte ce cas

Le contrôle FOREIGN_SECURITY_PRINCIPALS d'EtcSec rapporte DomainInfo.ForeignSecurityPrincipalsCount. La méthode Detect() examinée initialise le compteur à zéro, copie le champ lorsque DomainInfo existe et renvoie un constat de gravité Medium contenant ce nombre. Un DomainInfo absent produit donc zéro. Les détails associés à un compteur positif ajoutent une réserve, et non des preuves par objet ou une classification des SID.

Le fournisseur LDAP effectue une recherche paginée dans le sous-arbre de CN=ForeignSecurityPrincipals,<baseDN> avec (objectClass=foreignSecurityPrincipal). Il demande uniquement distinguishedName et affecte le nombre d'entrées renvoyées lorsque la recherche réussit. Une erreur de recherche laisse le champ à sa valeur initiale de zéro. Ce champ n'expose aucun indicateur de réussite de collecte qui distingue cet échec d'un résultat vide obtenu avec succès.

Le contrôle n'expose ni SID individuels, ni memberOf, ni responsables, ni noms résolus, ni connectivité d'approbation, ni autorisations effectives. Son compteur mélange les objets de substitution bien connus et les véritables références externes. Il ne peut pas identifier un orphelin, compter les relations d'approbation, prouver une exposition entre forêts ou établir que zéro signifie un inventaire propre. La collecte et la classification indépendantes ci-dessus fournissent les preuves nécessaires à une décision. Cette procédure ne comporte aucune suppression automatique.

Le texte explicatif du collecteur généralise également la création d'objets de substitution aux références dans les ACL. La source historique Microsoft utilisée ici établit le cas member ; cette formulation plus large n'est pas reprise comme une règle vérifiée. Traitez le constat comme une invitation à examiner les objets sous-jacents et leurs dépendances, puis conservez ou modifiez uniquement ce que les preuves justifient.