Veraltetes adminCount bereinigen: Sicherer AD-Ablauf

Veraltetes adminCount bereinigen: Was Sie in Active Directory korrigieren

Wenn Sie veraltetes adminCount bereinigen, besteht das betriebliche Ziel darin, eine zurückgebliebene administrative Kennzeichnung zu entfernen und die vorgesehene Berechtigungsvererbung für Konten wiederherzustellen, die geschützte Gruppen tatsächlich verlassen haben. Das gehört zur regelmäßigen Wartung nach Rollenwechseln und beim Ausscheiden von Mitarbeitern. Unser Leitfaden zu AdminSDHolder- und SDProp-Hintertüren behandelt ein anderes Szenario: Eine unbefugte ACE auf der Vorlage kann auf geschützte Objekte übertragen werden. Hier beginnt die Entscheidung mit der aktuellen Mitgliedschaft und der ACL des Kontos, ohne einen Angreifer vorauszusetzen.

Verschachtelungen prüfen, die Kennzeichnung löschen und die Vererbung aktivieren sind nur Teile dieses Ablaufs. Eine sichere Wartungsdokumentation sollte geschützte Gruppen anhand ihrer SID identifizieren, die primäre Gruppe gesondert auflösen, die übergeordnete OU prüfen, jedes Konto einzeln freigeben und das Ergebnis nach einem späteren SDProp-Zyklus verifizieren. Ein kleineres Inventar mit adminCount=1 ist nützlich, belegt aber nicht, dass die effektiven Berechtigungen korrekt sind.

Wie SDProp funktioniert und warum die Kennzeichnung bestehen bleibt

AdminSDHolder liefert die Berechtigungsvorlage für geschützte Objekte. SDProp vergleicht deren Berechtigungen auf dem PDC-Emulator (PDCE) jeder Domäne mit dieser Vorlage, standardmäßig alle 60 Minuten, und setzt Abweichungen zurück. Bei geschützten Objekten ist die Vererbung deaktiviert; ein Verschieben in eine andere OU hebt den Schutz nicht auf. Microsoft dokumentiert dies in Anhang C: Geschützte Konten und Gruppen. Die AdminSDHolder-Protokollspezifikation erklärt den regelmäßigen Schutz der Sicherheitsdeskriptoren.

Microsofts Schemareferenz zu Admin-Count beschreibt das Attribut als Aufzeichnung einer ACL, die nach direkter oder transitiver administrativer Mitgliedschaft verstärkt wurde. Es ist kein vollständiges Inventar aktueller Privilegien. Der historische Microsoft-Artikel zu AdminSDHolder und SDProp erklärt, dass nach dem Entfernen der geschützten Mitgliedschaft adminCount=1 und die deaktivierte Vererbung bestehen bleiben. Das ehemalige Mitglied erhält die Vorlagen-ACL nicht mehr, erbt aber weiterhin keine Berechtigungen vom übergeordneten Objekt.

Verwenden Sie die aktuelle Liste aus Anhang C statt der älteren Liste im historischen Artikel:

Administrator und Krbtgt sind Konten, keine Mitgliedschaftsgruppen. Dokumentieren Sie relevante Domänenkonfigurationen oder Ausnahmen auf Gesamtstrukturebene; ändern Sie dSHeuristics nicht, um die Bereinigung zu vereinfachen. Die Gruppe Protected Users ist eine separate Authentifizierungskontrolle; sie selbst wird nicht durch AdminSDHolder geschützt.

Falle 1: Nach dem direkten Entfernen bleibt ein verschachtelter Pfad

Der historische Microsoft-Artikel beschreibt transitiven Schutz, einschließlich Pfaden über Verteilergruppen. Ein aus Domain Admins entfernter Benutzer kann über eine andere Gruppe weiterhin eine geschützte Gruppe erreichen. Bleibt dieser Pfad bestehen, hebt das Löschen eines Attributs den Schutz nicht auf, und SDProp kann die aktivierte Vererbung wieder rückgängig machen. Versprechen Sie nicht, dass allein das Löschen der Kennzeichnung zwangsläufig dazu führt, dass sie beim exakt terminierten nächsten Zyklus erneut gesetzt wird; die belegte Schlussfolgerung lautet, dass die verbleibende Mitgliedschaft das Objekt weiterhin schützt.

