AD Computer adminCount Triage: Geschützte DCs und Mitgliedshosts

Was ist AD Computer adminCount Triage?

AD Computer adminCount Triage bezeichnet die Untersuchung, warum ein maschinenbezogenes Verzeichnisobjekt adminCount=1 trägt, bevor entschieden wird, ob etwas geändert werden muss. Ein Domänencontroller, ein Dienstkonto und ein gewöhnlicher Mitgliedsserver können in derselben Kandidatenliste erscheinen, obwohl sie sehr unterschiedliche Entscheidungen erfordern. Das sinnvolle Ergebnis ist eine Klassifizierung, die durch Nachweise zu Identität, Mitgliedschaften und Berechtigungen gestützt wird.

Microsofts Schemareferenz zu Admin-Count beschreibt ein Attribut im Zusammenhang mit dem ACL-Schutz nach direkter oder transitiver Mitgliedschaft in administrativen Gruppen. Der Marker allein belegt weder aktuelle Privilegien noch einen Angriffspfad oder eine veraltete ACL. Er ist ein Anlass, das Objekt zu untersuchen, keine Aufforderung, einen Wert zu löschen.

Dieser Ablauf erstellt für jede SID einen Datensatz: geschützt, begründete Ausnahme, plausibler Überrest oder unbestimmt. Er ergänzt unseren Ablauf zur Bereinigung veralteter adminCount-Werte bei Benutzerkonten, der ausdrücklich verlangt, Computer und Gruppen getrennt zu klassifizieren. Seine Bereinigungsbefehle für Benutzer dürfen nicht zu einem Rezept für die Massenwartung von Maschinen werden.

Wie sich der Schutz auf DCs, RODCs und andere Objekte auswirkt

Microsofts Anhang C: Geschützte Konten und Gruppen führt sowohl Domain Controllers als auch Read-only Domain Controllers in der Liste geschützter Gruppen auf. AdminSDHolder stellt Berechtigungen als Vorlage bereit, und SDProp vergleicht die Berechtigungen geschützter Objekte mit dieser Vorlage. Bei geschützten Objekten ist die Vererbung deaktiviert; das Verschieben in eine andere OU hebt den Schutz nicht auf.

Ein verifizierter DC oder RODC kann daher eine legitime Erklärung für seinen Schutz haben. Ermitteln Sie seine tatsächliche Rolle und Mitgliedschaft, statt jeden Maschinenmarker als versehentlichen administrativen Zugriff zu behandeln. Untersuchen Sie bei einer Mitgliedsarbeitsstation oder einem Anwendungsserver die aktuellen Gruppenpfade und ihren geschäftlichen Zweck. Weder Hostname noch OU-Position reichen als Nachweis der Rolle aus.

Auch die Computersuche des Collectors ist relevant: Sie verwendet (objectClass=computer). In der geprüften Revision erkennt der Parser innerhalb dieser Population ausdrücklich msDS-GroupManagedServiceAccount. Ein gMSA kann daher als Computer-Befund erscheinen, ohne ein gewöhnlicher Host zu sein. Bestätigen Sie die zurückgegebene strukturelle Klasse und den Dienstverantwortlichen; gewähren Sie keine pauschale Ausnahme allein deshalb, weil es sich um ein Dienstkonto handelt.

Microsofts historische Erklärung zu AdminSDHolder und SDProp dokumentiert verbleibende Marker und deaktivierte Vererbung, nachdem ein Benutzer eine geschützte Mitgliedschaft verlassen hat. Das erklärt, warum ein Überrest eine prüfenswerte Hypothese ist. Es belegt nicht, dass ein bestimmter Computer verwaist ist; die ältere Liste geschützter Gruppen darf den aktuellen Anhang C nicht ersetzen. Derselbe Artikel beschreibt Schutz durch verschachtelte Sicherheits- oder Verteilergruppen, weshalb eine Mitgliedschaftsuntersuchung diese Pfade erhalten sollte.

Erkennung: Identität und unabhängige Verzeichnisnachweise erfassen

