Active Directory Domain Controller Computerobjekt-Hygiene LAPS-Schema: Sechs Lücken, die ein Live-Audit immer wieder findet

Active Directory Domain Controller Computerobjekt-Hygiene LAPS-Schema: Was dieses Audit abdeckt

Prüfungen zur Active Directory Domain Controller Computerobjekt-Hygiene und zum LAPS-Schema sind das, was ein Live-Audit zuerst findet – und keine davon ist für sich genommen dramatisch: ein AD-Schema, das nie für LAPS erweitert wurde, Domain Controller außerhalb ihrer OU und Computerobjekte, die seit Jahren niemand mehr angesehen hat. Zusammen liegen sie unter den bekannten Angriffspfaden – Kerberoasting, DCSync, ADCS-Eskalation – und entscheiden still darüber, ob diese Angriffe überhaupt nötig sind. Eine Domäne, in der jedes Computerobjekt aktuell ist, jeder Domain Controller dort steht, wo er hingehört, und lokale Administratorkennwörter zentral verwaltet werden, ist eine Domäne, in der sich ein Angreifer den ersten Fuß in die Tür hart erarbeiten muss. Eine Domäne, in der nichts davon zutrifft, verschenkt Abkürzungen.

Dieser Beitrag behandelt sechs Lücken, die ein Live-Audit gegen eine reale AD-Umgebung immer wieder gemeinsam aufdeckt – keine davon taucht in einer typischen „Top-10-Fehlkonfigurationen"-Liste auf, weil keine für sich genommen eine dramatische Einzelschwachstelle ist:

1. Die LAPS-Schemaerweiterung für Active Directory wurde nie angewendet — nicht „LAPS ist bereitgestellt, aber nicht überall", sondern die Schema-Attribute selbst existieren gar nicht.
2. Domain Controller, deren Computerobjekt außerhalb der OU Domain Controllers liegt.
3. Domain-Controller-Objekte, die die Replikation eingestellt haben und nie bereinigt wurden.
4. Veraltete, inaktive Computerobjekte, um die sich niemand kümmert.
5. Computer ohne BitLocker, einschließlich Domain Controllern, die NTDS.dit vorhalten.
6. Computerkonten, deren Maschinenkennwort nicht mehr rotiert.

Jede einzelne davon ist wenig spektakulär. Zusammen beschreiben sie eine Umgebung, in der sich niemand für den Objekt-Lebenszyklus zuständig fühlt — und genau darauf verlassen sich Angreifer, wenn die auffälligeren Kontrollen bereits abgesichert sind.

Warum ein nicht erweitertes LAPS-Schema die tiefste Lücke ist

Local Administrator Password Solution gibt es in zwei Generationen, und der Unterschied ist hier wichtig. Das klassische Microsoft LAPS speicherte das verwaltete Kennwort im Attribut ms-Mcs-AdmPwd, das durch Ausführen von Update-AdmPwdADSchema als Schema Admin zum Schema hinzugefügt wurde — siehe Microsofts eigene Attributreferenz in MS-ADA2. Seit dem kumulativen Update vom April 2023 wird Windows LAPS als integrierte Betriebssystemkomponente ausgeliefert und verwendet einen anderen, verschlüsselten Satz von Attributen (msLAPS-Password, msLAPS-EncryptedPassword, msLAPS-PasswordExpirationTime) — siehe die technische Referenz zu Windows LAPS. Beide Generationen erfordern eine eigene, einmalige Schemaerweiterung (Update-LapsADSchema für die neuen Attribute), die einmalig domänenweit von einem Mitglied der Gruppe Schema Admins ausgeführt wird.

Dieser Schritt wird leicht übersehen, weil das Auslassen keinen Fehler erzeugt. GPOs können verknüpft werden, die LAPS-CSE kann auf jeden Endpoint ausgerollt werden, und trotzdem passiert nichts — es gibt schlicht kein Attribut, in das das Kennwort geschrieben werden könnte. Das ist eine andere, grundlegendere Lücke als „LAPS ist konfiguriert, aber einige Computer sind nicht im Geltungsbereich", die Lücke, die wir separat unter Windows LAPS nicht bereitgestellt behandelt haben. Hier wurde das Schema selbst nie angefasst, was bedeutet, dass jedes lokale Administratorkennwort in der Domäne unverwaltet ist — häufig identisch über ein gesamtes Build-Image hinweg geteilt, so die LAPS-Deployment-Analyse von ADSecurity.org. Ein einziges image-basiertes lokales Admin-Credential, einmal von einer einzelnen, wenig wertvollen Workstation geknackt oder ausgelesen, öffnet die laterale Bewegung in jede Maschine, die aus diesem Image gebaut wurde.

DCs außerhalb ihrer OU und Metadaten, die niemand bereinigt hat

