Smartcard-Passwortrotation in Active Directory

Smartcard-Passwortrotation in Active Directory

Die Smartcard-Passwortrotation in Active Directory ist wichtig, weil diese Konten weiterhin ein Netzwerkpasswort als Geheimnis behalten. Ohne Passwort-Rolling kann das von Windows erzeugte zufällige Geheimnis bestehen bleiben, bis es ausdrücklich geändert wird. Die Aussage, es ändere sich „standardmäßig nie“, muss sofort eingeschränkt werden: Microsoft dokumentiert Rolling als aktiviert für neue Domänen, während bestehende Domänen konfiguriert werden müssen. Betrachten Sie dies als Risiko in Domänen ohne Rolling oder mit deaktiviertem Rolling, statt als allgemeine Eigenschaft moderner Active-Directory-Umgebungen. Microsofts Dokumentation zu den Funktionen von Windows Server 2016 macht diese Unterscheidung.

Die Kontooption und die Rotationseinstellung der Domäne beantworten unterschiedliche Fragen. Die erste legt fest, ob der Benutzer für die erste interaktive Anmeldung eine Smartcard verwenden muss, einschließlich Remote Desktop. Die zweite steuert die Pflege des passwortbasierten Geheimnisses, das für die Netzwerkauthentifizierung weiterhin relevant bleibt. Eine Prüfung, die beim Kontrollkästchen des Kontos endet, lässt die zweite Frage offen. Microsofts Kontodokumentation beschreibt sowohl die interaktive Einschränkung als auch den verbleibenden NT-Hash.

Für Administratoren reicht das sinnvolle Ziel daher über „das Kontrollkästchen grün machen“ hinaus. Ermitteln Sie, welche Identitäten die Karte benötigen, ob ihre Domäne Rolling unterstützt und aktiviert hat und wie Sie ein erfolgreiches Zurücksetzen an einem repräsentativen Konto nachweisen werden. Dieser Leitfaden folgt dieser Reihenfolge: Konto und Domäne prüfen, Befunde interpretieren und anschließend Abhilfemaßnahmen im Pilotversuch erproben. Die folgenden Befehle sind Beispiele auf Grundlage der Dokumentation; keiner wurde für diesen Artikel gegen eine Domäne ausgeführt.

Das Bit ist eine Authentifizierungsanforderung

Die Option entspricht dem kumulativen userAccountControl-Flag SMARTCARD_REQUIRED, hexadezimal 0x40000, dezimal 262144. Andere Flags können gleichzeitig gesetzt sein. Wer das gesamte Attribut so auswertet, als müsse es gleich 0x40000 sein, übersieht Konten mit zusätzlichen Optionen. Microsofts UserAccountControl-Referenz führt das Flag auf und erläutert die kumulativen Werte.

Windows setzt das Geheimnis des Kontos auf einen zufälligen Wert, wenn die Anforderung aktiviert wird. Microsofts Administrationsleitfaden beschreibt ein anfangs unbekanntes zufälliges Passwort und warnt, dass jemand mit Passwort-Zurücksetzungsrechten anschließend einen bekannten Wert setzen und bestimmte Netzwerkzugriffswege nutzen kann. Die Kartenpflicht hebt die Bedeutung dieser Zurücksetzungsrechte nicht auf. Microsofts Leitfaden zum Prinzip der geringsten Rechte beschreibt diese verbleibende administrative Möglichkeit ausdrücklich.

Wie das verbleibende Geheimnis und Rolling funktionieren

Zufällig bedeutet nicht regelmäßig ersetzt

Laut Microsofts Kontoreferenz bleibt der erzeugte Wert ohne das zusätzliche Rolling-Verhalten bestehen, bis ein neues Passwort gesetzt oder die Smartcard-Anforderung deaktiviert und erneut aktiviert wird. Ein Anfangswert mit hoher Entropie erschwert das Erraten; denselben Wert nach einem Diebstahl beizubehalten, ist ein anderes Problem. Diese Unterscheidung liegt der Prüfung zugrunde, nicht die Behauptung, jedes Smartcard-Konto habe das älteste Passwort seiner Domäne. Das dokumentierte Kontoverhalten belegt die Beständigkeit und den Mechanismus für den manuellen Ersatz.

