AD OU Zaehlung direkter Kinder: vor Umstrukturierung prüfen

Was eine AD OU Zaehlung direkter Kinder belegt

Eine AD OU Zaehlung direkter Kinder erfasst, welche Objekte unmittelbar unter einer bestimmten Organisationseinheit liegen. Vor einer Umstrukturierung beantwortet sie eine eng begrenzte Frage: Was enthält diese OU auf dieser Ebene in der Verzeichnisansicht, die wir tatsächlich gelesen haben? Führen Sie für die darunterliegende Hierarchie ein separates Inventar. Die Anzahl direkter Kinder hilft bei der Planung, aber ein scheinbar leerer Zähler darf niemals automatisch zu einer Löschentscheidung führen.

Dieser Leitfaden wurde am 4. Oktober 2026 anhand von Microsoft Learn und der unten angegebenen Collector-Revision geprüft. Er beschreibt ein Abgleichverfahren für Administratoren, die ein OU-Inventar prüfen. Die PowerShell-Befehle sind dokumentarische Beispiele für Leser, die aus der dokumentierten Parametersyntax abgeleitet wurden; sie wurden für diesen Artikel nicht gegen eine AD-Domäne ausgeführt. Es wird weder eine erfolgreiche Erfassung noch eine leere produktive OU oder eine abgeschlossene Änderung behauptet.

Das praktische Problem ist die Abweichung zwischen der Bezeichnung eines Zählers und seiner Population. Ein Bericht kann Users, Computers, Groups und OUs anzeigen, während der Prüfer annimmt, er beschreibe sämtliche Objekte unterhalb der OU. Auch Erfassungsgrenzen, Ausschlüsse oder ein Vergleich des übergeordneten DN können Objekte auslassen. Halten Sie diese Grenzen fest, bevor Sie den Bericht in einem Änderungsantrag verwenden.

Funktionsweise: Zählungen einer Ebene von der Hierarchie trennen

Microsofts Get-ADObject-Referenz unterscheidet OneLevel, das unmittelbare Kinder durchsucht, von Subtree, das die Basis und Nachfahren einschließt. SearchBase legt den Zielpfad fest, Server wählt die Verzeichnisinstanz. Geben Sie beide an, wenn Sie Nachweise erstellen.

Erstellen Sie für dasselbe Ziel zwei Aufzeichnungen: ein Inventar direkter Kinder für die lokale Population und ein Teilbauminventar für Abhängigkeiten tiefer in der Hierarchie. Kennzeichnen Sie deren Suchbereiche ausdrücklich. Vergleichen Sie die Summe der Klassenzähler direkter Kinder nicht mit einer unqualifizierten Teilbaumgesamtzahl. Eine OU, die eine weitere OU enthält, kann wenige direkte Identitäten haben, während die untergeordnete Hierarchie die für die Änderung entscheidenden Objekte enthält.

Bewahren Sie für jedes Inventar Objektkennungen, ursprüngliche DNs, Klasse, Erfassungskontext und Abschlussstatus auf. Legen Sie die unverarbeitete Objektliste neben jeder zusammengefassten Anzahl ab, damit sich Abweichungen untersuchen lassen, ohne zu erraten, welche Objekte dazu beigetragen haben. Eine Objektliste ermöglicht auch die Unterscheidung zwischen einer unerwarteten Klasse und einer unerwarteten Elternbeziehung.

Festlegen, was die Klassenbezeichnungen bedeuten

Betrachten Sie Users, Computers, Groups und OUs als vier Collector-Populationen, nicht als Zusage, dass jede Verzeichnisklasse gelesen wurde. Definieren Sie die unabhängigen Abfragen vor dem Vergleich. Erfassen Sie andere zurückgegebene Klassen separat; ordnen Sie sie nicht stillschweigend Users zu und ignorieren Sie sie nicht, weil dem Dashboard ein entsprechender Zähler fehlt.

Die geprüfte LDAP-Benutzerpopulation enthält im Standardfilter einen Zweig für gruppenverwaltete Dienstkonten. Deshalb können die unten gezeigte Abfrage für Personenbenutzer und der Users-Bereich des Collectors selbst dann abweichen, wenn beide Lesevorgänge abgeschlossen werden. Vergleichen Sie die tatsächlichen Filterdefinitionen und zurückgegebenen Objektkennungen. Halten Sie Dienstkonto-Unterklassen und andere nicht zugeordnete Klassen im Abgleichprotokoll sichtbar, statt eine numerische Übereinstimmung zu erzwingen.

