AD leere privilegierte Gruppen Review: Mitgliedschaft vor Abschluss prüfen

Was die Prüfung leerer privilegierter AD-Gruppen klärt

Ein AD leere privilegierte Gruppen Review prüft, ob eine gemeldete Abwesenheit von Mitgliedern verlässlich und beabsichtigt ist. Ein informativer Befund ist der Ausgangspunkt für die Verifikation: die Gruppe identifizieren, feststellen, was die Erfassung tatsächlich gelesen hat, und anschließend die Entscheidung des Verantwortlichen dokumentieren. Beim Schließen des Befunds sollten diese Nachweise erhalten bleiben, statt die Mitgliedschaft lediglich zu ändern, damit das Ergebnis verschwindet.

Microsoft dokumentiert mehrere Operatorgruppen ohne Standardmitglieder, darunter Account Operators, Backup Operators, Print Operators und Server Operators. Ihr leerer Zustand kann daher dem erwarteten Zustand entsprechen. Dieselbe Referenz erläutert die administrativen Fähigkeiten dieser Gruppen und die Einschränkungen beim Löschen integrierter Gruppen. Konsultieren Sie die Referenz zu Active Directory-Sicherheitsgruppen für die jeweils geprüfte Gruppe.

Die hilfreiche Unterscheidung lautet: Mitgliedschaft unbekannt, Mitglieder nachweislich vorhanden oder beabsichtigte Leere innerhalb eines definierten Umfangs bestätigt. Diese Ergebnisse verlangen unterschiedliche Folgemaßnahmen. Ein fehlendes Attribut, ein fehlgeschlagener Befehl und eine genehmigte leere Gruppe dürfen nicht dieselbe Abschlusskennzeichnung erhalten.

Wie Nachweise zur Mitgliedschaft unvollständig sein können

Das member-Attribut des Gruppenobjekts ist mehrwertig und verwendet die Distinguished-Name-Syntax. Sein Auslesen liefert eine Sicht auf Attributebene. Die Prüfung muss außerdem verschachtelte Gruppen und, soweit relevant, die auf Kontoseite hinterlegte primäre Gruppenmitgliedschaft berücksichtigen.

Die Seitennavigation von LDAP-Ergebnissen und der bereichsweise Abruf von Attributwerten lösen unterschiedliche Probleme. Paging ruft Objektmengen ab; der bereichsweise Abruf von Attributwerten ruft Teilmengen der Werte eines einzelnen mehrwertigen Attributs ab. Ein Collector kann das Paging seiner Gruppensuche abschließen und dennoch daran scheitern, die Mitgliedschaftswerte einer einzelnen Gruppe zusammenzuführen. Prüfen Sie bei der Diagnose eines rohen LDAP-Exports die zurückgegebenen Attributnamen und den vollständigen Abruf aller Bereiche.

Die Schemareferenz zu primaryGroupID definiert dieses Kontoattribut als relativen Bezeichner der primären Gruppe. Ein Export ausschließlich von Gruppen untersucht dieses Kontoattribut nicht. Unser Artikel über primaryGroupID-Mitgliedschaften, die Exporte ausschließlich des member-Attributs übersehen erklärt diesen separaten Mitgliedschaftspfad. Nutzen Sie ihn, um die Grenze der Abdeckung zu verstehen; diese Prüfung erfordert weder eine Änderung von primaryGroupID noch das Nachstellen der Missbrauchstechnik.

Notieren Sie vor der Interpretation eines leeren Ergebnisses den genauen DC, die Domäne, die Suchbasis, die Erfassungsidentität und relevante Begrenzungen. Bewahren Sie die zurückgegebenen Fehler auf. Wenn sich diese Fakten nicht feststellen lassen, kennzeichnen Sie die Mitgliedschaft als unbekannt und benennen Sie einen Verantwortlichen für die Nachverfolgung. Machen Sie aus einem Betriebsfehler kein erfolgreiches leeres Ergebnis.

Erkennung: Die Gruppe auf einem ausgewählten DC prüfen