Die Windows-Authentifizierung muss auch den anschließenden Zugriff auf Netzwerkressourcen unterstützen. Microsofts Dokumentation zu Anmeldeinformationsprozessen beschreibt in ihrem Anmeldeinformationsmodell die Aufbewahrung des entsprechenden NT-Hashes nach der Smartcard-Anmeldung. Das erklärt, warum das Geheimnis wichtig ist. Es belegt nicht, dass ein Angreifer unabhängig von Schutzmaßnahmen und tatsächlicher Sitzung aus jedem Endgerät einen Hash extrahieren kann. Untersuchen Sie das Vorhandensein, die Offenlegung und den Diebstahl von Anmeldeinformationen als getrennte Fragen.

Die Domäneneinstellung ermöglicht richtlinienbasierten Ablauf

Das boolesche Domänenattribut msDS-ExpirePasswordsOnSmartCardOnlyAccounts steuert den Ablauf der Passwörter von Konten mit ausschließlicher Smartcard-Anmeldung gemäß der Passwortrichtlinie. Es ist nicht das Smartcard-Bit eines einzelnen Benutzers. Die Attributdefinition in MS-ADA2 beschreibt seinen Zweck.

Die Funktion erfordert eine Domänenfunktionsebene von Windows Server 2016 oder höher. Die Betriebssystemversion eines Domänencontrollers allein weist diese Voraussetzung nicht nach; erforderlich ist hier die Domänenebene, keine erfundene Voraussetzung auf Gesamtstrukturebene. Microsofts Funktionsseite dokumentiert außerdem die Option im Active Directory Administrative Center für bestehende Domänen. Die Beschreibung der Rolling-Funktion ist die Referenz für diese Bereitstellungsanforderungen.

Das Zurücksetzen gehört zur Verarbeitung geeigneter Anmeldungen

Während der Verarbeitung eines PKINIT AS-REQ fordert der KDC unter den in MS-PKCAs Zurücksetzungsverfahren definierten Bedingungen das Zurücksetzen des Passworts für das Konto mit ausschließlicher Smartcard-Anmeldung an. Bei erfolgreichem Abschluss beginnt er die Verarbeitung der ursprünglichen Anfrage erneut.

Der antwortende Dienst wendet die Ablauf- und Validierungsregeln aus MS-SAMS' normativer Spezifikation des Zurücksetzens an. Ein noch nicht abgelaufenes Passwort führt zu einer erfolgreichen Rückmeldung ohne Ersatz. Ablauf bedeutet hier die vom Protokoll berechnete Bedingung, die auch Regeln zur Ticketlebensdauer berücksichtigt; es handelt sich nicht einfach um den domänenbezogenen Altersgrenzwert des Collectors. Bei einem abgelaufenen Passwort prüft die Validierung unter anderem das aktivierte Domänenattribut, eine ausreichende Domänenfunktionsebene, das Smartcard-Bit und das Fehlen von DONT_EXPIRE_PASSWD. Ein erfolgreiches Zurücksetzen erzeugt neue Geheimnisse und aktualisiert pwdLastSet auf den aktuellen Zeitpunkt.

Dies ist eine Anmeldeverarbeitung unter Richtlinien- und Protokollbedingungen. Es ist weder ein Hintergrundtimer noch ein bei jeder Anmeldung garantierter Ersatz oder ein allgemeiner Zeitplan mit fester Tageszahl. Daraus lässt sich für den Betrieb ableiten, dass ein Konto, das selten eine geeignete Anmeldung durchführt, auch bei aktiviertem Rolling ein altes Datum behalten kann. Untersuchen Sie die Richtlinie und tatsächliche Nutzung dieses Kontos, bevor Sie dem Datum eine Ursache zuordnen.

Konto und Domäne getrennt messen

Verwenden Sie für vergleichbare Abfragen einen benannten Domänencontroller und ersetzen Sie corp.example, dc01.corp.example, den Distinguished Name der Domäne und admin-pilot durch reale Werte. Bewahren Sie Identität, Erfassungszeitpunkt und Rohergebnisse mit Ihrem Änderungsnachweis auf. Die Beispiele wurden aus dokumentierten Cmdlet-Parametern zusammengestellt; sie werden weder als wörtlich aus Learn übernommene Befehle noch als Ergebnisse eines Kundenaudits dargestellt.