Falle 2: Die Kennzeichnung verschwindet, die ACL bleibt jedoch falsch

Bei einem bestätigten ehemaligen Mitglied ändert das Löschen von adminCount die Vererbung nicht. Die Delegierung auf der übergeordneten OU erreicht das Konto daher möglicherweise weiterhin nicht. Das beweist nicht, dass die bestehende ACL des Kontos großzügiger ist: Stattdessen können vorgesehene Verwaltungsrechte fehlen. Umgekehrt kann das Aktivieren der Vererbung unter einer OU mit zu weitgehender Delegierung unerwünschte Berechtigungen hinzufügen. Explizite ACEs müssen ebenfalls gesondert geprüft werden; das Aktivieren der Vererbung entfernt sie nicht.

Erkennung: Ein Inventar der Kandidaten erstellen

Beginnen Sie mit einem schreibgeschützten Inventar. Get-ADObject dokumentiert -LDAPFilter, -Properties und -Server; diese Anpassung fragt die Kennzeichnung und den für die Untersuchung benötigten Zustand ab:

Get-ADObject -LDAPFilter "(adminCount=1)" -Properties adminCount,memberOf,objectSid,primaryGroupID,nTSecurityDescriptor -Server "dc-pdce.corp.example"

Die Ergebnisse können Gruppen und Computer enthalten. Klassifizieren Sie diese gesondert, statt den Ablauf für Benutzerkonten auf jedes zurückgegebene Objekt anzuwenden. Verwenden Sie für die Benutzerpopulation der beiden EtcSec-Prüfungen die dokumentierten Get-ADUser-Parameter:

Get-ADUser -LDAPFilter "(adminCount=1)" -Properties adminCount,memberOf,Enabled,SID,primaryGroupID -Server "dc-pdce.corp.example"

Ein leerer oder scheinbar gewöhnlicher memberOf-Wert ist ein Untersuchungsansatz, kein Beweis für ein verwaistes Konto. Die MemberOf-Schemaseite beschreibt Gruppen-DNs; diese Eigenschaft allein liefert nicht die nachfolgend erforderliche vollständige Schutzanalyse.

Dieser Ablauf erkennt einen Zustand des Verzeichnisses durch Abfragen und ACL-Prüfung. Er benötigt keine erfundene Ereignis-ID und behandelt eine frühere Gruppenentfernung nicht als Beleg dafür, dass das Konto aktuell gefahrlos geändert werden kann.

Behebung: Erst verifizieren, dann ein Konto ändern (Remediation)

Schritt 1 — Zustand des Kontos und des übergeordneten Objekts sichern

Erfassen Sie für jeden Kandidaten DN, SID, Aktivierungszustand, direkte Gruppen, RID der primären Gruppe, fachlich Verantwortlichen, vollständige ACL und Vererbungszustand. Dokumentieren Sie DC und Erfassungszeitpunkt. Halten Sie eine freigegebene Methode zur ACL-Wiederherstellung bereit; gespeicherte Textausgaben sind nützliche Nachweise, stellen aber keine Zusicherung einer wiederherstellbaren AD-Sicherung dar.

Die Microsoft-Referenz zu Dsacls dokumentiert die Anzeige von Zugriffseinträgen ohne Änderungen. Die Standardausgabe lässt Besitz- und Überwachungsinformationen aus; /A schließt diese Details beim Erfassen des vollständigen Sicherheitsdatensatzes ein. Führen Sie jede Leseoperation separat aus:

dsacls "\\dc-pdce.corp.example\CN=FormerAdmin,OU=Staff,DC=corp,DC=example"