Die folgenden PowerShell-Beispiele verwenden von Microsoft Learn dokumentierte Syntax. Es handelt sich um schreibgeschützte Prüfbeispiele mit Platzhalterwerten für die Umgebung, nicht um Befehle, die für diesen Artikel in einem AD-Labor ausgeführt wurden. Ersetzen Sie Server, Domäne und Gruppenidentität, bevor Sie sie auf einem System mit verfügbarem ActiveDirectory-Modul ausführen.

Schritt 1: Vor dem Zählen der Mitglieder die Identität feststellen

Verwenden Sie einen verifizierten DN, eine GUID oder einen SID, statt anzunehmen, dass der Anzeigename die beabsichtigte privilegierte Gruppe eindeutig identifiziert. Get-ADGroup unterstützt diese Identitäten und den expliziten Abruf von Eigenschaften:

$server = 'dc01.example.com'
$groupIdentity = 'CN=Schema Admins,CN=Users,DC=example,DC=com'
$group = Get-ADGroup -Identity $groupIdentity -Server $server -Properties member -ErrorAction Stop
$group | Select-Object DistinguishedName, SID, GroupScope, GroupCategory, member

Wählen Sie für dieses Beispiel einen DC in der Gesamtstruktur-Stammdomäne, die Schema Admins enthält, und ersetzen Sie den DN entsprechend. Dokumentieren Sie den zurückgegebenen SID und gleichen Sie ihn mit dem maßgeblichen Gruppeninventar ab. Wenn Sie stattdessen eine Operatorgruppe prüfen, wählen Sie deren tatsächliche Identität und Domäne. Bewahren Sie den Identitätsnachweis auch dann auf, wenn das Auslesen der Mitgliedschaft ein leeres Ergebnis liefert.

Schritt 2: Direkte und rekursive Ergebnisse getrennt aufbewahren

Get-ADGroupMember akzeptiert einen expliziten Server und eine Gruppenidentität. Der rekursive Modus erweitert die Hierarchie bis zu Mitgliedern ohne untergeordnete Objekte. Bewahren Sie das nichtrekursive Ergebnis auf, um Gruppenobjekte zu erkennen, die ein abgeflachtes Ergebnis nicht erhält:

$direct = @(Get-ADGroupMember -Identity $group.DistinguishedName -Server $server -ErrorAction Stop)
$direct | Select-Object DistinguishedName, objectClass, SID

$recursive = @(Get-ADGroupMember -Identity $group.DistinguishedName -Server $server -Recursive -ErrorAction Stop)
$recursive | Select-Object DistinguishedName, objectClass, SID

Behandeln Sie diese Ergebnisse als getrennte Nachweismengen, nicht als austauschbare Zählwerte. Wenn ein direktes Ergebnis eine Gruppe enthält, prüfen Sie deren Identität und Mitgliedschaft auf dem geeigneten DC. Eine leere verschachtelte Gruppe ist weiterhin ein direktes Mitglied ihrer übergeordneten Gruppe. Eine rekursive Ausgabe ohne Konten darf diese Beziehung nicht aus dem Prüfprotokoll entfernen.

-ErrorAction Stop zeigt einen Fehler an und stoppt den Befehl; nichtterminierende Fehler werden zu terminierenden Fehlern hochgestuft. Wenn ein Befehl fehlschlägt, beenden Sie diese Messung und bewahren Sie den Fehler auf; verwenden Sie nicht den Inhalt einer früheren Variablen als neues Ergebnis. Ein erfolgreicher Befehl bleibt ein Nachweis für den gewählten Server und den lesbaren Umfang, keine uneingeschränkte Bestätigung für jede Domäne oder Vertrauensstellung. Die Microsoft-Dokumentation zu Get-ADGroupMember schließt außerdem Active Directory-Momentaufnahmen sowie Gruppen mit Mitgliedern in einer anderen Gesamtstruktur aus, wenn diese Gesamtstruktur keinen Active Directory Web Service hat. Dokumentieren Sie beide Einschränkungen als ungeklärten Lesevorgang, nicht als leere Gruppe.