DC_NOT_IN_DC_OU wirkt kosmetisch, bis man nachsieht, was Microsoft tatsächlich mit der Standard-OU Domain Controllers verknüpft: die Default Domain Controllers Policy GPO, die DC-spezifische Benutzerrechtezuweisungen, Audit-Richtlinien und Sicherheitsoptionen festlegt — dieselbe GPO-Vererbungskette, die wir in GPO-Fehlkonfigurationen als Angriffsvektor genauer betrachten. Wird das Computerobjekt eines Domain Controllers in eine andere OU verschoben — selbst in eine Unter-OU, die nur aus organisatorischer Ordnungsliebe angelegt wurde —, bricht diese Vererbungskette. Microsoft dokumentiert das seit Jahren als nicht unterstützte Konfiguration, nicht als Stilfrage; siehe den Beitrag von Computerworld zu diesem Fehler und den Domain-Controller-Sicherheitsleitfaden von Semperis. Ein DC, der stillschweigend seine Basis-Audit-Richtlinie verloren hat, erzeugt unvollständige Sicherheitsprotokolle — und genau das ist die Art von blindem Fleck, auf den eine Rogue-DC-Registrierungstechnik wie DCShadow angewiesen ist; diesen konkreten Missbrauch behandeln wir in DCShadow-Angriff: Rogue-Domain-Controller-Registrierung.

DC_INACTIVE ist das Geschwisterproblem: ein DC-Computerobjekt, das die Replikation eingestellt hat und nie formal außer Betrieb genommen wurde. Microsofts Leitfaden ist eindeutig: Ein DC, der durch Hardwareausfall oder eine fehlgeschlagene erzwungene Demotion entfernt wurde, hinterlässt verwaiste Verzeichnis- und DNS-Metadaten — Computer- und NTDS-Settings-Objekte, Replikationsverbindungen, SRV/CNAME-Einträge —, die bewusst per Metadatenbereinigung entfernt werden müssen und nicht einfach liegen bleiben dürfen; siehe Active Directory Domain Controller-Servermetadaten bereinigen. Bleibt sie liegen, erzeugt diese veraltete DC-Identität inkonsistente DC-Locator-Ergebnisse und liefert einem Angreifer ein plausibles, selten geprüftes Objekt zum Imitieren oder Zweckentfremden. Objektplatzierung und Replikationszustand sind die „Hygiene"-Hälfte der DC-Sicherheit; die Netzwerkdienst-Hälfte — LDAPS-Cipher-Stärke, ein exponierter Print Spooler, Uhrzeitabweichung jenseits der Kerberos-Toleranz — ist eine eigene Checkliste, die wir unter Domain Controller LDAPS schwaches TLS, Print Spooler, Zeitsynchronisation Audit veröffentlicht haben.

Veraltete Computer, fehlendes BitLocker und Maschinenkennwörter, die niemand rotiert

COMPUTER_STALE_INACTIVE ist das Pendant zum veralteten Benutzerkonto auf Computerobjekt-Ebene: eine Maschine, die sich seit Monaten nicht mehr authentifiziert hat, aber weiterhin ein vollgültiges Kerberos-Prinzipal mit SID, Gruppenmitgliedschaften und — falls ihr jemals Delegationsrechte oder Schreibzugriff auf etwas Sensibles eingeräumt wurden — eine Angriffsfläche ist, die niemand beobachtet. Die eigenständigen, tiefergehenden Risiken, die auf einem Computerobjekt liegen, sobald ein Angreifer es kontrolliert (uneingeschränkte Delegation, RBCD-Missbrauch, DCSync-fähige Rechte), behandeln wir separat unter Active Directory Computerobjekte Angriffsfläche; bei dieser Lücke geht es darum, dass die Objekte überhaupt existieren, ohne jemals überprüft zu werden.

COMPUTER_NO_BITLOCKER zählt am meisten bei den Maschinen, die die wertvollsten ruhenden Daten vorhalten. Bei einem Domain Controller ist das konkret NTDS.dit — die Datenbank mit dem Passwort-Hash jedes einzelnen Kontos. Microsofts eigener Härtungsleitfaden für Domain Controller empfiehlt TPM-gestütztes BitLocker auf allen DC-Volumes genau deshalb, weil es das Verzeichnis auch dann schützt, wenn eine physische Festplatte aus dem Server ausgebaut wird (siehe die Referenz Securing Domain Controllers Against Attack). Ist BitLocker mit AD-basierter Schlüsselhinterlegung aktiviert, landet das Recovery-Kennwort als untergeordnetes Objekt msFVE-RecoveryInformation unter dem Computerobjekt — siehe Storing BitLocker Recovery Keys in Active Directory —, sodass sein Fehlen direkt abfragbar ist und man dafür keiner Tabelle vertrauen muss.