Beginnen Sie mit Get-ADComputer, dessen dokumentierte Parameter -LDAPFilter, -SearchBase, -Server und -Properties umfassen. Diese Anpassung fordert die Attribute an, die zur Untersuchung der Computerkandidaten benötigt werden:

Get-ADComputer -LDAPFilter "(adminCount=1)" -SearchBase "DC=corp,DC=example" -Server "dc01.corp.example" -Properties adminCount,memberOf,primaryGroupID,PrimaryGroup,nTSecurityDescriptor,Enabled,SID,ObjectClass,userAccountControl

Diese unabhängige Abfrage behält bewusst aktivierte und deaktivierte Ergebnisse zur Klassifizierung bei. Die unten erläuterte EtcSec-Prüfung wählt ausschließlich aktivierte Computer-Einträge aus. Dokumentieren Sie den Aktivierungsstatus ausdrücklich beim Abgleich beider Populationen; ein unterschiedlicher Umfang bedeutet nicht zwangsläufig eine Abweichung beim Marker.

Verwenden Sie SID und DN, um den Befund dem Verzeichnisobjekt zuzuordnen. Bewahren Sie auch seine GUID als weiteres Identifikationsmerkmal auf, außerdem seine Klasse, die abgefragte Domäne und den Server, den Erfassungszeitpunkt sowie fehlgeschlagene Lesevorgänge. Bewahren Sie die unverarbeiteten Attributnachweise auf, nicht nur eine formatierte Bildschirmausgabe. Ein leeres Ergebnis aus einer engeren Suchbasis klärt einen andernorts erfassten Befund nicht.

Verwenden Sie bei einem Kandidaten, der als gMSA vermutet wird, einen klassenneutralen Lesevorgang mit der exakten DN. Get-ADObject dokumentiert die Identifikation über DN und zusätzliche Eigenschaften:

Get-ADObject -Identity "CN=svcInventory,CN=Managed Service Accounts,DC=corp,DC=example" -Server "dc01.corp.example" -Properties objectClass,objectSid,adminCount,memberOf,primaryGroupID,nTSecurityDescriptor,userAccountControl

Vergleichen Sie diese Identität mit dem Befund, bevor Sie den Prüfpfad für Hosts oder Dienstkonten wählen. Eine fehlgeschlagene computerspezifische Suche darf ein Objekt, das der breitere Klassenfilter des Collectors zurückgegeben hat, nicht stillschweigend verwerfen.

Behebung: Jedes Objekt vor der Freigabe von Änderungen klassifizieren (Remediation)

Schritt 1 — Die Referenz geschützter Gruppen ermitteln

Lösen Sie die relevanten Gruppen aus Anhang C in den betroffenen Domänen und der Gesamtstruktur-Stammdomäne auf und dokumentieren Sie ihre SIDs und DNs. Namen können umbenannt oder lokalisiert sein. Microsofts SID-Referenz erklärt Domänenkennungen und relative Kennungen; verwenden Sie verifizierte Gruppenidentitäten statt eines reinen Namensvergleichs.

Get-ADGroup akzeptiert eine SID für -Identity und unterstützt zusätzliche Eigenschaften. Diese dokumentierte Anpassung liest die integrierte Gruppe Administrators in einem ausdrücklich angegebenen Domänenkontext:

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

Wiederholen Sie dies für die relevanten geschützten Gruppen mit deren verifizierten SIDs. Dieses Beispiel ist eine einzelne Abfrage, kein vollständiges Inventar geschützter Gruppen. Trennen Sie direkt geschützte Konten von Mitgliedschaftsgruppen und dokumentieren Sie relevante Ausnahmen in der Domänenkonfiguration. Eine ungeklärte Referenzgruppe lässt die Untersuchung unvollständig.

Schritt 2 — Mitgliedschaften über die erste Ansicht hinaus auflösen

Get-ADPrincipalGroupMembership unterstützt Computer, Gruppen und Dienstkonten. Die Beispiel-SID ist ein Platzhalter für die verifizierte SID des Kandidaten:

Get-ADPrincipalGroupMembership -Identity "S-1-5-21-111111111-222222222-333333333-1101" -Server "dc01.corp.example"

Microsoft dokumentiert, dass die Gruppensuche einen globalen Katalog benötigt und lokale Gruppen in einer anderen Domäne den passenden Ressourcenkontext erfordern. Dokumentieren Sie nicht terminierende Fehler als fehlgeschlagene Auflösung der Mitgliedschaft, statt eine Teilausgabe als unauffälliges Ergebnis zu akzeptieren. Fragen Sie die relevanten Ressourcendomänen ab, wenn das Objekt dort Mitgliedschaften besitzt.

Verwenden Sie die zurückgegebenen Gruppen und die memberOf-Nachweise des Objekts als Ausgangspunkte. Lesen Sie für jede Gruppe ihre übergeordneten Gruppen mit Get-ADGroup -Properties memberOf,groupType und setzen Sie die Untersuchung fort, bis die Pfade enden oder die verifizierte Menge geschützter Gruppen erreichen. Bewahren Sie die Identitäten der Zwischenstationen auf, behandeln Sie Zyklen und decken Sie die betroffenen Domänen ab. Ein einzelner Cmdlet-Aufruf wird hier nicht als vollständige, validierte transitive Traversierung dargestellt.

Schritt 3 — Die primäre Gruppe separat auflösen

Microsofts Protokollreferenz zu primaryGroupID erklärt, dass die primäre Mitgliedschaft in memberOf des Objekts und in der gewöhnlichen member-Liste der Gruppe fehlt. Die Get-ADComputer-Dokumentation zeigt außerdem PrimaryGroup und primaryGroupID in ihrer Computerausgabe.

Lesen Sie einen verifizierten Computer erneut und lösen Sie die DN seiner primären Gruppe unabhängig auf:

$machine = Get-ADComputer -Identity "CN=APP01,OU=Servers,DC=corp,DC=example" -Server "dc01.corp.example" -Properties PrimaryGroup,primaryGroupID,memberOf,adminCount,nTSecurityDescriptor

Get-ADGroup -Identity $machine.PrimaryGroup -Server "dc01.corp.example" -Properties memberOf,groupType

Führen Sie den zweiten Lesevorgang nur aus, wenn PrimaryGroup erfolgreich aufgelöst wurde. Ist nur die RID verfügbar, bilden Sie die SID der primären Gruppe aus der verifizierten Kontodomänen-SID und dieser RID und lösen Sie anschließend die vollständige SID auf. Setzen Sie nicht die vollständige Computer-SID ein und leiten Sie keine erwartete primäre Gruppe allein aus der Maschinenrolle ab. Prüfen Sie auch die übergeordneten Pfade der primären Gruppe selbst. Fehlende oder widersprüchliche Nachweise halten den Fall unbestimmt.

Schritt 4 — Berechtigungen des Objekts und seines übergeordneten Objekts untersuchen

Bewahren Sie den Sicherheitsdeskriptor auf und prüfen Sie Vererbung, Eigentümerschaft und explizite ACEs. Vergleichen Sie das Objekt mit seiner vorgesehenen Rolle und dem Referenzzustand des übergeordneten Objekts. Berechtigungsschutz kann legitim sein; umgekehrt erklärt ein bekannter Marker keine verdächtige explizite Berechtigungsvergabe.

Microsofts Dsacls-Referenz dokumentiert die Anzeige der ACL und die Verwendung von /A, um Informationen zu Eigentümerschaft und Überwachung hinzuzufügen. Dies sind getrennte Leseoperationen:

dsacls "\\dc01.corp.example\CN=APP01,OU=Servers,DC=corp,DC=example" /A

dsacls "\\dc01.corp.example\OU=Servers,DC=corp,DC=example" /A

Ein Zugriffsfehler bedeutet, dass der angeforderte Nachweis nicht verfügbar ist. Eine Textaufzeichnung ist ein Untersuchungsartefakt, keine Garantie für eine wiederherstellbare Sicherung. Legen Sie vor jeder späteren ACL-Wartung das freigegebene Wiederherstellungsverfahren fest.