Unser Leitfaden zu Standardcontainern und zum Geltungsbereich von Gruppenrichtlinien erklärt, warum Standardziele und der beabsichtigte Richtlinienbereich eine separate Platzierungsprüfung benötigen. Sein OneLevel-Beispiel inventarisiert Computer im Standardcontainer Computers. Es liefert keine Zählung der vier Populationen in einer OU, berücksichtigt nicht jede Klasse und löst nicht das hier behandelte Problem escapeter DNs.

Erkennung: Objekte lesen, bevor Zähler verglichen werden

1. Den Abfragekontext festlegen

Wählen Sie die genehmigte OU und einen ausdrücklich angegebenen Verzeichnisserver. Erfassen Sie den Lesekontext des Operators, Start- und Abschlusszeiten, Suchbasis, Suchbereich, Klassenfilter und sämtliche Fehler. Verwenden Sie einen autorisierten Administrationshost mit dem AD-PowerShell-Modul. Der folgende OU-DN steht in Beispiel 5 der Get-ADObject-Referenz; der Servername ist ein fiktiver FQDN-Platzhalter. Ersetzen Sie beide durch das geprüfte Ziel.

Die folgenden Beispiele leiten sich aus den dokumentierten Get-ADObject-Parametern Filter, LDAPFilter, SearchBase, SearchScope, Server und Properties ab. Sie fordern Kennungen für den Abgleich an. Speichern Sie die zurückgegebenen Objekte und das Ergebnis des Vorgangs über Ihren Administrationsprozess, bevor Sie eine Zusammenfassung berechnen.

Lesen Sie zuerst die direkte Population ohne Klassenbeschränkung:

Get-ADObject -Filter * -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Mit dieser Liste entdecken Sie Klassen, die die vier Zähler nicht beschreiben. Das Inventar bleibt durch die ausgewählte Ansicht und den Lesekontext begrenzt. Falls der Vorgang fehlschlägt oder vorzeitig endet, bewahren Sie dieses Ergebnis auf; bereits angezeigte Objekte sind kein Nachweis einer vollständigen Zählung.

2. Klassenabfragen getrennt halten

Diese Beispiele für Leser definieren separate Prüfpopulationen; sie bilden nicht sämtliche Collector-Filter nach. Das erste kombiniert objectClass=user mit objectCategory=person, wie in Microsofts Anleitung zur Abfrage von Benutzern dokumentiert. Ein Filter allein nach Benutzerklasse trifft auch Computer, weil die Computerklasse von user abgeleitet ist:

Get-ADObject -LDAPFilter '(&(objectClass=user)(objectCategory=person))' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Get-ADObject -Filter 'ObjectClass -eq "computer"' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Get-ADObject -Filter 'ObjectClass -eq "group"' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Get-ADObject -Filter 'ObjectClass -eq "organizationalUnit"' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Halten Sie die vier Ausgaben einzeln identifizierbar. Erfassen Sie, ob jede Abfrage abgeschlossen wurde, und vergleichen Sie ihre Objektmenge mit der uneingeschränkten OneLevel-Liste. Wo eine weitere Klasse auftaucht, ergänzen Sie eine separat bezeichnete Prüfpopulation. Wo ein Collector-Bereich einen breiteren Filter verwendet, dokumentieren Sie die zusätzliche Population vor dem Abgleich der Anzahl.

3. Den Teilbaum als anderen Nachweis lesen

Verwenden Sie für die Hierarchie einen separaten Vorgang:

Get-ADObject -Filter * -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope Subtree -Server 'dc01.fabrikam.com' -Properties objectGUID

Kennzeichnen Sie diese Ausgabe als Subtree und unterscheiden Sie die Basis-OU von den darunterliegenden Objekten. Prüfen Sie untergeordnete OUs und deren Inhalte gemeinsam mit ihren Verantwortlichen. Addieren Sie diese Gesamtzahl nicht zu den Zählern direkter Kinder und bezeichnen Sie sie nicht als zweite Messung derselben Population.

4. Kennungen und escapete DNs abgleichen

