Ausgangslage: 30 Tage sind kein Ablaufdatum

Jedes domänengebundene Windows-System besitzt in Active Directory ein Computerkonto, üblicherweise mit einem Namen wie CLIENT-042$. Zu diesem Konto gehört ein automatisch erzeugtes Kennwort. Eine Kopie liegt als lokales LSA-Secret auf dem System, die andere in Active Directory. Netlogon nutzt dieses gemeinsame Geheimnis, um den Secure Channel zu Domain Controllern aufzubauen. Über diesen Kanal laufen sicherheitsrelevante Vorgänge wie DC-Ermittlung, Authentifizierungsprüfungen und Aktualisierungen des Computerkontos.

Windows stößt standardmäßig ungefähr alle 30 Tage eine Änderung dieses Computerkennworts an. Das wird häufig falsch als serverseitiges Ablaufdatum interpretiert. Ein Notebook verliert aber nicht automatisch am 31. Tag ohne VPN seine Domänenvertrauensstellung. Die Rotation ist clientgetrieben: Ist das Kennwort fällig und ein Domain Controller erreichbar, führt das System die Änderung durch. Ohne DC-Verbindung bleibt das vorhandene Geheimnis bestehen und die Rotation wird später erneut versucht.

Echte Trust-Probleme entstehen meist an anderer Stelle: Eine virtuelle Maschine wird auf einen alten Snapshot zurückgesetzt, ein Image enthält bereits eine Domänenidentität, ein Computerkonto wird manuell zurückgesetzt oder ein zweites System übernimmt denselben Namen. Dann kann Active Directory ein neueres Kennwort kennen als das lokale System. Das sichtbare Symptom lautet oft, dass die Vertrauensstellung zwischen Arbeitsstation und primärer Domäne fehlgeschlagen ist. Die Ursache ist nicht das Alter allein, sondern ein nicht mehr synchroner Zustand.

Ebenso problematisch ist die Gegenreaktion, die Kennwortänderung pauschal abzuschalten. Damit bleibt ein einmal kompromittiertes Computerkennwort länger nutzbar. Gleichzeitig wird ein normaler Windows-Schutzmechanismus geopfert, obwohl sich Snapshot-, VDI- und Bereitstellungsprobleme besser über einen sauberen Geräte-Lifecycle lösen lassen.

Zielbild: Rotation bleibt aktiv und Sonderfälle bleiben sichtbar

Ein belastbarer Zielzustand besteht nicht aus einem möglichst kleinen Zahlenwert. Er verbindet eine vernünftige Baseline mit überprüfbarem Betrieb:

  1. Persistente Windows-Clients und Member Server rotieren standardmäßig etwa alle 30 Tage. Kürzere Intervalle werden nur mit einem konkreten Risikomodell und gemessener Replikationswirkung gewählt.
  2. Die Kennwortänderung ist auf Mitgliedssystemen nicht deaktiviert. Die Richtlinie Domain member: Disable machine account password changes bleibt Disabled.
  3. Domain Controller lehnen legitime Änderungen nicht ab. Domain controller: Refuse machine account password changes ist deaktiviert oder nicht konfiguriert.
  4. Alte Zeitstempel werden nicht isoliert bewertet. PasswordLastSet, Gerätestatus, letzte Aktivität, angewendete Richtlinie und Secure-Channel-Zustand werden gemeinsam betrachtet.
  5. Snapshots, Golden Images und nicht persistente VDI haben einen eigenen Identitätsprozess. Ein Computerobjekt gehört genau zu einer laufenden Instanz; Rollbacks und Klone bringen keine veralteten LSA-Secrets zurück.
  6. Trust-Reparaturen sind ein kontrollierter Betriebsprozess. DNS, Zeit, Erreichbarkeit und Replikation werden geprüft, bevor Konten zurückgesetzt oder Systeme aus der Domäne entfernt werden.

Die 30-Tage-Baseline ist dabei ein sinnvoller Ausgangspunkt, keine magische Sicherheitsgrenze. Eine Verkürzung auf wenige Tage verursacht mehr Kennwortänderungen und Replikation, ohne automatisch einen proportionalen Sicherheitsgewinn zu liefern. Eine starke Verlängerung vergrößert dagegen das Zeitfenster, in dem ein entwendetes Computerkennwort wiederverwendet werden kann.

Umsetzung: Policy, Lifecycle und Monitoring zusammenführen

1) Bestehende Werte und Ausnahmen inventarisieren

Beginne mit den effektiven Einstellungen, nicht nur mit den GPO-Namen. Für Windows-Mitglieder liegen die relevanten Sicherheitsoptionen unter:

Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen

Prüfe dort mindestens:

  • Domain member: Maximum machine account password age,
  • Domain member: Disable machine account password changes,
  • auf Domain Controllern zusätzlich Domain controller: Refuse machine account password changes.

Auf einem Testsystem liefert der Netlogon-Registryzweig eine schnelle lokale Sicht:

$netlogonPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters'

Get-ItemProperty -Path $netlogonPath |
  Select-Object MaximumPasswordAge, DisablePasswordChange, ScavengeInterval

Nicht vorhandene Werte bedeuten nicht automatisch eine Abweichung: Dann kann der Betriebssystemstandard greifen. Entscheidend sind zusätzlich gpresult, die Resultant Set of Policy und die tatsächlich verknüpften GPOs. Suche auch nach alten Registry-Preferences, Image-Build-Skripten und VDI-Agenten, die Netlogon-Werte außerhalb der Sicherheitsrichtlinie setzen.

2) Computerobjekte mit Betriebsdaten korrelieren

PasswordLastSet ist ein nützlicher Suchwert, aber kein alleiniger Health-Check. Eine erste, rein lesende AD-Auswertung kann auffällige Systeme für die weitere Prüfung markieren:

$reviewBefore = (Get-Date).AddDays(-60)

Get-ADComputer -Filter 'Enabled -eq $true' -Properties PasswordLastSet, LastLogonDate, OperatingSystem |
  Where-Object { -not $_.PasswordLastSet -or $_.PasswordLastSet -lt $reviewBefore } |
  Select-Object Name, OperatingSystem, PasswordLastSet, LastLogonDate |
  Sort-Object PasswordLastSet

Die 60 Tage sind hier nur ein Review-Filter, kein automatischer Lösch- oder Quarantänewert. Ein Ersatzgerät im Lager, ein Saisonarbeitsplatz und ein rund um die Uhr aktiver Member Server haben unterschiedliche Erwartungen. Ergänze deshalb CMDB-Owner, Gerätekategorie, letzte EDR-Sichtbarkeit, Standort und geplanten Lebenszyklus. LastLogonDate ist ebenfalls nur ein Näherungswert und ersetzt keine belastbare Asset-Quelle.

Aktive Server mit deutlich altem PasswordLastSet sind interessanter als ausgeschaltete Reservegeräte. Prüfe bei ihnen zuerst angewendete Richtlinien, Netlogon-Status, DC-Erreichbarkeit, DNS und Zeitabweichung. Setze nicht reflexartig das Computerkonto zurück: Ein manueller Reset verändert den gemeinsamen Zustand und kann das Problem erst erzeugen.

3) Eine klare 30-Tage-Baseline pilotieren

Setze die maximale Machine Account Password Age in einer dedizierten Hardening-GPO auf 30 Tage und lasse die Deaktivierungsrichtlinie ausdrücklich auf Disabled. Eine dedizierte GPO macht Scope, Ausnahmen und spätere Änderungen nachvollziehbarer als zusätzliche Einstellungen in der Default Domain Policy.

Der Pilot sollte getrennte Gerätegruppen enthalten:

  • dauerhaft verbundene Clients,
  • mobile Clients mit seltenem VPN-Kontakt,
  • Member Server in mindestens zwei AD-Standorten,
  • Systeme hinter restriktiven Firewalls,
  • Cluster- oder Applikationsserver mit dokumentierten Wartungsfenstern.

Beobachte mindestens einen vollständigen Rotationszyklus. Prüfe dabei nicht nur Tickets aus dem Helpdesk, sondern auch erfolgreiche Netlogon-Änderungen, Replikationsgesundheit und die Verteilung von PasswordLastSet. Ein Pilot über wenige Tage bestätigt nur die GPO-Anwendung, nicht den vollständigen Betriebsablauf.

4) Erfolg und Fehler mit Netlogon-Signalen unterscheiden

Auf dem Mitgliedssystem dokumentiert NETLOGON Event ID 5823 eine erfolgreiche, systemseitige Kennwortänderung. Event ID 3210 kann auf einen fehlgeschlagenen Secure Channel hindeuten. Auf Domain Controllern zeigt Security Event ID 4742 Änderungen an Computerkonten; die Änderung von Password Last Set ist bei normaler Rotation zu erwarten.

Ein einzelnes Domain-Controller-Event 5722 ist dagegen kein automatischer Incident. Es kann bei echten Trust-Problemen auftreten, aber auch zeitlich mit legitimen Kennwortaktualisierungen zusammenfallen. Korrelieren sollte man mindestens:

  • betroffenes Gerät und zugehörigen Owner,
  • PasswordLastSet sowie Replikationsstand auf mehreren DCs,
  • passende Client-Events,
  • Snapshot-, Restore- oder Imaging-Aktivitäten,
  • DNS-, Zeit- und Netzwerkfehler,
  • tatsächlichen Secure-Channel-Test.