Schritt 1 — Konten mit der Anforderung inventarisieren

Get-ADUser dokumentiert -Filter, -Properties und -Server. Das Active-Directory-Objektmodell dokumentiert SmartcardLogonRequired sowie die aus pwdLastSet abgeleitete Eigenschaft PasswordLastSet.

Get-ADUser -Filter {SmartcardLogonRequired -eq $true} -Properties pwdLastSet,PasswordLastSet,PasswordNeverExpires,Enabled,adminCount -Server dc01.corp.example

Lesen Sie neben den Datumswerten auch den Aktivierungszustand und die Ausnahme vom Passwortablauf. Behalten Sie deaktivierte Konten im Inventar, sofern dies hilfreich ist, unterscheiden Sie sie aber von der aktivierten Population, die der Rotationsdetektor auswertet. Ein Datum belegt die Passwortpflege; es datiert nicht unabhängig davon den Zeitpunkt, zu dem das Smartcard-Bit aktiviert wurde.

Erfassen Sie für jedes Konto den Verantwortlichen, den erwarteten Anmeldeablauf, die geltende Richtlinie und Ausnahmen vom Ablauf. Erheben Sie Ablauf- und Verantwortlichkeitsinformationen getrennt; Get-ADUser weist sie nicht nach.

Schritt 2 — Domäne und Funktionsebene bestimmen

Get-ADDomain akzeptiert eine Domänenidentität und einen Server und liefert Domäneninformationen einschließlich DomainMode und DistinguishedName.

Get-ADDomain -Identity corp.example -Server dc01.corp.example

Bestätigen Sie anhand der zurückgegebenen Domänenidentität, dass nachfolgende Abfragen den vorgesehenen Namenskontext betreffen. Erfassen Sie die Funktionsebene getrennt vom Betriebssysteminventar des Domänencontrollers. Wenn das Ergebnis nicht verfügbar ist oder die falsche Domäne bezeichnet, lösen Sie dieses Messproblem, bevor Sie Schlüsse über die Verfügbarkeit der Funktion ziehen.

Schritt 3 — Domänenattribut und Richtlinie zum Passwortalter lesen

Get-ADObject dokumentiert das Lesen eines Objekts anhand seiner Identität mit zusätzlichen LDAP-Eigenschaften. Lesen Sie das Domänenstammobjekt, keine OU und keinen einzelnen Benutzer:

Get-ADObject -Identity 'DC=corp,DC=example' -Properties msDS-ExpirePasswordsOnSmartCardOnlyAccounts,maxPwdAge -Server dc01.corp.example

Bewahren Sie den Rohwert von maxPwdAge zusammen mit der Domäneneinstellung auf. Der unten beschriebene Altersvergleich des Collectors nutzt einen aus dieser Richtlinie abgeleiteten Wert in Tagen. Ersetzen Sie ihn nicht durch ein willkürliches Altersziel, das Sie anschließend als Microsofts Rolling-Anforderung bezeichnen.

Behandeln Sie ein fehlendes Attribut, einen falschen booleschen Wert und eine fehlgeschlagene Abfrage als unterschiedliche Untersuchungssituationen. Bestätigen Sie Controller, Domänenidentität, Berechtigungen und Vollständigkeit der Antwort. Eine leere Konsolenansicht ist kein ausreichender Beleg dafür, dass eine erfolgreiche Erfassung false zurückgegeben hat.

Erkennung: Welche Frage beantwortet der Befund?

Beginnen Sie mit zwei Populationen: aktivierten Konten mit Kartenpflicht und administrativen Identitäten ohne Kartenpflicht. Ermitteln Sie in der ersten Population, ob Rolling aktiviert ist, bevor Sie das Alter bewerten. Bestätigen Sie in der zweiten die tatsächlichen administrativen Aufgaben, bevor Sie entscheiden, wo die Anforderung hingehört. Dies sind aus den Detektorkriterien abgeleitete Prüfschritte, kein Nachweis eines Einbruchs.