Schritt 3: primaryGroupID auslesen, soweit relevant

Bei einer verifizierten Domänensicherheitsgruppe kann eine Prüfung auf Kontoseite primaryGroupID mit dem RID dieser Gruppe vergleichen. Beschränken Sie die Abfrage auf die durch den Gruppen-SID repräsentierte Domäne: Der RID allein ist keine gesamtstrukturweite Identität. Wenden Sie dieses Beispiel für Domänengruppen nicht mechanisch auf einen SID aus dem Builtin-Container an.

Das folgende Beispiel verwendet die dokumentierten Parameter LDAPFilter, SearchBase, Server und Properties von Get-ADObject, kombiniert mit der Schemadefinition von primaryGroupID:

$domainBase = 'DC=example,DC=com'
$rid = $group.SID.Value.Split('-')[-1]
$primaryMembers = @(Get-ADObject -LDAPFilter "(primaryGroupID=$rid)" -SearchBase $domainBase -SearchScope Subtree -Server $server -Properties primaryGroupID,objectSid -ErrorAction Stop)
$primaryMembers | Select-Object DistinguishedName, objectClass, objectSid, primaryGroupID

Dies ist eine Prüf-Abfrage, kein Skript zur Korrektur der primären Gruppe. Stellen Sie vor der Interpretation der Ausgabe ihre Anwendbarkeit und die lesbare Objektpopulation fest. Berücksichtigen Sie bei verschachtelten Domänengruppen auch die relevanten Nachweise auf Kontoseite auf diesen Ebenen; nehmen Sie nicht an, dass das rekursive Ergebnis der obersten Ebene jede Frage zur primären Gruppe beantwortet. Wenn die Population oder die Sichtbarkeit der Attribute unvollständig ist, halten Sie diese Einschränkung in der Schlussfolgerung fest.

Behebung: Nachweislücken vor dem Abschluss klären (Remediation)

Behebung bedeutet hier, die Unsicherheit der Prüfung zu beseitigen oder die beabsichtigte Konfiguration zu dokumentieren. Änderungen der Mitgliedschaft erfordern eine separate Begründung. Folgen Sie nach dem Erfassen der Identitäts- und Mitgliedschaftsnachweise dieser Reihenfolge.

1. Ungeklärte Lesevorgänge aufklären. Untersuchen Sie den dokumentierten Fehler, die Erfassungsidentität, die Sichtbarkeit der Attribute, den Suchumfang und die Objektbegrenzungen. Wenn rohes LDAP Mitgliedschaftsattribute mit Bereichsangaben zurückgibt, verwenden Sie einen Abrufweg, der diese Bereiche verarbeitet, und bewahren Sie den Nachweis seiner Vollständigkeit auf. Wiederholen Sie den relevanten Lesevorgang auf dem dokumentierten DC, sobald das Erfassungsproblem behoben ist.
2. Bestätigte Mitglieder abgleichen. Wenn die native Prüfung Mitglieder zurückgibt, während der Collector eine leere Liste meldet, bewahren Sie beide Ausgaben mit ihren Erfassungszeitpunkten und Identitäten auf. Untersuchen Sie den Unterschied, bevor Sie den Befund klassifizieren. Entfernen Sie keine gültigen Mitglieder, um Übereinstimmung mit einem unvollständigen Export zu erzwingen.
3. Beabsichtigte Leere dokumentieren. Lassen Sie den Gruppenverantwortlichen den betrieblichen Zweck, den genehmigten leeren Zustand und das Verfahren für eine spätere Nutzung bestätigen. Fügen Sie dieser Entscheidung die verifizierte Identität und den Leseumfang bei. Dokumentieren Sie bei einer Operatorgruppe ohne Standardmitglieder, warum der aktuelle Zustand zum lokalen Administrationsmodell passt.
4. Unerwartete Leere eskalieren. Wenn der Verantwortliche aktive Administratoren oder eine dokumentierte verschachtelte Gruppe erwartet hat, untersuchen Sie die Abweichung über das Änderungsverfahren der Organisation. Befüllen Sie die Gruppe nicht automatisch aus einem alten Export und fügen Sie keine breit gefasste Identität als schnelle Umgehungslösung hinzu.
5. Den Abschlussnachweis aufbewahren. Halten Sie Verantwortlichen, Entscheidung, Nachweisdatum, DC, Gruppen-SID, Befehle, Fehler und ungeklärte Abdeckungsgrenzen fest. Definieren Sie, wann die Entscheidung erneut geprüft werden muss, etwa bei einer Änderung des Administrationsmodells oder einer neuen Abweichung in den erfassten Nachweisen.

