Kontoablauf in AD: Vor einer Verlängerung entscheiden

Kontoablauf in AD: Vor dem Stichtag entscheiden

Wer den Kontoablauf in AD prüft, macht aus bevorstehenden Endterminen für Zugriffe Entscheidungen mit klarer Verantwortung. Ein bald ablaufendes Konto kann einem Auftragnehmer gehören, dessen Einsatz endet, einem Mitarbeiter mit befristetem Zugriff oder einer Benutzeridentität, die eine Anwendung verwendet. Zunächst ist zu klären, ob das geplante Enddatum weiterhin stimmt. Jedes Konto aus einem Bericht zu verlängern, untergräbt den Zweck eines festgelegten Enddatums.

Eine Prüfung benötigt den Ablaufzeitpunkt, den verantwortlichen Eigentümer, den fortbestehenden geschäftlichen Bedarf und die Abhängigkeiten, die beendet oder übertragen werden müssen. Sie sollte alle relevanten Benutzergruppen abdecken. Privilegierte Mitgliedschaften beeinflussen die Dringlichkeit und die zu entziehenden Rechte, sind aber keine Voraussetzung für die Prüfung eines bevorstehenden Stichtags.

Ein bald ablaufendes Konto ist kein Beleg für eine Kompromittierung. Kontoablauf und Kennwortablauf sind ebenfalls getrennte Sachverhalte: Sie betreffen unterschiedliche Kontoeigenschaften und unterschiedliche betriebliche Probleme. Dieser Leitfaden schlägt einen Prüfablauf vor; er berichtet weder Ergebnisse aus einer produktiven Domäne noch schreibt er eine allgemeingültige Verlängerungsrichtlinie vor.

Wie accountExpires ein Enddatum abbildet

Das AD-Attribut accountExpires speichert Windows FILETIME: Intervalle von 100 Nanosekunden, gezählt ab dem 1. Januar 1601 UTC. Microsoft definiert zwei Werte für ein Konto, das nie abläuft: 0 und 9223372036854775807, auch als 0x7FFFFFFFFFFFFFFF geschrieben. Keiner dieser Werte ist ein zukünftiger Stichtag, der in einen Ablaufkalender gehört. Microsoft Learn: Attribut Account-Expires

Unterscheiden Sie den gespeicherten Zeitpunkt von einer geschäftlichen Anweisung wie „Der Zugriff endet am Freitag“. Klären Sie, ob der Eigentümer den Tagesbeginn, das Ende einer Schicht oder einen bestimmten UTC-Zeitpunkt meint. Halten Sie die vereinbarte Zeitzone und die genaue Uhrzeit vor einer Änderung fest. Ein Datum ohne diesen Kontext kann den Zugriff früher beenden als beabsichtigt.

Es gibt eine ausdrücklich benannte Überschneidung mit unserem Artikel über deaktivierte, abgelaufene und gesperrte Konten, die in privilegierten Gruppen verbleiben. Dort geht es um Konten, die bereits in einem ungültigen Zustand sind, während ihre privilegierten Mitgliedschaften fortbestehen. Diese Prüfung greift vor dem Ablauf, umfasst alle Benutzergruppen, weist die Entscheidung einer verantwortlichen Person zu und koordiniert die Zugriffsänderungen. Ist das Konto bereits abgelaufen, gehört es in den bestehenden Offboarding- und Mitgliedschaftsprüfprozess statt in die Liste bevorstehender Stichtage.

Der Leitfaden zur Lebensdauer von Kerberos-Tickets und zur Begrenzung bestehender Verbindungen erklärt, warum Kontozustand, ausgestellte Tickets und authentifizierte Verbindungen jeweils eigene Nachweise erfordern. Berücksichtigen Sie diese Unterscheidung bei der Planung eines Zugriffsendes. Eine gewöhnliche Ablaufprüfung ist kein Vorfallbefund und rechtfertigt keine Annahme eines Ticketdiebstahls.

Erkennung: Ein Inventar der Ablaufdaten erstellen

1. Den Umfang festlegen und einen ausdrücklichen Zeithorizont verwenden

Beginnen Sie mit Domäne, Verzeichnisserver, Suchbasis und Referenzzeit. Dokumentieren Sie den Prüfhorizont als lokale betriebliche Entscheidung. Die folgenden Beispiele erfordern das ActiveDirectory PowerShell-Modul und einen autorisierten Verzeichniskontext. Es sind aus der Dokumentation abgeleitete Beispielbefehle, keine gegen eine AD-Umgebung ausgeführten Befehle. Ersetzen Sie sämtliche Beispielserver, DNs und Identitäten durch überprüfte Werte.

