Fremde Sicherheitsprinzipale in AD: SIDs vor Bereinigung einstufen

Was fremde Sicherheitsprinzipale in AD darstellen

Fremde Sicherheitsprinzipale in AD sind Platzhalterobjekte, mit denen eine Domäne Sicherheitsidentitäten darstellen kann, die sie nicht als gewöhnliche lokale Benutzer oder Gruppen speichert. Ihre Existenz ist eine Inventartatsache. Sie belegt weder einen Angriff noch eine gefährliche Berechtigung oder eine gestörte Vertrauensstellung. Prüfen Sie die SID jedes Objekts und die Gruppen, die es verwenden, bevor Sie entscheiden, ob etwas geändert werden sollte.

Microsofts MS-ADTS-Spezifikation des Containers für Foreign Security Principals erläutert den AD-DS-Fall: Der Domänennamenskontext enthält einen Container mit foreignSecurityPrincipal-Objekten, die Prinzipale aus vertrauenswürdigen Domänen außerhalb der Gesamtstruktur darstellen. So können diese Prinzipale Gruppen in der Domäne beitreten. Dieser Artikel behandelt AD DS und nicht die gesonderten Containerregeln von AD LDS.

Daneben gibt es den normalen Fall einer well-known SID. Microsofts historische FSP-Erklärung, zuletzt am 24. Mai 2016 aktualisiert, beschreibt, weshalb das Hinzufügen einer bekannten Identität zum Attribut member einer Gruppe einen Platzhalter erzeugen kann: Die Mitgliedschaftsreferenz benötigt einen bestehenden Distinguished Name. Das Archiv empfiehlt, vor dem Entfernen eines FSP dessen memberOf zu prüfen. Es dokumentiert Gruppenmitgliedschaften; es belegt nicht, dass jede ACL-Referenz einen FSP erzeugt.

Technische Quellen und das Verhalten des Collectors wurden am 4. Oktober 2026 geprüft. Die folgenden Befehle sind Beispiele auf Grundlage der Dokumentation für einen autorisierten Administrator; sie wurden nicht in einer Kundendomäne ausgeführt.

SID und Abhängigkeiten klassifizieren

Beginnen Sie mit drei Ergebnissen: bekannte Identität, aufgelöste externe Identität und unbestimmt. Das sind Prüfentscheidungen und keine aus einer Objektanzahl abgeleiteten Schweregrade. Halten Sie die SID im Prüfprotokoll fest, auch wenn ein Werkzeug einen lesbaren Namen anzeigt. Namen helfen bei der Kontaktaufnahme mit Verantwortlichen; die SID ist die referenzierte Identität.

Microsofts aktuelle Referenz zu Sicherheitsbezeichnern führt die folgenden bekannten Identitäten auf:

Dies ist eine Beispielsammlung und keine vollständige Nachschlagetabelle. Gleichen Sie jede andere SID mit der Microsoft-Referenz ab, bevor Sie ihr eine Bezeichnung zuweisen. Well-known bedeutet eine erkannte Identität, nicht automatisch angemessenen Zugriff. Eine weitreichende Mitgliedschaft kann weiterhin eine Prüfung erfordern; ihren Platzhalter zu löschen ersetzt jedoch nicht die Überprüfung der Mitgliedschaftsentscheidung.

Ermitteln Sie bei einer Domänenkonto-SID die ausstellende Domäne und bitten Sie deren zuständigen Administrator, den genauen Prinzipal zu bestätigen. Dokumentieren Sie Quelldomäne, aktuelle Identität, fachlichen Verantwortlichen und Zweck der Mitgliedschaft. Eine erfolgreiche Namensauflösung allein beweist nicht, dass die Gruppe weiterhin benötigt wird. Eine fehlgeschlagene Auflösung allein beweist nicht, dass der Prinzipal gelöscht wurde.