Für persistente Server lohnt ein zentraler Alarm auf wiederholte 3210-Ereignisse oder dauerhaft fehlende erfolgreiche Rotation. Für Clients ist eine Abfrage aus EDR oder Endpoint Management meist belastbarer als die Hoffnung, dass jedes Gerät ständig zum Event-Collector verbunden ist.

5) Images, Snapshots und VDI identitätssicher betreiben

Die wichtigste Trennung lautet: Offline ist nicht dasselbe wie zurückgerollt. Ein ausgeschaltetes Notebook behält sein letztes gültiges Secret. Ein Snapshot-Rollback kann dagegen ein älteres lokales Secret wiederherstellen, während Active Directory bereits ein oder mehrere neuere Werte kennt. Windows toleriert begrenzte Replikationslatenz über aktuelle und vorherige Werte; beliebige Rollbacks sind daraus aber nicht sicher ableitbar.

Für Images und VDI gelten deshalb klare Regeln:

  • Golden Images werden nicht mit einer wiederverwendbaren Domänenidentität versiegelt.
  • Jede persistente Instanz erhält ein eigenes Computerkonto.
  • Nicht persistente Pools verwenden den vom Hersteller vorgesehenen Join- und Identitätsmechanismus.
  • Snapshot- und Restore-Prozesse enthalten einen Test der Domänenvertrauensstellung.
  • Ausgemusterte Instanzen und ihre Computerobjekte werden kontrolliert entfernt.
  • Eine deaktivierte Rotation bleibt eine eng begrenzte Ausnahme mit Owner, Begründung und Review-Termin.

Nicht persistente VDI oder schreibgeschützte Embedded-Systeme können Sonderbehandlung brauchen, weil eine während des Betriebs geänderte lokale Kopie beim nächsten Reset verloren wäre. Das ist kein Grund, die Rotation domänenweit abzuschalten. Der Ausnahmebetrieb muss stattdessen Passwortänderungen in Image-Wartung, Provisionierung oder einen herstellergestützten Lifecycle integrieren.

6) Trust-Probleme reparieren, ohne Identitäten blind neu anzulegen

Bei einer gemeldeten Vertrauensstellungsstörung prüfe zuerst lokale Zeit, AD-DNS, DC-Erreichbarkeit, Replikation und den Zustand des Computerkontos. Auf einem Domain Member ist dieser Test lesend:

Test-ComputerSecureChannel -Verbose

Eine Reparatur über Test-ComputerSecureChannel -Repair oder Reset-ComputerMachinePassword gehört in einen kontrollierten Change mit geeigneten, nicht protokollierten Anmeldeinformationen und verfügbarer lokaler Recovery-Anmeldung, idealerweise über Windows LAPS. Test-ComputerSecureChannel ist für Domain Member gedacht, nicht für Domain Controller. DC-Secure-Channels werden mit den dafür vorgesehenen netdom- oder nltest-Verfahren und einem eigenen Runbook behandelt.

Aus der Domäne austreten und wieder beitreten sollte die letzte, nicht die erste Maßnahme sein. Dieser Weg kann Zertifikatszuordnungen, Deployment-Gruppen, lokale Profile, SPNs oder applikationsbezogene Abhängigkeiten berühren. Ebenso riskant ist ein pauschaler Reset des AD-Computerkontos, solange das betroffene System nicht koordiniert denselben neuen Zustand übernimmt.

Vorteile

  • Begrenzt die Nutzungsdauer entwendeter Machine Secrets: Regelmäßige Rotation reduziert das Fenster für die Wiederverwendung eines alten Computerkennworts.
  • Stabilisiert den Netlogon Secure Channel: Einheitliche Client- und DC-Einstellungen vermeiden absichtlich blockierte Kennwortänderungen.
  • Macht Geräte-Lifecycle-Probleme sichtbar: Alte Images, doppelte Identitäten und unkontrollierte Snapshots fallen als Betriebsrisiken auf.
  • Erzeugt messbare Signale: PasswordLastSet, Netlogon-Events und Secure-Channel-Tests lassen sich zu einem belastbaren Kontrollbild verbinden.
  • Reduziert unnötige Rejoins: Ein definiertes Diagnose- und Reparaturverfahren behebt Trust-Probleme gezielter.
  • Hält Ausnahmen klein: VDI- oder Embedded-Sonderfälle werden separat betrieben, statt die Domänenbaseline zu schwächen.

