Deaktivierte Abgelaufene Gesperrte Konten Privilegierte AD-Gruppen: Warum Admin-Rechte Bestehen Bleiben

Deaktivierte abgelaufene gesperrte Konten privilegierte AD-Gruppen ist genau die Lücke, die dieser Artikel behandelt: ein Konto, dessen eigener Zustand – deaktiviert, abgelaufen oder gesperrt – eigentlich sagt, dass es keinen Zugriff mehr haben sollte, das aber weiterhin formal Mitglied von Domain Admins, Enterprise Admins oder einer anderen Tier-0-Gruppe ist. Ein deaktiviertes Admin-Konto ist so gut wie immer ein vergessener Offboarding-Schritt. Ein abgelaufenes ist eine zeitlich befristete Zugriffsvergabe, die niemand aus der Gruppe entfernt hat, als die Frist ablief. Ein gesperrtes kann einfach ein Helpdesk-Ticket sein – oder das Ende einer noch laufenden Password-Spray-Attacke. Dieser Artikel behandelt alle drei Zustände sowie ihren nahen Verwandten, das verwaiste adminCount-Flag, und zeigt, wie man sie findet und behebt.

Deaktivierte Abgelaufene Gesperrte Konten Privilegierte AD-Gruppen: Die Vier Zustände

Jede dieser vier Bedingungen hat eine präzise Definition auf Attributebene, und jede hat ihre eigene Art, unbemerkt in einer privilegierten Gruppe zu landen, ohne dass jemand das so entschieden hat.

Das Deaktivierte Konto

Das ACCOUNTDISABLE-Bit (0x2) ist in userAccountControl gesetzt; das Konto kann sich nicht interaktiv anmelden. (Microsoft Learn: UserAccountControl property flags) Deaktivierte Konten häufen sich an, weil Offboarding-Checklisten meist bei „Konto deaktivieren" enden. Das blockiert die Anmeldung, ändert aber nichts an der Gruppenmitgliedschaft – die SID bleibt in Domain Admins. Jedes Angriffspfad-Tool, das kartiert „wer könnte Domain Admin werden" – BloodHound, PingCastle oder auch EtcSec –, zählt das Konto weiterhin, weil diese Graphen auf Gruppenmitgliedschaft basieren, nicht auf userAccountControl. Wird das Konto jemals wieder aktiviert – aus Versehen, durch ein verzögertes ITSM-Ticket oder durch einen Angreifer, der sich die Rechte verschafft hat, ein einzelnes Bit umzulegen –, ist sein altes Privileg sofort wieder wirksam, ohne weiteren Aufwand.

Das Abgelaufene Konto

accountExpires enthält einen Wert, der weder 0 noch der „läuft nie ab"-Sentinel 9223372036854775807 ist, und dieser Wert (ein Windows-FILETIME) liegt in der Vergangenheit. (Microsoft Learn: Account-Expires attribute) Dieses Attribut wird häufig für Auftragnehmer- oder befristete Eskalationskonten mit einem geplanten Enddatum verwendet. Der KDC verweigert die Ausstellung eines Ticket-Granting-Tickets nach diesem Datum, sodass das Konto für interaktive oder Netzwerk-Anmeldung nicht mehr funktioniert – aber auch accountExpires rührt die Gruppenmitgliedschaft nicht an. Wenn die eigentliche Absicht war „der Admin-Zugriff dieser Person endet an diesem Datum", blockiert das Setzen eines Ablaufdatums ohne gleichzeitige Entfernung aus der Gruppe nur die Vordertür.

Das Gesperrte Konto