Microsoft dokumentiert Search-ADAccount -AccountExpiring entweder mit -TimeSpan für einen Zeitraum ab dem aktuellen Zeitpunkt oder mit -DateTime für einen Stichtag. -UsersOnly beschränkt die Objektpopulation auf Benutzer. Das folgende Beispiel wählt einen Berichtshorizont von dreißig Tagen; diese Wahl ist keine Microsoft-Anforderung. Microsoft Learn: Search-ADAccount

$server = 'dc01.example.com'
$searchBase = 'OU=People,DC=example,DC=com'
Search-ADAccount -AccountExpiring -UsersOnly -TimeSpan '30.00:00:00' -Server $server -SearchBase $searchBase |
    Select-Object DistinguishedName, Name, Enabled, AccountExpirationDate

Für eine geplante Prüfung lässt sich ein absoluter Stichtag unter Umständen leichter reproduzieren. Dieses separate Beispiel erzeugt einen UTC-DateTime-Wert, statt sich auf eine vom Gebietsschema abhängige Datumszeichenfolge zu verlassen:

$deadlineUtc = [datetime]::new(2026, 11, 3, 18, 0, 0, [DateTimeKind]::Utc)
Search-ADAccount -AccountExpiring -UsersOnly -DateTime $deadlineUtc -Server $server -SearchBase $searchBase |
    Select-Object DistinguishedName, Name, Enabled, AccountExpirationDate

Verwenden Sie pro Abfrage nur eine Form des Zeithorizonts. Bewahren Sie neben dem Stichtag auch den Abfragezeitpunkt auf: Eine später ausgeführte relative Abfrage hat ein anderes Zeitfenster. Diese Cmdlet-Suchen liefern Ausgangsdaten für die Untersuchung; sie beanspruchen nicht, die strikten Grenzvergleiche von EtcSec nachzubilden. Prüfen Sie die zurückgegebenen Daten und den Aktivierungszustand, bevor Sie eine Maßnahme zuweisen.

2. Das Rohattribut lesen und die Daten normalisieren

Rufen Sie accountExpires ausdrücklich mit Get-ADUser -Properties ab. Microsoft dokumentiert zusätzliche LDAP-Attribute über diesen Parameter sowie -SearchBase und -Server zur Auswahl des Verzeichniskontexts. Microsoft Learn: Get-ADUser

Dieses beispielhafte Inventar bewahrt den Rohwert auf und meldet den Konvertierungsstatus. Es unterscheidet bewusst einen nicht verfügbaren oder ungültigen Wert von einem dokumentierten Sentinelwert für ein nie ablaufendes Konto:

Get-ADUser -Filter * -Server $server -SearchBase $searchBase -Properties accountExpires,manager,description |
    ForEach-Object {
        $raw = $_.accountExpires
        $expiryUtc = $null
        $state = 'Missing or invalid'
        if ($null -ne $raw -and [string]$raw -ne '') {
            try {
                $value = [long]$raw
                if ($value -eq 0 -or $value -eq [long]::MaxValue) {
                    $state = 'Never expires'
                } else {
                    $expiryUtc = [datetime]::FromFileTimeUtc($value)
                    $state = 'Dated'
                }
            } catch {
                $state = 'Missing or invalid'
            }
        }
        [pscustomobject]@{
            DistinguishedName = $_.DistinguishedName
            Enabled = $_.Enabled
            RawAccountExpires = $raw
            ExpirationUtc = $expiryUtc
            DateState = $state
            Manager = $_.Manager
            Description = $_.Description
        }
    }

FromFileTimeUtc wandelt eine Dateizeit in einen UTC-DateTime-Wert um und weist Eingaben außerhalb des gültigen Bereichs zurück. Die beiden Sentinelwerte für nie ablaufende Konten werden vor der Konvertierung behandelt. Die Fehlerbezeichnungen dieses Beispiels sind vorgeschlagene Prüflabels, keine Ausgaben des Collector-Parsers. Microsoft Learn: DateTime.FromFileTimeUtc