COMPUTER_PASSWORD_OLD verfolgt ein subtileres Signal. Standardmäßig liegt „Domänenmitglied: Maximales Kennwortalter für Computerkonten" bei 30 Tagen — jeder domänenbeigetretene Computer soll sein eigenes Maschinenkennwort in diesem Rhythmus rotieren, eine Einstellung, die in Microsofts Referenz zu Sicherheitsrichtlinien dokumentiert und in ADSecurity.orgs ausführlicher Erklärung zu Maschinenkontokennwörtern vertieft wird. Ein Computerkonto mit einem Kennwort, das deutlich älter als 30 Tage ist und trotzdem noch aktiv Anmeldungen durchführt, bedeutet meist einen defekten Secure Channel — nicht einen gehärteten. Und ein statisches Maschinenkennwort gibt einem Angreifer, der das Konto kompromittiert, deutlich mehr Zeit, es per Brute-Force anzugreifen oder zu wiederholen, bevor die Rotation einen Reset erzwingt.

Erkennung

# 1. Prüfen, ob die LAPS-Schemaerweiterung existiert (beide Generationen)
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
    -Filter {name -eq "ms-Mcs-AdmPwd" -or name -eq "msLAPS-Password"}

# 2. Domain Controller, deren Computerobjekt außerhalb der Standard-DC-OU liegt
Get-ADDomainController -Filter * | ForEach-Object {
    $dn = (Get-ADComputer $_.Name).DistinguishedName
    if ($dn -notmatch "OU=Domain Controllers") { "$($_.Name) -> $dn" }
}

# 3. Veraltete Computerobjekte — keine Authentifizierung seit 90+ Tagen
Get-ADComputer -Filter * -Properties lastLogonTimestamp |
    Where-Object { [DateTime]::FromFileTime($_.lastLogonTimestamp) -lt (Get-Date).AddDays(-90) } |
    Select-Object Name, @{N='LastLogon';E={[DateTime]::FromFileTime($_.lastLogonTimestamp)}}

# 4. Computer ohne in AD hinterlegte BitLocker-Recovery-Informationen
Get-ADComputer -Filter * | ForEach-Object {
    $recovery = Get-ADObject -Filter {objectClass -eq "msFVE-RecoveryInformation"} -SearchBase $_.DistinguishedName
    if (-not $recovery) { $_.Name }
}

# 5. Maschinenkontokennwort älter als die 30-Tage-Richtlinie
Get-ADComputer -Filter * -Properties PasswordLastSet |
    Where-Object { $_.PasswordLastSet -lt (Get-Date).AddDays(-30) } |
    Select-Object Name, PasswordLastSet

Behebung

1. Das LAPS-Schema einmalig domänenweit erweitern

Führen Sie Update-LapsADSchema (Windows LAPS) aus — oder Update-AdmPwdADSchema, falls die Organisation bewusst beim klassischen LAPS bleibt — als Mitglied von Schema Admins, und delegieren Sie anschließend mit Set-LapsADComputerSelfPermission das SELF-Schreibrecht auf die neuen Attribute, bevor Sie die GPO ausrollen.

2. Falsch platzierte DC-Objekte zurück in Domain Controllers verschieben

Verschieben Sie das Computerobjekt mit Move-ADObject oder ADUC, und bestätigen Sie anschließend mit gpresult /r auf dem betroffenen DC, dass die Default Domain Controllers Policy wieder greift.

3. Inaktive DCs bewusst beheben oder stilllegen

Zeigt repadmin /showrepl einen echten Replikationsfehler, beheben Sie ihn. Ist der DC tatsächlich nicht mehr vorhanden, führen Sie eine ordentliche Metadatenbereinigung durch, statt das verwaiste Objekt und die DNS-Einträge stehen zu lassen.

4. Veraltete Computer nach festem Zeitplan deaktivieren, dann löschen

Zum Beispiel deaktivieren nach 90 Tagen Inaktivität und löschen nach 180 — dieselbe Disziplin, die bereits bei veralteten Benutzerkonten angewendet wird.

5. BitLocker mit TPM und AD-Schlüsselhinterlegung aktivieren

Priorisieren Sie zuerst die Domain Controller über die GPO-Einstellung „BitLocker-Wiederherstellungsinformationen in Active Directory Domain Services speichern", damit msFVE-RecoveryInformation befüllt und damit prüfbar wird.

6. Die 30-Tage-Richtlinie für das Maschinenkennwortalter unangetastet lassen

Untersuchen Sie statt zu ignorieren jede aktive Maschine, deren PasswordLastSet deutlich darüber hinausgedriftet ist — meist behebt Test-ComputerSecureChannel -Repair einen defekten Secure Channel, der die Rotation still blockiert.

Wie EtcSec das erkennt

Das Active-Directory-Audit von EtcSec prüft alle sechs dieser Bedingungen direkt gegen die Domäne: COMPUTER_NO_LAPS für eine fehlende Schemaerweiterung, DC_NOT_IN_DC_OU und DC_INACTIVE für Platzierung und Replikationszustand der Domain Controller, COMPUTER_STALE_INACTIVE für ungeprüfte ruhende Maschinen, COMPUTER_NO_BITLOCKER für nicht hinterlegte Datenträgerverschlüsselung und COMPUTER_PASSWORD_OLD für stehengebliebene Rotation der Maschinenkennwörter.