Learn dokumentiert objectGUID als eine von Get-ADObject akzeptierte Kennung. Verwenden Sie sie als Vergleichsschlüssel in den unabhängigen Inventaren und bewahren Sie den DN als Standortnachweis auf. Falls die Collector-Nutzdaten keine GUID enthalten, lösen Sie ihren aufgezeichneten DN im selben Kontext auf und bewahren Sie die Zuordnung auf; erfinden Sie keine Kennung und gleichen Sie nicht allein anhand des Anzeigenamens ab.

Microsofts Referenz zu Distinguished Names erläutert, dass RDNs durch Kommas getrennt werden und dass ein Komma innerhalb eines Attributwerts escapet werden muss. Ein bloßes Komma reicht daher nicht aus, um zu entscheiden, wo ein Name endet und sein übergeordnetes Objekt beginnt.

Learn nennt beispielsweise diesen DN mit einem escapeten Komma im OU-RDN:

CN=Litware,OU=Docs\, Adatum,DC=Fabrikam,DC=COM

Bevorzugen Sie das OneLevel-Ergebnis des Verzeichnisses, wenn Sie die unmittelbare Elternbeziehung feststellen. Muss ein Export lokal verarbeitet werden, verwenden Sie einen DN-fähigen Parser, der Escaping berücksichtigt, und behalten Sie die ursprüngliche Zeichenfolge. Trennen Sie nicht an jedem Komma und entfernen Sie keine Backslashes, bevor Sie die Elternbeziehung bestimmen.

Abgleich der Zählung vor der Umstrukturierung (Remediation)

1. Jede Beobachtung einordnen

Entscheiden Sie anhand des Abgleichprotokolls, was belegt ist und was offenbleibt. Eine Abweichung ist ein Anlass, Suchbereich, Filter, Kennungen oder Erfassung zu untersuchen, statt Objekte so lange zu ändern, bis die Anzahlen übereinstimmen.

Ordnen Sie diese Klassifizierung der konkreten OU und Klasse zu. Eine Bezeichnung der gesamten Zeile als „leer“ verwischt den Unterschied zwischen einer verifizierten Null für eine Klasse und einem fehlenden Lesevorgang für eine Klasse. Falls unterschiedliche Abfragen zu unterschiedlichen Zeiten abgeschlossen wurden, bewahren Sie diesen Unterschied auf, statt sie als eine gleichzeitige Momentaufnahme darzustellen.

2. Unterschiede vor Änderungen an der Hierarchie erklären

Vergleichen Sie zuerst einzelne Objekte, dann Gesamtzahlen. Erfassen Sie, ob jeder Unterschied von einer anderen Klasse, einem tieferen Nachfahren, einem Ausschluss, einem Filter, unvollständiger Erfassung oder ungeklärtem Elternabgleich stammt. Halten Sie unerklärte Unterschiede mit einem verantwortlichen Prüfer und den zu ihrer Klärung erforderlichen Nachweisen offen.

Verwenden Sie für den ersten Abgleich denselben Server- und Zielkontext. Falls die Prüfung einen weiteren Server umfasst, kennzeichnen Sie dessen Inventar unabhängig. Ein Unterschied zwischen Ansichten muss untersucht werden; dieses Verfahren bietet keine Grundlage, ein Replikationsergebnis zu erraten oder eine passende Anzahl als maßgeblich zu behandeln.

Dokumentieren Sie Collector-Ausschlüsse und sämtliche Erfassungsgrenzen neben den unabhängigen Lesevorgängen. Halten Sie eine uneingeschränkte administrative Zählung getrennt von einer Teilmenge, die absichtlich an die Collector-Eingaben angepasst wurde. Ein ausgeschlossenes Objekt bleibt für die Umstrukturierung relevant, obwohl es nicht zu einem gefilterten Zähler beiträgt.

3. Verantwortlichkeit und Löschschutz bewahren

Geben Sie dem Verantwortlichen die Aufzeichnung auf Objektebene, die Teilbaumprüfung, die ungeklärten Unterschiede und den vorgeschlagenen Umfang. Holen Sie eine Entscheidung über das genaue Ziel und seine Abhängigkeiten ein. Ein OU-Name, eine kleine Anzahl oder ein leeres Dashboard-Feld bestimmt nicht, wer eine Verschiebung oder Bereinigung genehmigen darf.