Nachteile und Grenzen

  • Mehr Rotation erzeugt mehr Replikation: Sehr kurze Intervalle erhöhen Änderungsvolumen und können langsame Standorte unnötig belasten.
  • Rotation verhindert keinen lokalen Systemkompromiss: Wer dauerhaft lokale Administrator- oder SYSTEM-Rechte hält, kann auch nachfolgende Secrets erneut erlangen.
  • Zeitstempel sind keine vollständige Telemetrie: PasswordLastSet und LastLogonDate brauchen Kontext aus CMDB, EDR und Endpoint Management.
  • Rollback-Verfahren werden anspruchsvoller: Snapshots und Bare-Metal-Restores müssen den AD-Zustand der Computeridentität berücksichtigen.
  • Nicht persistente Plattformen benötigen Sonderdesign: Eine klassische persistente Machine-Secret-Rotation passt nicht automatisch zu jedem VDI- oder Embedded-Modell.
  • Trust-Reparaturen brauchen privilegierte Abläufe: Unkontrollierte Reset- oder Rejoin-Aktionen können zusätzliche Abhängigkeiten beschädigen.

Typische Stolperfallen

  • 30 Tage als harte Offline-Grenze behandeln: Ein Gerät verliert seine Vertrauensstellung nicht allein, weil es länger ausgeschaltet war.
  • PasswordLastSet pauschal als Schwachstelle melden: Ein alter Wert ist ein Review-Signal, kein Beweis für einen defekten Secure Channel.
  • Nur MaximumPasswordAge prüfen: DisablePasswordChange auf Mitgliedern und RefusePasswordChange auf DCs können die Rotation unabhängig blockieren.
  • Eine Mini-Frist als Härtung verkaufen: Ein oder sieben Tage können Replikation und Betrieb belasten, ohne den lokalen Kompromiss zu lösen.
  • VDI-Ausnahmen domänenweit vererben: Nicht persistente Pools brauchen einen eigenen Scope und Lifecycle.
  • Golden Images bereits domänengebunden klonen: Mehrere Instanzen konkurrieren dann um dieselbe Computeridentität.
  • Snapshots als normale Wiederherstellung behandeln: Ein technisch erfolgreicher Rollback kann ein veraltetes lokales LSA-Secret zurückbringen.
  • Computerkonten vorschnell zurücksetzen: Ohne koordinierte lokale Reparatur wird der gemeinsame Secret-Zustand absichtlich getrennt.
  • Event 5722 ohne Korrelation eskalieren: Das Ereignis allein unterscheidet legitime Rotation nicht sicher von einem Trust-Fehler.
  • Secure-Channel-Cmdlets auf DCs verwenden: Diagnose und Reparatur unterscheiden sich zwischen Domain Members und Domain Controllern.

Projekt-Checkliste

  • [ ] Effektive Machine-Account-Password-Age auf Clients, Member Servern und DCs erfassen.
  • [ ] Domain member: Disable machine account password changes auf Disabled verifizieren.
  • [ ] Domain controller: Refuse machine account password changes deaktivieren oder nicht konfigurieren.
  • [ ] Dedizierte Hardening-GPO mit 30-Tage-Baseline und klaren OU-Links erstellen.
  • [ ] Alte Registry-Preferences, Build-Skripte und VDI-Agenten auf Netlogon-Sonderwerte prüfen.
  • [ ] AD-Inventar um PasswordLastSet, Lifecycle-Status, Owner und Gerätekategorie ergänzen.
  • [ ] Persistente, mobile, standortferne und serverseitige Pilotgruppen definieren.
  • [ ] Den Pilot mindestens über einen vollständigen Rotationszyklus beobachten.
  • [ ] NETLOGON 5823 und 3210 sowie DC-Events 4742 und 5722 kontextbezogen auswerten.
  • [ ] Snapshot-, Restore- und Bare-Metal-Runbooks um einen Secure-Channel-Test ergänzen.
  • [ ] Golden-Image- und VDI-Prozess auf eindeutige Computeridentitäten prüfen.
  • [ ] Ausnahmen mit Scope, Owner, Begründung, Ablaufdatum und Wartungsverfahren dokumentieren.
  • [ ] Lokalen Recovery-Zugang, vorzugsweise Windows LAPS, vor Trust-Reparaturen validieren.
  • [ ] Runbook für Member-Reparatur und getrenntes DC-Verfahren dokumentieren und testen.
  • [ ] Replikationszustand und Helpdesk-Fälle nach dem breiten Rollout überwachen.