Machen Sie Unsicherheit ausdrücklich sichtbar. Das Prüfprotokoll sollte vier Fragen beantworten: Wurde die Erfassung abgeschlossen, welche Gruppen verwenden das Objekt, ist der relevante Vertrauenspartner erreichbar und wer darf die fachliche Entscheidung genehmigen? Bleibt eine Frage unbeantwortet, bleibt das Objekt in der Kategorie unbestimmt.

Erkennung: SID, memberOf und Vertrauenskontext erfassen

Schritt 1: Objekte unabhängig von der Anzahl erfassen

Verwenden Sie einen autorisierten Windows-Administrationsrechner mit dem PowerShell-Modul ActiveDirectory. Wählen Sie bewusst einen Domänencontroller aus und dokumentieren Sie Rechner, Domäne, Erfassungszeit und etwaige Fehler. Microsofts Dokumentation zu Get-ADRootDSE stellt defaultNamingContext bereit; bilden Sie damit den domänenspezifischen Container-DN, statt den Pfad einer anderen Domäne zu kopieren.

Das folgende Inventar passt die dokumentierten LDAP-Abfrageparameter von Get-ADObject an. Der Filter ist fest vorgegeben, zusätzliche Attribute sind ausdrücklich angegeben und $null für ResultSetSize vermeidet eine absichtliche Begrenzung der Ergebnisanzahl.

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

Für einen LDAP-Client verwendet die entsprechende Anfrage diesen Container als Suchbasis, den Suchbereich Subtree, (objectClass=foreignSecurityPrincipal) als Filter sowie distinguishedName, objectGUID, objectSid und memberOf als angeforderte Attribute. Schließen Sie die Seitennavigation vollständig ab, erhalten Sie mehrwertige Attribute und halten Sie Fehler getrennt von leeren Ergebnissen fest. Erzeugen Sie keine SID-Zeichenfolgen aus Anzeigenamen.

Gehen Sie nicht zur Bereinigung über, wenn die Abfrage fehlschlägt, unterbrochen wird oder das Konto die erforderlichen Eigenschaften nicht lesen kann. Ein leeres Inventar nach einer abgeschlossenen Leseoperation und ein nicht verfügbares Inventar sind unterschiedliche Ergebnisse. Wiederholen Sie bei mehreren Domänen die Erfassung mit dem jeweiligen Domänenkontext und halten Sie diese Datensätze getrennt.

Schritt 2: Die verwendenden Gruppen prüfen

Microsofts Schemareferenz zu memberOf beschreibt das Attribut als die Distinguished Names der Gruppen, denen das Objekt angehört. Behandeln Sie die zurückgegebenen Referenzen als Ausgangsliste der verwendenden Gruppen und nicht als Bericht über effektiven Zugriff. Verfolgen Sie Gruppenverschachtelungen und Ressourcenabhängigkeiten gesondert, bevor Sie Auswirkungen bewerten.

Wählen Sie einen FSP anhand seines dokumentierten DN aus, statt die erste Zeile zu nehmen. Dieses Beispiel nutzt die dokumentierten Parameter für Identität und zusätzliche Eigenschaften von Get-ADGroup, um jede zurückgegebene Gruppe zu prüfen:

$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
}

Prüfen Sie, ob die member-Werte der Gruppe den exakten FSP-DN enthalten. Fragen Sie den Gruppenverantwortlichen, welche Anwendung oder Ressource davon abhängt, ob eine Übernahme oder Migration noch läuft und wie der beabsichtigte Zugriff getestet werden soll. managedBy und die Beschreibung können Hinweise auf Ansprechpartner liefern; sie ersetzen keine Bestätigung durch einen rechenschaftspflichtigen Verantwortlichen. Ein leeres Verantwortlichenfeld ist eine Aufgabe zur Nachverfolgung und keine Erlaubnis zum Löschen.

Schritt 3: Auflösen, ohne aus Fehlern ein Verwaisungsurteil abzuleiten

Microsoft dokumentiert SecurityIdentifier.Translate und die zugehörige IdentityNotMappedException, wenn Identitätsreferenzen nicht übersetzt werden können. Dieses Beispiel bewahrt einen Fehler als Nachweis auf:

$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 }
}

Die Auflösung verwendet den Windows-Kontext des Administrationsrechners. Sie nimmt keinen ausgewählten Partner-DC entgegen und belegt nicht den Zustand der Vertrauensstellung. Bewahren Sie Rechner und Fehler auf, ermitteln Sie die erwartete ausstellende Domäne, prüfen Sie mit deren Administratoren die Namensauflösung und erforderliche Konnektivität und bestätigen Sie, ob die exakte SID dort noch existiert. Untersuchen Sie unerreichbare Partner und stillgelegte Vertrauensstellungen, bevor Sie von verwaist sprechen. Schwächen Sie keine Vertrauenseinstellungen, um eine Auflösung erfolgreich zu machen.

Microsofts Dokumentation zu Get-ADTrust enthält genau diesen Aufzählungsbefehl:

Get-ADTrust -Filter *

Verwenden Sie die zurückgegebenen Trusted-Domain-Objekte als Kontext und dokumentieren Sie die abgefragte Domäne. Ihre Existenz ist ein Konfigurationsnachweis und weder ein durchgängiger Konnektivitätstest noch der Beweis, dass eine bestimmte fremde SID aufgelöst wird. Sobald eine tatsächliche externe Identität identifiziert wurde, bietet das Audit der SID-Filterung und selektiven Authentifizierung bei Vertrauensstellungen die separate Prüfung der Vertrauenskontrollen.

Wenn stattdessen gefragt wird, ob ein nicht aufgelöster Berechtigungsempfänger eine gefährliche Berechtigung besitzt, nutzen Sie das Audit gefährlicher ACEs für nicht aufgelöste und domänenübergreifende Berechtigungsempfänger. Es untersucht DACL-Berechtigungen; dieses Inventar klassifiziert bestehende FSP-Objekte und ihre verwendenden Gruppen. Keine der beiden Prüfungen ersetzt die andere.

Behebung: nur eine nachweislich unnötige Referenz entfernen (Remediation)

Schritt 1: Klassifizierung und Umfang genehmigen

Behalten Sie benötigte well-known und externe Mitgliedschaften bei. Lassen Sie unbestimmte Objekte unverändert, solange Fragen zur Erfassung, Konnektivität oder Verantwortlichkeit offen sind. Bewahren Sie für eine möglicherweise stillgelegte Referenz die exakte SID, FSP-DN und GUID, die DNs der verwendenden Gruppen, die Bestätigung des Partners, die Entscheidung des Verantwortlichen und relevante Anwendungstests auf. Vereinbaren Sie ein Änderungsfenster und einen Rücksetzplan, der die beabsichtigte Mitgliedschaft wiederherstellen kann.

Treffen Sie eine konkrete Entscheidung: Welche Gruppenmitgliedschaft ist unnötig, weshalb und welche Zugriffe sollen anschließend weiterhin möglich sein? Hat nur eine verwendende Gruppe ihre Abhängigkeit aufgegeben, entfernen Sie ausschließlich diese Mitgliedschaft. Andere Gruppen können denselben Platzhalter weiterhin benötigen. Machen Sie das Löschen des Objekts nicht zum ersten Schritt einer Mitgliedschaftsprüfung.

Schritt 2: Eine genehmigte Mitgliedschaftsänderung vorab anzeigen

Microsofts Dokumentation zu Set-ADGroup unterstützt das Entfernen eines bestimmten Eigenschaftswerts über dessen LDAP-Anzeigenamen sowie WhatIf und Bestätigung. Dieses angepasste Beispiel zielt auf einen member-DN auf einem beschreibbaren DC:

$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

Prüfen Sie zuerst das Ziel und die gesicherte Mitgliedschaft. WhatIf zeigt eine Vorschau der Operation; es testet weder den Zugriff der Anwendung noch garantiert es, dass eine spätere Schreiboperation gelingt. Führen Sie erst nach der Genehmigung genau dieser Entfernung durch den Verantwortlichen die einzelne Änderung mit Bestätigung aus und lesen Sie die Gruppe erneut:

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