dsacls "\\dc-pdce.corp.example\OU=Staff,DC=corp,DC=example"

Prüfen Sie das übergeordnete Objekt, bevor Sie die Vererbung zulassen. Bestimmen Sie, welche geerbten Rechte erscheinen sollen und welche expliziten Konto-ACEs bestehen bleiben müssen oder gesondert zu prüfen sind. Eine verdächtige ACL führt zur Untersuchung des Kontos statt zur automatischen Bereinigung.

Schritt 2 — Geschützte Gruppen anhand ihrer SID auflösen

Verwenden Sie Microsofts SID-Referenz, um die Domänenkennung von der RID zu unterscheiden. Lösen Sie jede geschützte Gruppe in der betreffenden Domäne auf; Gruppen der Gesamtstruktur benötigen die entsprechende Abdeckung der Gesamtstruktur-Stammdomäne. Umbenannte oder lokalisierte Gruppennamen reichen zur Identitätsprüfung nicht aus.

Get-ADGroup akzeptiert eine SID für -Identity. Die folgende domänenspezifische SID ist ein illustrativer Platzhalter, keine ermittelte Gruppe. Die SID der integrierten Gruppe Administrators wird ebenfalls gezeigt, mit explizitem Server zur Festlegung des Domänenkontexts:

Get-ADGroup -Identity "S-1-5-21-111111111-222222222-333333333-512" -Properties memberOf,groupType -Server "dc-pdce.corp.example"

Get-ADGroup -Identity "S-1-5-32-544" -Properties memberOf,groupType -Server "dc-pdce.corp.example"

Dokumentieren Sie für jeden Eintrag in der Schutzliste die aufgelöste SID und DN. Ein fehlgeschlagener Lookup hinterlässt eine Abdeckungslücke. Er ist nicht gleichbedeutend mit der Bestätigung, dass die Gruppe kein relevantes Mitglied enthält.

Schritt 3 — Rekursive Mitgliedschaft und primäre Gruppe prüfen

Die Get-ADGroupMember-Dokumentation enthält ein Beispiel für rekursive Mitgliedschaft. Passen Sie es an jede verifizierte SID einer geschützten Gruppe an und vergleichen Sie die zurückgegebenen Benutzer-SIDs mit dem Kandidaten:

Get-ADGroupMember -Identity "S-1-5-21-111111111-222222222-333333333-512" -Recursive -Server "dc-pdce.corp.example"

Wiederholen Sie dies für die gesamte Schutzliste und die relevanten Domänen. Berücksichtigen Sie Pfade über Verteilergruppen. -Recursive liefert Mitglieder in der Hierarchie zurück, die keine untergeordneten Objekte haben; es ist keine vollständige Liste der Verbindungen zwischen den zwischengeschalteten Gruppen. Microsoft dokumentiert außerdem eine Einschränkung für andere Gesamtstrukturen, wenn dort Active Directory Web Service fehlt. Fehlgeschlagene oder unvollständige Aufzählungen müssen zu einem unbestimmten Urteil führen.

Prüfen Sie die primäre Gruppe gesondert. Microsofts Primary-Group-ID-Referenz definiert den Wert als RID der primären Gruppe des Benutzers. Die primaryGroupID-Protokollreferenz bestätigt, dass diese Mitgliedschaft sowohl in memberOf des Benutzers als auch im Attribut member der primären Gruppe fehlt. Der geprüfte Collector bildet die SID der primären Gruppe aus der Domänen-SID und dieser RID. Lösen Sie die vollständige SID mit Get-ADGroup auf; leiten Sie die Antwort nicht aus einem lesbaren Gruppennamen ab.

Ermitteln Sie anschließend, ob die primäre Gruppe direkt geschützt ist oder durch Verschachtelung eine geschützte Gruppe erreicht. Diese dokumentierte Anpassung von Get-ADGroup liest die nächsten übergeordneten Gruppen:

Get-ADGroup -Identity "CN=PrimaryGroup,OU=Groups,DC=corp,DC=example" -Properties memberOf -Server "dc-pdce.corp.example"