Die Tabelle fasst smartcard-rotation.go:48 und admin-no-smartcard.go:24 zusammen, die für diesen Artikel vollständig untersucht wurden. Ihre Implementierung wird im Abschnitt „Wie EtcSec dies erkennt“ erläutert.

Ein nützlicher Nachweis trennt die Konfigurationsbeobachtung, die Beobachtung des Kontoalters und die bestätigte Ursache. Ein altes Datum bei aktiviertem Rolling ist beispielsweise ein Anlass zur Untersuchung; es beweist nicht, dass das Domänenattribut insgeheim deaktiviert sein muss. Beschreiben Sie den Namen des Detektors nicht als Diagnose für jedes von ihm zurückgegebene Konto.

Warum die Angriffsfolge an Bedingungen gebunden bleibt

Wird ein noch gültiges NT-Geheimnis tatsächlich gestohlen, hängt seine Nutzung von den Authentifizierungsprotokollen und Rechten entlang des Zielpfads ab. Unser Pass-the-Hash-Leitfaden erläutert diese bedingte Wiederverwendung über NTLM. Er unterscheidet außerdem Overpass-the-Hash, das unter den entsprechenden Bedingungen Kerberos-Authentifizierungsmaterial beschafft, von Pass-the-Ticket, das ein Ticket wiederverwendet. Leiten Sie aus dem Besitz des NT-Hashes eines Benutzers nicht ab, dass er jedes Ticket in einer AES-basierten Domäne bereitstellt.

Formulieren Sie das Härtungsziel präzise: die Beständigkeit eines wiederverwendbaren Passwortgeheimnisses verringern. Beschreiben Sie ein erfolgreiches Zurücksetzen des Passworts nicht als universellen Widerruf bereits ausgestellter Tickets, bestehender Netzwerksitzungen oder Zertifikate. Diese erfordern eigene Entscheidungen im Rahmen der Vorfallsreaktion.

Abhilfemaßnahmen: Rolling im kontrollierten Pilotversuch aktivieren (Remediation)

Schritt 1 — Voraussetzungen und Verantwortlichkeit festlegen

Benennen Sie vor einer Domänenänderung den verantwortlichen Administrator, wählen Sie ein repräsentatives Pilotkonto und bestätigen Sie die Domänenfunktionsebene. Prüfen Sie die tatsächliche Passwortrichtlinie des Pilotkontos und seine Ausnahmen vom Ablauf. Organisieren Sie eine Möglichkeit, seine Smartcard-Anmeldung und den erforderlichen Netzwerkzugriff mit einem vereinbarten Wiederherstellungsverfahren zu testen.

Dies ist ein empfohlener Änderungsplan, kein Laborergebnis. Er soll Abhängigkeiten aufdecken, bevor die Änderung ausgeweitet wird. Nutzen Sie eine erfolgreiche Schreiboperation nicht als einziges Abnahmekriterium. Legen Sie vorab fest, welche Abfragen und Authentifizierungstests der Änderungsverantwortliche als Nachweise aufbewahren wird.

Die ausgewählten Identitäten müssen auch zur vorgesehenen Nutzung passen. Microsofts Kontoreferenz besagt, dass Konten mit Smartcard-Anforderung nicht zum Starten von Diensten oder zum Ausführen geplanter Aufgaben verwendet werden können. Prüfen Sie solche Abhängigkeiten, bevor Sie die Anforderung eines Kontos ändern. Microsofts Kontoleitfaden beschreibt diese Grenze.

Schritt 2 — Rolling für die Domäne aktivieren

Passen Sie nach Validierung der Funktionsebene und Planung des Pilotversuchs Beispiel 6 von Set-ADDomain an:

Set-ADDomain -Identity corp.example -PublicKeyRequiredPasswordRolling $true -Server dc01.corp.example

Der dokumentierte Parameter setzt msDS-ExpirePasswordsOnSmartCardOnlyAccounts auf true. Dies ist eine Domänenänderung, auch wenn die Validierung mit einem einzigen Konto beginnt. Inventarisieren Sie betroffene Identitäten und ihre Verantwortlichen vor der Anwendung.