Unsere Prüfung von Computerobjekten auf Rechte, Delegierung und gefährliche Gruppen erklärt die umfassendere Angriffsfläche von Maschinen. Diese Risiken erfordern eigene Nachweise: adminCount=1 allein belegt keines davon. Halten Sie die ACL des Objekts, seine Mitgliedschaften und etwaige Rechte an anderer Stelle im Prüfdatensatz getrennt fest.

Schritt 5 — Die Entscheidung dokumentieren und das vorgesehene Ergebnis validieren

Eine begründete Ausnahme ist eine geschäftliche Entscheidung; sie macht ein geschütztes Objekt nicht ungeschützt. Ein plausibler Überrest ist eine Untersuchungsklassifizierung, keine Erlaubnis zur Bereinigung. Leiten Sie jede vorgeschlagene Mitgliedschafts- oder ACL-Änderung mit dem erfassten Referenzzustand und den erwarteten endgültigen Berechtigungen an den Maschinen- oder Dienstverantwortlichen weiter.

Wiederholen Sie nach freigegebener Wartung die Lesevorgänge für Identität, Mitgliedschaften und ACL auf den dokumentierten Servern. Berücksichtigen Sie die Verzeichnisreplikation und beobachten Sie, sofern Schutz greift, das nachfolgende SDProp-Ergebnis gemäß dem konfigurierten Zeitplan. Dokumentieren Sie Erfolg oder Fehler und testen Sie das vorgesehene Administrations- oder Dienstverhalten. Löschen Sie einen Marker nicht wiederholt, um ein ungeklärtes Ergebnis zu unterdrücken.

Wie EtcSec dies erkennt

In Collector-Revision 9f698083354a1cb7f625df5cb490a515823c3257 durchläuft die geprüfte Kontrolle COMPUTER_ADMIN_COUNT die erfassten Computer-Einträge, überspringt deaktivierte Einträge und wählt diejenigen aus, deren boolescher Wert AdminCount wahr ist. Sie erzeugt einen Info-Befund mit der ausgewählten Anzahl; Details zu betroffenen Entitäten werden nur aufgenommen, wenn Details angefordert wurden und Kandidaten vorhanden sind.

Der LDAP-Parser setzt diesen booleschen Wert nur dann, wenn der zurückgegebene Wert von adminCount gleich 1 ist. Ein fehlender oder von 1 abweichender Wert wird in dieser Darstellung zu falsch. Die Prüfung schließt weder DCs noch RODCs oder gMSAs aus, löst keine direkten, transitiven oder primären Gruppenmitgliedschaften auf und untersucht keine ACLs. Sie liefert daher Kandidaten zur Klassifizierung, kein Urteil über veralteten Schutz oder gefährliche Privilegien.

Der Computer-Provider fordert primaryGroupID oder nTSecurityDescriptor in seiner Standardattributliste nicht an. Ihr Fehlen in dieser Erfassung darf nicht als Fehlen von Gruppen oder Rechten verstanden werden. BaseDN und MaxComputers begrenzen die erfasste Population; ein GetComputers-Fehler stoppt die Erfassung. Der Detektor liefert auch dann einen Info-Befund mit der Anzahl null, wenn keine Kandidaten ausgewählt wurden; das bloße Vorhandensein des Befundtyps ist daher kein Nachweis eines Treffers.

Gleichen Sie den Auditumfang und die Kandidatenidentitäten mit den oben beschriebenen unabhängigen Lesevorgängen ab. Erklären Sie anhand des Klassifizierungsdatensatzes legitimen Schutz, eskalieren Sie ungeklärte Hosts und bewahren Sie Unsicherheit. Ein erneutes Audit kann die Kandidatenliste innerhalb des erfassten Umfangs mit diesem Datensatz vergleichen, ersetzt aber weder die Auflösung von Mitgliedschaften noch die Validierung von Berechtigungen.