Prüfen Sie jede übergeordnete Gruppe weiter, mit Behandlung von Zyklen und Abdeckung der betreffenden Domänen. Das Beispiel ist eine einzelne Leseoperation, kein vollständig validiertes Traversierungsprogramm. Fehlt der Kandidat in der Ausgabe rekursiver Mitglieder, entfällt dadurch nicht die Prüfung der primären Gruppe. Nicht aufgelöste fremde Mitglieder, nicht abgefragte Domänen oder ungelöste Zyklen verhindern die Freigabe eines Schreibzugriffs.

Schritt 4 — Die Entscheidung vor dem Schreiben dokumentieren

Die integrierten Konten Administrator und Krbtgt bleiben unabhängig davon geschützt, ob eine erklärende direkte Mitgliedschaft fehlt. Der geprüfte Collector identifiziert sie anhand der RIDs 500 und 502, auch nach einer Umbenennung. Ein deaktiviertes Konto, das weiterhin geschützt ist, gehört in die erste Zeile, nicht in die Zeile für verwaiste Konten. Entscheiden Sie bei einem bestätigt verwaisten deaktivierten Konto gemäß der Aufbewahrungsrichtlinie zwischen Wartung und Stilllegung; dieser Ablauf aktiviert es nicht automatisch wieder.

Schritt 5 — Nur das bestätigte Restattribut löschen

Set-ADObject dokumentiert -Clear mit dem LDAP-Anzeigenamen sowie -WhatIf und -Confirm. Prüfen Sie zunächst die einzelne Änderung in der Vorschau:

Set-ADObject -Identity "CN=FormerAdmin,OU=Staff,DC=corp,DC=example" -Clear adminCount -Server "dc-pdce.corp.example" -WhatIf

Erst nach Entscheidung und Prüfung führen Sie den separaten, bestätigten Schreibzugriff aus:

Set-ADObject -Identity "CN=FormerAdmin,OU=Staff,DC=corp,DC=example" -Clear adminCount -Server "dc-pdce.corp.example" -Confirm

-Clear entfernt den Wert; es schreibt nicht die Zahl null. Der Befehl entfernt keine Mitgliedschaften, ändert keine expliziten ACEs und aktiviert keine Vererbung. Eine erfolgreiche Vorschau sagt ebenfalls nichts darüber aus, ob der Kandidat tatsächlich verwaist ist.

Schritt 6 — Vererbung aktivieren und resultierende ACL prüfen

Die Dsacls-Referenz definiert /P:N als Erlaubnis für das Objekt, Berechtigungen vom übergeordneten Objekt zu erben. Wenden Sie dies nach der Prüfung des übergeordneten Objekts ausschließlich auf das freigegebene Objekt an:

dsacls "\\dc-pdce.corp.example\CN=FormerAdmin,OU=Staff,DC=corp,DC=example" /P:N

Prüfen Sie das Ausführungsergebnis und wiederholen Sie sofort die ACL-Leseoperation aus Schritt 1. Vergleichen Sie die geerbten Rechte mit dem freigegebenen Ausgangszustand des übergeordneten Objekts und prüfen Sie explizite Einträge unabhängig davon. /P:N ändert den Vererbungsschutz des Objekts; es ändert nicht die Vererbbarkeit einer ACE. Ersetzen Sie es nicht durch /S oder /S /T: /S stellt die schemadefinierte Standardsicherheit des Objekts wieder her, und /T erweitert diese Wiederherstellung nur in Verbindung mit /S auf den Verzeichnisbaum.

Validierung nach dem nächsten SDProp-Zyklus

Lesen Sie das Konto auf dem dokumentierten Server erneut aus, mit den oben dokumentierten Get-ADUser-Parametern:

Get-ADUser -Identity "CN=FormerAdmin,OU=Staff,DC=corp,DC=example" -Properties adminCount,memberOf,primaryGroupID,Enabled -Server "dc-pdce.corp.example"