Befolgen Sie die ergänzende unabhängige Berechtigungsprüfung und Entscheidung des Verantwortlichen vor der OU-Bereinigung. Dieser Leitfaden behandelt Löschschutz und begrenzte Ausnahmen. Belassen Sie diese Prüfung im Änderungsprozess; diese Zählung bewertet weder die einschlägigen Berechtigungen noch autorisiert sie das Entfernen von Schutzmaßnahmen.

Bestimmen Sie vor der Genehmigung einer Umstrukturierung die beabsichtigten Folgen für Richtlinien und Administration der betroffenen Objekte. Belassen Sie die Platzierung in Standardcontainern und den GPO-Geltungsbereich in der Platzierungsprüfung und den Löschschutz in der ergänzenden Berechtigungsprüfung. Die Zählung liefert die Objektpopulation, von der diese Entscheidungen abhängen.

4. Das genehmigte Ergebnis überprüfen

Wiederholen Sie nach einer autorisierten Änderung die relevanten OneLevel- und Subtree-Lesevorgänge mit dem aufgezeichneten Zielkontext. Gleichen Sie die verbleibenden Objekte anhand ihrer Kennung ab und erfassen Sie ihre aktuellen Standorte. Bewahren Sie die Entscheidung des Verantwortlichen und das tatsächliche Ergebnis des Vorgangs neben den Vorher-Nachher-Nachweisen auf.

Schließen Sie die Inventaraufgabe ab, wenn die vereinbarten Populationen und verbleibenden Unsicherheiten dokumentiert sind. Schließen Sie die Änderungsaufgabe anhand ihrer eigenen Ergebniskriterien ab, einschließlich der ergänzenden Schutzprüfung. Eine übersichtlicher wirkende Anzahl reicht nicht aus, um zu belegen, dass Abhängigkeiten, Richtlinienbereich und der Schutz verbleibender Objekte berücksichtigt wurden.

Wie EtcSec dies erkennt

Dieser Abschnitt beschreibt ausschließlich INFO_DOMAIN_OU_INVENTORY, geprüft im etc-collector-Commit afca1b9f7bba6f076d6a6493371486071001452b. Der relevante Detektor ist public/internal/audit/detectors/ad/permissions/organization/ou-inventory.go:31.

Sein Detect() erzeugt für jede erfasste OU einen Befund der Stufe Info mit Count=1. Diese Anzahl bezeichnet einen Inventareintrag, nicht die Anzahl der Kinder oder ein Schwachstellenurteil. Bei leerer OU-Eingabe liefert er keine Befunde. Details betroffener Entitäten werden nur befüllt, wenn IncludeDetails aktiviert ist; fehlende Details belegen keine fehlenden Kinder.

Der LDAP-Provider GetOUs unter public/internal/providers/ldap/client.go:946 liest Organisationseinheiten über seine Teilbaum-Suchfunktion. Eine Teilbaumerfassung von OUs verwandelt die ausgegebenen Kinderzähler nicht in Nachfahrenzahlen und belegt keine allgemeine Vollständigkeit.

In public/internal/audit/gpo_policy.go:365–436 erstellt OUEntity die ChildCounts aus den übergebenen Arrays Users, Computers, Groups und OUs. Die Hilfsfunktion zählt nur unmittelbare Kinder. Vor der Erkennung angewandte Asset-Ausschlüsse beeinflussen diese Populationen; andere Verzeichnisklassen sind kein fünfter Zähler für sämtliche Objekte. Die Anzahl muss im Verhältnis zu den tatsächlich erfassten Daten interpretiert werden.

Der Elterntest prüft ein OU-Suffix ohne Beachtung der Groß- und Kleinschreibung und verwirft anschließend einen führenden Teil, der irgendein Komma enthält. Statische Schlussfolgerung: Ein escapetes Komma im führenden RDN kann dazu führen, dass ein echtes direktes Kind ausgelassen wird. Dies folgt aus dem geprüften Zeichenfolgenprädikat und dem dokumentierten DN-Escaping; es wurde hier nicht durch die Ausführung eines Domänentests nachgewiesen.

Schließlich initialisiert OUEntity Delegations als leeres Platzhalter-Array, weil die Verdrahtung der OU-DACL-Delegierung auf diesem Pfad nicht befüllt wird. Dies liefert keinen Nachweis, dass delegierte Rechte fehlen. Verwenden Sie das Inventar zur Auswahl und zum Abgleich von OUs; belegen Sie Inhalte, Berechtigungen und das genehmigte Umstrukturierungsergebnis durch die oben beschriebenen separaten Nachweise.