Wiederholen Sie unmittelbar die vorherige Abfrage des Domänenobjekts am gewählten Controller. Organisieren Sie dann eine geeignete Anmeldung des Pilotkontos und wiederholen Sie die Benutzerabfrage. Erfassen Sie den tatsächlichen Ablauf, statt erwartete Ausgaben in den Änderungsnachweis einzufügen. Wenn sich das Datum nicht ändert, untersuchen Sie Eignung und Richtlinie, bevor Sie Änderungen blind wiederholen. Dieses Beispiel verspricht weder eine Replikationsverzögerung noch ein Zurücksetzungsergebnis.

Schritt 3 — Manuellen Ersatz nur als kontrolliertes Verfahren nutzen

Wo automatisches Rolling noch nicht eingesetzt werden kann, dokumentiert Microsofts Kontoreferenz den Ersatz durch Deaktivieren und erneutes Aktivieren der Anforderung. Set-ADUser dokumentiert den booleschen Parameter -SmartcardLogonRequired. Die folgenden Schritte sind zwei getrennte Aktionen an einem Pilotkonto.

Entfernen Sie zunächst die Anforderung:

Set-ADUser -Identity admin-pilot -SmartcardLogonRequired $false -Server dc01.corp.example

Stellen Sie sie anschließend wieder her:

Set-ADUser -Identity admin-pilot -SmartcardLogonRequired $true -Server dc01.corp.example

Lesen Sie das Konto erneut, prüfen Sie die wiederhergestellte Anforderung, testen Sie den vorgesehenen Anmelde- und Netzwerkablauf und bestätigen Sie den relevanten replizierten Zustand. Behaupten Sie nicht, dieses manuelle Verfahren aktualisiere pwdLastSet stets genauso wie das normative automatische Zurücksetzen. Messen Sie das Ergebnis.

Wenn eine niedrigere Funktionsebene automatisches Rolling verhindert, dokumentieren Sie das manuelle Verfahren, die Verantwortlichkeit und den organisatorischen Zeitplan. Wählen Sie diesen Zeitplan anhand Ihres Risiko- und Betriebsprozesses; bezeichnen Sie ein gewähltes Intervall nicht als Microsoft-Anforderung für diese Funktion.

Schritt 4 — Den tatsächlichen administrativen Umfang prüfen

Nutzen Sie die Auswahl des ergänzenden Detektors als Ausgangsliste. Die folgende Syntax verwendet dokumentierte Get-ADUser-Parameter; die Auswahlkriterien stammen aus admin-no-smartcard.go:24.

Get-ADUser -Filter {Enabled -eq $true -and adminCount -eq 1 -and SmartcardLogonRequired -eq $false} -Properties adminCount,userAccountControl -Server dc01.corp.example

Gleichen Sie diese Liste mit aktuellen Gruppenmitgliedschaften, delegierter Administration, Anwendungsbefugnissen und Wiederherstellungsidentitäten ab. Der Detektor liest eine administrative Kennzeichnung; er berechnet nicht jede Form wirksamer Berechtigung. Microsofts Leitfaden zum Prinzip der geringsten Rechte behandelt Rechte in Verzeichnisgruppen, Mitgliedssystemen und Anwendungen. Deshalb muss die Prüfung über die Population der Abfrage hinausgehen. Prüfen Sie administrative Rechte und Passwort-Zurücksetzungsrechte, bevor Sie Kontobeschränkungen anwenden.

Änderung validieren, ohne das Ergebnis zu überzeichnen

Bauen Sie den Validierungsnachweis auf Beobachtungen auf, die ein Prüfer reproduzieren kann: abgefragte Domäne und Controller, Funktionsebene, rohes Rolling-Attribut, Kontoanforderung, geprüfte Richtlinie und Authentifizierungsergebnis des Pilotkontos. Fügen Sie Zeitstempel hinzu und bewahren Sie Fehler auf. Dies ist ein empfohlenes Nachweisformat, keine Behauptung, ein einzelner Befehl liefere jedes Element.