lockoutTime ist ungleich null, und die Sperrdauer des Kontos ist noch nicht abgelaufen. Windows setzt niemals ein UF_LOCKOUT-Bit im gespeicherten userAccountControl-Wert selbst; der aktuelle Sperr-/Entsperrzustand wird über das konstruierte Attribut msDS-User-Account-Control-Computed offengelegt. (MS-ADLS: lockoutTime, MS-ADTS: msDS-User-Account-Control-Computed) Anders als Deaktivieren oder Ablaufen ist Sperrung keine administrative Entscheidung – sie ist eine Nebenwirkung fehlgeschlagener Anmeldeversuche, die auf die Kontosperrrichtlinie treffen. Ein privilegiertes Konto kann gesperrt sein, weil jemand tatsächlich ein Passwort falsch eingegeben hat, oder weil es gerade angegriffen wird: Ein Password-Spray- oder Brute-Force-Lauf, der ein privilegiertes Konto erreicht und kurz vor dem Erfolg steht, kann genau dieselbe Signatur erzeugen, unmittelbar bevor er sich authentifiziert.

Das Verwaiste adminCount-Flag

adminCount=1 kennzeichnet Mitglieder von AdminSDHolder-geschützten Gruppen, aber ein Konto kann dieses Flag tragen, obwohl es zu keiner geschützten Gruppe mehr gehört – der umgekehrte Fall: kein lebendiges Privileg bei einem toten Konto, sondern ein totes Kennzeichen, das von bereits entferntem Privileg übrig geblieben ist. Der Mechanismus dahinter ist der SDProp-Prozess, der auf dem Domänencontroller mit der PDC-Emulator-Rolle läuft (standardmäßig etwa einmal pro Stunde), die Mitgliedschaft geschützter Gruppen durchgeht, adminCount=1 auf jedem Mitglied setzt, die AdminSDHolder-ACL auf das Objekt kopiert und die ACL-Vererbung deaktiviert. (Microsoft Community Hub: Five common questions about AdminSDHolder and SDProp) Wird das Konto später aus der geschützten Gruppe entfernt, rührt SDProp es einfach nicht mehr an – es setzt adminCount nicht auf 0 zurück und stellt auch nicht die Vererbung wieder her. Das Flag und die abgekoppelte ACL bleiben als stiller, dauerhaft wirkender Marker für ein Privileg zurück, das das Konto nicht mehr besitzt.

Erkennung

Attribute und PowerShell-Abfragen

Direkte Mitgliedschaftsabfragen mit dem AD-PowerShell-Modul zeigen alle vier Zustände schnell:

# Deaktivierte Konten, die noch in einer privilegierten Gruppe sind
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Get-ADUser -Properties Enabled, userAccountControl |
    Where-Object { -not $_.Enabled }

# Abgelaufene Konten (accountExpires gesetzt und in der Vergangenheit — 0 und der
# Max-Int64-Sentinel bedeuten beide „läuft nie ab")
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Get-ADUser -Properties accountExpires |
    Where-Object {
        $_.accountExpires -gt 0 -and
        $_.accountExpires -lt 9223372036854775807 -and
        [datetime]::FromFileTime($_.accountExpires) -lt (Get-Date)
    }

# Aktuell gesperrte Konten, abgeglichen mit privilegierten Gruppen
Search-ADAccount -LockedOut -UsersOnly |
    Where-Object { (Get-ADPrincipalGroupMembership $_.SamAccountName).Name -contains "Domain Admins" }

# adminCount=1 ohne aktuelle Mitgliedschaft in einer geschützten Gruppe (verwaistes Flag)
Get-ADUser -LDAPFilter "(adminCount=1)" -Properties adminCount, memberOf, Enabled

LDAP-Filter für Raw-Bind-Tooling

Für Tools, die nicht über das AD-PowerShell-Modul laufen, nutzt die Prüfung des Deaktiviert-Bits die LDAP_MATCHING_RULE_BIT_AND-OID gegen userAccountControl:

(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))

Das entspricht AD's eigener bitweiser AND-Semantik: Die Klausel ist nur erfüllt, wenn das zweite Bit (0x2, ACCOUNTDISABLE) im gespeicherten Wert gesetzt ist. (MS-ADTS: LDAP_MATCHING_RULE_BIT_AND)

Windows Event-IDs zum Korrelieren