Schritt 3: Zugriff vor einer optionalen Objektbereinigung validieren

Bestätigen Sie, dass sich die genehmigte Mitgliedschaft geändert hat, berücksichtigen Sie Replikation und Authentifizierungskontext der Umgebung und lassen Sie den Anwendungsverantwortlichen sowohl den beabsichtigten Zugriff als auch die aufgegebene Abhängigkeit prüfen. Eine erfolgreiche Schreiboperation ist kein Zugriffstest. Dokumentieren Sie tatsächliche Ergebnisse im Änderungsprotokoll, statt aus einer niedrigeren Inventaranzahl einen Erfolg abzuleiten.

Erfassen Sie die Mitgliedschaft des FSP erneut und untersuchen Sie verbleibende Abhängigkeiten. Ein leeres memberOf belegt für sich allein nicht, dass eine SID in Ressourcen-ACLs oder Anwendungskonfigurationen unbenutzt ist. Ist das Objekt selbst nachweislich unnötig, ist die Objektbereinigung eine separate, ausdrücklich genehmigte Aktion. Microsofts Referenz zu Remove-ADObject dokumentiert das Entfernen einzelner Objekte; zeigen Sie die Vorschau für die dokumentierte GUID erst nach diesen Prüfungen an:

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

Diese Vorschau führt keine Löschung durch. Machen Sie daraus keine Pipeline über den Container und entfernen Sie den Container selbst nicht. Halten Sie Bereinigungsentscheidung, Wiederherstellungsplan und abschließende Zugriffsprüfung gemeinsam fest.

Wie EtcSec dies erkennt

Die EtcSec-Prüfung FOREIGN_SECURITY_PRINCIPALS meldet DomainInfo.ForeignSecurityPrincipalsCount. Die geprüfte Methode Detect() initialisiert die Anzahl mit null, übernimmt das Feld, wenn DomainInfo vorhanden ist, und gibt einen Befund mit Schweregrad Medium zurück, der diese Anzahl enthält. Ein fehlendes DomainInfo ergibt daher null. Die Details für eine positive Anzahl ergänzen einen Vorbehalt, aber keine Nachweise zu einzelnen Objekten oder eine SID-Klassifizierung.

Der LDAP-Provider führt eine paginierte Subtree-Suche unter CN=ForeignSecurityPrincipals,<baseDN> mit (objectClass=foreignSecurityPrincipal) durch. Er fordert nur distinguishedName an und weist bei erfolgreicher Suche die Anzahl der zurückgegebenen Einträge zu. Bei einem Suchfehler bleibt das Feld auf seinem Anfangswert null. Dieses Feld stellt keinen Indikator für eine erfolgreiche Erfassung bereit, der diesen Fehler von einem erfolgreich leeren Ergebnis unterscheidet.

Die Prüfung stellt weder einzelne SIDs noch memberOf, Verantwortliche, aufgelöste Namen, Vertrauenskonnektivität oder effektive Berechtigungen bereit. Ihre Anzahl vermischt well-known Platzhalter und tatsächliche externe Referenzen. Sie kann weder ein verwaistes Objekt identifizieren noch Vertrauensstellungen zählen, eine Exposition über Gesamtstrukturgrenzen beweisen oder belegen, dass null ein bereinigtes Inventar bedeutet. Die oben beschriebene unabhängige Erfassung und Klassifizierung liefern die für eine Entscheidung erforderlichen Nachweise. Dieser Ablauf enthält keine automatische Löschung.

Der erläuternde Text des Collectors verallgemeinert die Platzhaltererzeugung außerdem auf ACL-Referenzen. Die hier verwendete historische Microsoft-Quelle belegt den Fall member; diese weitergehende Formulierung wird nicht als verifizierte Regel wiederholt. Nehmen Sie den Befund als Anlass, die zugrunde liegenden Objekte und ihre Abhängigkeiten zu prüfen, und behalten oder ändern Sie anschließend nur das, was durch die Nachweise gestützt wird.