Lesen Sie seine ACL separat aus:

dsacls "\\dc-pdce.corp.example\CN=FormerAdmin,OU=Staff,DC=corp,DC=example"

Wiederholen Sie auch die Auflösung der Mitgliedschaften: Sie können sich zwischen Inventarisierung und Wartung ändern. Warten Sie unter dem tatsächlich konfigurierten Intervall einen späteren SDProp-Durchlauf ab und berücksichtigen Sie die Replikation, bevor Sie DCs vergleichen. Dokumentieren Sie Prüfzeitpunkt und Server, das Fehlen der Restkennzeichnung, die erwartete Vererbung, die Prüfung expliziter ACEs und einen tatsächlichen Test der vorgesehenen Delegierung. Behaupten Sie „nach dem Zyklus validiert“ nur, wenn diese Beobachtung vorliegt.

Kehrt der Schutz zurück, untersuchen Sie einen verbleibenden Gruppenpfad, eine kürzlich hinzugefügte Mitgliedschaft oder eine unvollständige Erfassung. Wiederholtes Löschen des Attributs ist keine Lösung. Microsofts Anhang C beschreibt eine optionale Labormethode mit Ldp.exe auf dem PDCE und rootDSE RunProtectAdminGroupsTask=1. Bevorzugen Sie für diesen Wartungsablauf im Produktionsbetrieb den normalen Zyklus und lassen Sie seine Häufigkeit unverändert. Die Operation FixUpInheritance aus dem historischen Artikel sollte nicht automatisch anstelle dieser Aufgabe eingesetzt werden.

Unser Leitfaden zur Drift privilegierter Zugriffe erklärt, weshalb Gruppen- und ACL-Ausnahmen Verantwortliche sowie eine erneute Validierung anhand effektiver Rechte benötigen. Wenden Sie dieses Prinzip hier an: Die erfolgreiche Bereinigung der Kennzeichnung ist ein Wartungsergebnis; der Nachweis, dass die Berechtigungen des Kontos seiner vorgesehenen Rolle entsprechen, erfordert die umfassendere Rechteprüfung.

Wie EtcSec dies erkennt

Die beiden geprüften etc-collector-Prüfungen verwenden dasselbe Prädikat für verwaiste Konten auf Basis direkter oder primärer Mitgliedschaft, angewendet auf unterschiedliche Kontopopulationen:

Die normalisierten Auswahlblöcke unterscheiden sich nur durch if u.Disabled gegenüber if !u.Disabled; auch Titel, Schweregrad und Empfehlungen unterscheiden sich. Es handelt sich um zwei nach Kontozustand getrennte Varianten derselben Prüfung, nicht um unabhängige Mechanismen, die als Nachweis eines höheren Risikos zusammengezählt werden können.

Verschachtelte Mitgliedschaften werden nicht aufgelöst. Keine der beiden Prüfungen erweitert eine in eine geschützte Gruppe verschachtelte Gruppe, einschließlich einer selbst verschachtelten primären Gruppe. Solche Konten können weiterhin geschützt sein und fälschlich als verwaiste Kandidaten erscheinen. Die Hilfsfunktion löst DNs geschützter Gruppen anhand von SID-Suffixen im erfassten Index auf und vergleicht anschließend direkte DNs; fehlende Gruppen- oder SID-Daten können ebenfalls einen unerklärten Kandidaten hinterlassen.

Keine der beiden Detect()-Methoden liest die ACL oder den Vererbungszustand des Kontos. Ein Befund belegt daher keine gefährlichen Restberechtigungen, beweist nicht das Fehlen von SDProp-Schutz und autorisiert nicht das Löschen des Attributs. Bestätigen Sie ihn vor Änderungen mit dem Mitgliedschafts- und ACL-Ablauf. Führen Sie nach Wartung und Verzeichnisvalidierung das Audit erneut aus, um Kandidatenbefunde mit dem dokumentierten Ergebnis zu vergleichen.