Diese Events werden auf Domänencontrollern unter Account-Management-Auditing protokolliert – die vollständige Referenz der AD-Monitoring-Event-IDs enthält das breitere Logging-Setup:

Quellen: Event ID 4725, Event ID 4740, Event ID 4767, Event ID 4738, Event ID 4728, Event ID 4756.

Remediation

Für Deaktivierte und Abgelaufene Konten

1. Machen Sie die Prüfung wiederkehrend, nicht nur Teil des Offboardings. Ein Leaver-Prozess, der das Konto beim Ausscheiden deaktiviert, erkennt kein Ablaufdatum, das schon vor sechs Monaten verstrichen ist. Planen Sie die obigen Abfragen oder eine gleichwertige SIEM-/EASM-Regel für regelmäßige Ausführung.
2. Koppeln Sie Offboarding an die Entfernung aus der Gruppe, nicht nur an das Deaktivieren des Kontos. Deaktivieren blockiert die Anmeldung; es widerruft nicht die Gruppenmitgliedschaft, die Angriffspfad-Graphen, delegierte Rechte und manche Anwendungslogik zur Autorisierung weiterhin auslesen. Wenn der Zugriff enden soll, entfernen Sie das Konto explizit aus der privilegierten Gruppe.
3. Behandeln Sie Ablaufdaten als Auslöser für eine Mitgliedschaftsprüfung, nicht als deren Ersatz. Wurde ein Konto zeitlich befristet in eine privilegierte Gruppe aufgenommen, setzen Sie eine entsprechende Erinnerung, die Mitgliedschaft am oder vor dem Ablaufdatum zu entfernen – verlassen Sie sich nicht allein auf accountExpires, um darzustellen, dass diese Person kein Admin mehr ist.

Für Gesperrte Privilegierte Konten

Da das Entsperren eines Kontos eine billige, schnelle und delegierbare Operation ist – ein eigenständiges AD-Recht, getrennt vom Zurücksetzen des Passworts –, ist ein gesperrtes Tier-0-Konto nur eine Entsperrung davon entfernt, wieder voll nutzbar zu sein. Leiten Sie Event-ID 4740 für Mitglieder geschützter Gruppen auf einen eigenen Alarmpfad, getrennt vom routinemäßigen Helpdesk-Sperrrauschen, und bestätigen Sie, dass die Entsperrung (Event-ID 4767) von einem erwarteten Administrator stammt, bevor Sie den Vorfall als abgeschlossen betrachten.

Für Verwaiste adminCount-Flags

Bestätigen Sie für jedes Konto mit adminCount=1, aber ohne aktuelle Mitgliedschaft in einer geschützten Gruppe, dass es tatsächlich nicht mehr privilegiert ist – prüfen Sie dabei auch verschachtelte Mitgliedschaften, nicht nur direkte, da eine Entfernung aus einer direkt zugewiesenen Gruppe indirektes Privileg noch bestehen lassen kann. Setzen Sie adminCount nach der Bestätigung zurück und aktivieren Sie die ACL-Vererbung wieder, anstatt das veraltete Flag und die abgekoppelte ACL stehen zu lassen – lässt man es stehen, verfälscht das jede künftige Berechtigungsprüfung an diesem Objekt.

Wie EtcSec Dies Erkennt

EtcSec prüft bei jedem Active-Directory-Audit auf alle vier Zustände: DISABLED_ACCOUNT_IN_ADMIN_GROUP und EXPIRED_ACCOUNT_IN_ADMIN_GROUP kennzeichnen Mitglieder privilegierter Gruppen, deren eigener Kontostatus ihren Zugriff eigentlich schon hätte blockieren sollen, LOCKED_ACCOUNT_ADMIN zeigt aktuell gesperrte privilegierte Konten für das oben beschriebene Password-Spray-Szenario, und ADMIN_COUNT_ORPHANED erfasst den umgekehrten Fall – das verbliebene adminCount=1-Kennzeichen, das übrig bleibt, nachdem eine geschützte Mitgliedschaft bereits entfernt wurde.