Unterscheiden Sie „die Einstellung ist aktiviert“ von „das Zurücksetzen eines geeigneten Kontos wurde abgeschlossen“. Wenn das Pilotkonto noch nicht zum Ablauf fällig ist, kann ein unverändertes Datum mit dem dokumentierten Ablauf vereinbar sein. Vergleichen Sie nach einem erfolgreichen Zurücksetzen die neue Benutzerbeobachtung mit der früheren Erfassung. Entscheiden Sie bei selten genutzten Konten, wie ihre künftige Validierung organisiert wird, statt anzunehmen, eine Domänenänderung erneuere sofort jedes Geheimnis.

Führen Sie abschließend die Konfigurationsbewertung erneut durch und untersuchen Sie beide Populationen nochmals. Ein verbleibender Befund verdient eine Untersuchung; eine Anzahl von null benötigt Erfassungskontext. Halten Sie den administrativen Wiederherstellungsplan bereit, während die Änderung ausgeweitet wird. Der Abschluss sollte genau beschreiben, was geprüft wurde und was weiterhin von künftigen Anmeldungen oder getrennten Kontrollen abhängt.

Wie EtcSec dies erkennt

SMARTCARD_PASSWORD_ROTATION_DISABLED

Die Implementierung in ad/advanced/other/smartcard-rotation.go:48 behandelt zunächst fehlende Domäneninformationen, indem sie einen Befund mit Count: 0 zurückgibt. Anschließend wählt sie aktivierte Benutzer aus, deren userAccountControl 0x40000 enthält.

Sie hat zwei tatsächliche Zweige:

• Domäneneinstellung false: Jeder Benutzer dieser aktivierten Population mit Smartcard-Anforderung wird ausgewählt, unabhängig von PasswordLastSet. Eine kürzliche Passwortänderung beseitigt den Konfigurationsbefund nicht.
• Domäneneinstellung true: Das Alter wird nur ausgewertet, wenn MaxPasswordAge > 0 gilt. Das Konto wird ausgewählt, wenn PasswordLastSet null ist oder strikt vor Now.AddDate(0, 0, -MaxPasswordAge) liegt. Gleichheit wird nicht ausgewählt. Bei einem Höchstalter von null leitet dieser Zweig keinen Altersbefund ab.

Diese Zweige stehen in smartcard-rotation.go:79–87; der Richtliniengrenzwert steht in 62–66. Der Check nutzt weder einen Grenzwert mit fester Tageszahl noch beweist er, dass bei einer bestimmten Anmeldung ein Zurücksetzen stattgefunden hat.

ADMIN_NO_SMARTCARD

Die ergänzende Implementierung in ad/accounts/advanced/admin-no-smartcard.go:24 wählt über die Bedingungen in 29–41 aktivierte Benutzer mit AdminCount=true und fehlendem Smartcard-Bit aus. Sie untersucht weder das Passwortalter noch das Rolling-Attribut der Domäne.

Die beiden Checks bewerten unterschiedliche Kontopopulationen. Einer prüft die Pflege des Geheimnisses hinter einer vorgeschriebenen Smartcard; der andere identifiziert Konten in seiner administrativen Auswahl ohne diese Anforderung. Keiner sollte so dargestellt werden, als beseitige er alle passwortbasierten Angriffe.

Was diese Befunde nicht messen

Keine der beiden Detect()-Funktionen validiert die Domänenfunktionsebene, berechnet für jeden Benutzer die wirksame fein abgestimmte Passwortrichtlinie, prüft DONT_EXPIRE_PASSWD, weist eine erfolgreiche Anmeldung oder ein Zurücksetzen nach oder inventarisiert Administratoren außerhalb von adminCount. Die LDAP-Erfassung bildet ein wahres Rolling-Attribut auf einen booleschen Wert ab und fehlend oder false auf false; sie leitet das maximale Passwortalter aus maxPwdAge ab (providers/ldap/client.go:636,662–669). Diese Erfassungsgrenze ist für die Interpretation des ersten Zweigs wichtig.

Eine Anzahl von null kann daher keine ausgewählten Benutzer, einen Altersvergleich ohne positiven Grenzwert oder nicht verfügbare Domäneninformationen bedeuten. Sie ist für sich kein Nachweis vollständiger Erfassung oder funktionierender Rotation. Nutzen Sie die Befunde als Leitlinie für die oben beschriebenen Konto- und Domänenmessungen und bewahren Sie die Pilotnachweise auf, die das tatsächlich geprüfte Verhalten belegen.