Der ergänzende Leitfaden über gefährliche Überbelegung privilegierter Gruppen und beabsichtigte Leere von Schema Admins erläutert, warum das Befüllen einer privilegierten Gruppe keine angemessene Reaktion auf diesen Info-Befund ist. Trennen Sie die dortige Diskussion der Zugriffsrisiken von der hier behandelten Entscheidung über die Vollständigkeit der Nachweise.

Beispielsweise könnte ein Prüfer für eine Operatorgruppe eine leere Collector-Liste erhalten. Wenn die Identität übereinstimmt, die unabhängigen Lesevorgänge im erforderlichen Umfang abgeschlossen sind und der Verantwortliche bestätigt, dass keine Operatoren vorgesehen sind, kann die Entscheidung den leeren Zustand bewahren. Tritt bei derselben Prüfung ein ungeklärter Lesefehler auf, lautet das korrekte Ergebnis unbekannte Mitgliedschaft mit einer benannten Folgemaßnahme. Dies sind beispielhafte Entscheidungen, keine beobachteten Testergebnisse.

Wie EtcSec dies erkennt

Der EtcSec-Detektor GROUP_EMPTY_PRIVILEGED erzeugt einen Info-Befund für erkannte privilegierte Gruppen, deren erfasste Member-Liste die Bedingung len(Member) == 0 erfüllt. Die geprüfte etc-collector-Revision ist 20268a321609c193b79c5da6764f3f56950449cb; der Detektor liegt unter public/internal/audit/detectors/ad/groups/privileged/empty-privileged.go.

Er erkennt zehn englische Namen: Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Server Operators, Backup Operators, Print Operators, DnsAdmins und Group Policy Creator Owners. Er vergleicht sAMAccountName ohne Beachtung der Groß- und Kleinschreibung, greift bei leerem sAMAccountName auf DisplayName zurück oder findet eine cn=-Namenszeichenfolge an beliebiger Stelle im DN. Er verifiziert weder einen SID noch eine RDN-Grenze. Umbenannte oder lokalisierte Gruppen können übersehen werden; eine Namensübereinstimmung allein belegt keine integrierte Identität.

Das Prädikat führt weder eine Erweiterung verschachtelter Mitgliedschaften noch eine primaryGroupID-Berechnung durch. Im geprüften LDAP-Provider verwendet die Gruppenerfassung standardmäßig (objectClass=group) innerhalb des konfigurierten BaseDN und der Objektbegrenzung. Der Parser liest exakt member, ohne Werte aus member;range=... zusammenzuführen. Ein fehlendes exaktes Attribut wird zu einer leeren Liste. Objekt-Paging behebt diese Lücke beim Attributabruf nicht.

Diese Codebeobachtungen belegen ein Risiko unvollständiger Interpretation, keinen nachgewiesenen Fehlalarm in einer laufenden AD-Umgebung. Für diesen Artikel wurden keine AD-Tests ausgeführt. Die allgemeine Empfehlung des Detektors erwähnt das Entfernen ungenutzter Gruppen; sie darf nicht auf integrierte Gruppen angewendet werden. Nutzen Sie den Info-Befund, um die oben beschriebene Prüfung von Identität, Vollständigkeit und Verantwortlichenentscheidung anzustoßen.