Die Verzeichnisfelder manager und description sind Anhaltspunkte für die Suche nach einem Eigentümer, kein Beleg dafür, dass die benannte Person den Zugriff genehmigt hat. Bestätigen Sie den verantwortlichen Eigentümer anhand des aktuellen Vertrags, des Zugriffsantrags oder des Servicedatensatzes. Lassen Sie ungeklärte Zuständigkeiten sichtbar, statt ein leeres Feld als Erlaubnis zur Verlängerung zu behandeln.

3. Aus Daten ein Register mit konkreten Maßnahmen machen

Bewahren Sie für jede Identität im Prüfumfang den stabilen Bezeichner, das Rohattribut, den normalisierten Ablaufzeitpunkt, den Aktivierungszustand, den Prüfzeitstempel und die Verzeichnisquelle auf. Ergänzen Sie das geschäftliche Enddatum, den Eigentümer, Abhängigkeiten, die Entscheidung und die Änderungsreferenz. Halten Sie bereits abgelaufene Konten, nie ablaufende Konten und nicht lesbare Daten von der Warteschlange bevorstehender Stichtage unterscheidbar.

Eine Anwendungsabhängigkeit sollte zu einer Aufgabe für den jeweiligen Serviceverantwortlichen werden. Sie darf eine befristete Identität nicht stillschweigend in eine dauerhafte verwandeln. Entscheiden Sie, wie die Arbeit weitergeht, wer den Ersatz oder den Übergang verantwortet und welcher Nachweis die Aufgabe abschließt.

Abhilfe: Das Enddatum bestätigen oder eine befristete Verlängerung genehmigen (Remediation)

1. Vor der Bearbeitung des Kontos entscheiden

Bestätigen Sie zunächst Referenzdatum und Benutzerpopulation und senden Sie dann jeden Stichtag an den jeweiligen Eigentümer. Fragen Sie, ob das ursprüngliche Enddatum weiterhin gültig ist und ob der Benutzer denselben Zugriff noch benötigt. Dokumentieren Sie die Antwort samt Genehmigungsquelle. Eine ausbleibende Antwort bedeutet eine ungeklärte Prüfung, keine Genehmigung zur Verlängerung.

Soll der Zugriff wie geplant enden, koordinieren Sie Rechteentzug, Mitgliedschaftsprüfung und Anwendungsübergabe mit den zuständigen Teams. Wird die Arbeit fortgesetzt, verlangen Sie ein neues begrenztes Enddatum und einen autorisierten Grund. Trennen Sie diese beiden Ergebnisse im Register, damit eine pauschale Verlängerung nicht als abgeschlossene Abhilfe missverstanden werden kann.

2. Nur das genehmigte Datum anwenden

Microsoft dokumentiert Set-ADAccountExpiration zum Festlegen eines genauen Ablaufzeitpunkts. Der Parameter -DateTime nimmt lokale Zeit an, sofern nichts anderes angegeben ist; wird die Uhrzeit weggelassen, bedeutet dies Mitternacht in lokaler Zeit. Verwenden Sie den genau genehmigten Zeitpunkt und halten Sie ihn ausdrücklich fest. Microsoft Learn: Set-ADAccountExpiration

Die folgende beispielhafte gezielte Verlängerung verwendet eine Platzhalteridentität und einen UTC-Stichtag. Führen Sie zunächst die Vorschau in einer autorisierten Umgebung aus. Wenden Sie den separaten Schreibbefehl erst an, nachdem Sie geprüft haben, dass Identität und Datum mit der dokumentierten Genehmigung übereinstimmen. Diese Befehle wurden hier nicht ausgeführt.

$identity = 'CN=Example User,OU=People,DC=example,DC=com'
$approvedExpiryUtc = [datetime]::new(2026, 12, 1, 18, 0, 0, [DateTimeKind]::Utc)
Set-ADAccountExpiration -Identity $identity -DateTime $approvedExpiryUtc -Server $server -WhatIf

Set-ADAccountExpiration -Identity $identity -DateTime $approvedExpiryUtc -Server $server

Übergeben Sie diesem Schreibbefehl nicht den gesamten Ablaufbericht. Ein Abfrageergebnis belegt eine Datumsbedingung; es liefert keine Genehmigung für fortgesetzten Zugriff. Ebenso ist das Aufheben des Ablaufdatums eine eigene Richtlinienentscheidung, keine routinemäßige Lösung für einen Befund zu einem bevorstehenden Kontoablauf.

3. Erneut lesen und die Entscheidung aufbewahren

Lesen Sie dasselbe Konto nach der Änderung vom ausgewählten Server erneut. Bewahren Sie die alten und neuen Rohwerte, normalisierten Daten, Server, Zeitstempel, Genehmigung und Änderungsreferenz auf:

Get-ADUser -Identity $identity -Server $server -Properties accountExpires,AccountExpirationDate |
    Select-Object DistinguishedName, Enabled, accountExpires, AccountExpirationDate

Normalisieren Sie den Rohwert mit der Inventarmethode und vergleichen Sie ihn mit dem genehmigten UTC-Zeitpunkt. Dieses erneute Lesen überprüft den Wert auf dem ausgewählten Server; hängt der Ablauf von weiteren Domänencontrollern ab, veranlassen Sie deren Überprüfung über den Prozess des Verzeichnisteams. Eine gespeicherte Genehmigung ohne erneutes Lesen belegt nicht, dass das Attribut wie beabsichtigt geändert wurde.

Bewahren Sie bei geplanten Austritten Nachweise auf, dass die zugewiesenen Aufgaben zum Rechteentzug und Serviceübergang abgeschlossen wurden. Planen Sie bei Verlängerungen die nächste Prüfung rund um den neuen Stichtag. Unterscheiden Sie in beiden Fällen das Kontoattribut von Tickets, Verbindungen und Anwendungszugriffen. Der Datensatz sollte benennen, was überprüft wurde und was noch bei einem anderen Verantwortlichen liegt.

Wie EtcSec dies erkennt

Der etc-collector von EtcSec implementiert ACCOUNT_EXPIRE_SOON in public/internal/audit/detectors/ad/accounts/status/account-expire-soon.go. Die statische Prüfung von Detect() zeigt die folgende Logik; für diesen Artikel wurde kein Kundenaudit ausgeführt:

1. Die Referenzzeit aus data.Now übernehmen.
2. Die obere Grenze mit now.AddDate(0, 0, 30) berechnen.
3. Jeden Benutzer überspringen, dessen Flag Disabled wahr ist.
4. Jeden Benutzer überspringen, dessen geparster Wert AccountExpires die Nullzeit ist.
5. Nur Daten auswählen, die strikt nach der Referenzzeit und strikt vor der oberen Grenze liegen.

Die untere und die obere Grenze sind beide ausgeschlossen. Bereits abgelaufene Konten sind ausgeschlossen, ebenso ein Ablaufzeitpunkt, der genau der Audit-Referenzzeit entspricht. Count ist die Anzahl ausgewählter Benutzer, nicht die Anzahl von Domänen, Genehmigungen oder fehlenden Offboarding-Aufgaben. Der Detektor gibt einen Befund mit Schweregrad Medium und dieser Anzahl zurück; Details zu betroffenen Benutzern werden nur angehängt, wenn IncludeDetails aktiviert und die Anzahl positiv ist.

Diese Prüfung enthält keine Bedingung zu privilegierten Gruppen, Servicekonten oder Geheimnissen. Sie umfasst alle erfassten Benutzer, die die Bedingungen für Datum und Aktivierungszustand erfüllen. Das Dreißigtagefenster ist eine erklärte Produktentscheidung, keine Anforderung von Microsoft, ANSSI oder CIS. Die Implementierung addiert Kalendertage; bewahren Sie die Audit-Referenz und die Grenzen auf, wenn Sie ein bestimmtes Ergebnis erläutern.

Der LDAP-Parser befüllt AccountExpires über parseFileTime in public/internal/providers/ldap/parser.go. Leere Eingaben, 0, der maximale vorzeichenbehaftete 64-Bit-Sentinelwert und Fehler beim Parsen ganzer Zahlen werden zur Nullzeit, ohne dass diese Hilfsfunktion eine Diagnose pro Wert ausgibt. Werte vor der Konvertierungsgrenze der Unix-Epoche werden ebenfalls zu Null. Daher kann ein geparstes Nulldatum sowohl nie ablaufende Daten als auch nicht verfügbare oder unbrauchbare Eingaben darstellen. Der Detektor überspringt beides.

Verwenden Sie ACCOUNT_EXPIRE_SOON, um die Prüfung von Eigentümer und Stichtag zu beginnen. Eine positive Anzahl belegt weder einen Angriff noch einen Kennwortablauf, eine unautorisierte Verlängerung oder die Notwendigkeit einer Erneuerung. Schließen Sie die Prüfung mit einer dokumentierten Entscheidung zum Enddatum, einem überprüften Attributzustand und separat verantworteten Aufgaben zum Zugriffsentzug oder zu Abhängigkeiten ab.