Heute Mal wieder ein handfester Praxisbeitrag. Der hat auch nur bedingt was mit Azure zu tun; nur insofern, dass der Domain-Controller selbst eine Azure-VM ist. Letzteres ist allerdings ein entscheidender Vorteil, weil 2 von 3 der im Folgenden vorgeschlagenen Methoden überhaupt erst ermöglicht. Die dritte Methode – das Eingängen der OS-Disk des betreffenden DC in eine neue VM – wird unabhängig von Azure überhaupt erst dadurch praktikabel, dass es sich um eine virtuelle Maschine handelt. Dies würde bei AWS, Hyper-V oder VMware aber ebenfalls funktionieren. 

Bevor wir zu starten, möchte ich eine möglicherweisen berechtigten Kritikpunkt von vorne herein den Wind aus den Segeln nehmen. Selbstverständlich darf man in der Praxis ein Domain-Controller-Passwort ohnehin unter keinen Umständen verlieren. Wie kann das überhaupt passieren. Nun – in setze im Rahmen meine Rahmen meine Training regelmäßig (nahezu wöchentlich) neu AD-Domänen auf Basis von Azure-VMs auf, welche dann quasi einen lokalen Standort simulieren. Diese sind als Demo-Umgebungen für viele Identitätsverwaltungsfunktionen, insbesondere für Entra ID Connect gedacht. Da kanne s schon Mal vorkommen, dass man sich ein Passwort nicht notiert, denke ich.

Prinzipiell steht ja bei Azure-VMs generell über den Azure-VM-Agenten eine einfache Möglichkeit, das „lokale“ Administrator-Passwort zurückzusetzen. Die Funktion findet im VM-Menü unter „Hilfe / Kennwort“ zurücksetzen. Hier können Sie je nach Bedarf das Kennwort eines bekannten Kontos zurücksetzen oder ein neues Passwort für ein neu anzulegendes Konto festlegen. Dazu muss die VM selbstverständlich eingeschaltet sein.

Das Kennwort einer gewöhnlichen Azure-VM lässt sich relativ einfach über den AM-Agenten zurücksetzen.
Das Kennwort einer gewöhnlichen Azure-VM lässt sich relativ einfach über den AM-Agenten zurücksetzen.

Sollten Sie selbst das lokale Administrator-Konto nicht mehr kennen, können Sie z. B. bei einer Windows-VM ebenfalls mit Hilfe des VM-Agenten unter „Vorgänge / Skriptausführung“ einfach ein Powershell-Skript ausführen, wie z. B.

Get-LocalUser

Der Benutzername eines lokalen Kontos lässt sich über die Skriptausführung leicht ermitteln.
Der Benutzername eines lokalen Kontos lässt sich über die Skriptausführung leicht ermitteln.

Das hilft Ihnen aber nur in Bezug auf das lokale Administratorkonto. Bei einem Domaincontroller kommen Sie so nicht weiter, da es ja um das Domänenkonto geht. Das Vergessen/Verlieren des betreffenden Passworts ist zwar ein Klassiker und leider auch ein kritischer Zustand – aber in den meisten Fällen lässt sich das wieder richten, solange Sie physischen/Consolen-Zugang zur VM haben, was bei einer Azure-VM normalerweise der Fall sein sollte. 

Die weiteren Schritte hängen davon ab, ob Sie das DSRM-Passwort (Directory Services Restore Mode) noch haben (im meinem Fall leider auch das nicht). Gehen wir aber im Folgenden für ein erstes Szenario davon aus, dass das noch der Fall ist.

Variante 1: Reparatur mit Azure-Mitteln, wenn DSRM bekannt

  1. Azure Portal → Ihre DC-VM → „Serial console“ (SAC) öffnen oder via „Run command“ → „EnableRemotePS“ + RDP.
  2. VM in DSRM-Modus neu booten:
    • Am einfachsten: In der Serial Console „bcdedit /set safeboot dsrepair“ eingeben und „reboot“.
    • Alternativ: Boot-Optionen über Azure „Boot diagnostics“ Screenshot oder Custom Script Extension manipulieren.
  3. Beim Neustart bootet die VM automatisch in DSRM.
  4. Mit dem DSRM-Passwort anmelden (lokaler Account .\Administrator).
  5. Dann im DSRM-Modus das Domänen-Administrator-Passwort zurücksetzen:
    net user Administrator NeuesSuperPasswort123!

    oder eleganter per PowerShell:

    Import-Module ActiveDirectory
    Set-ADAccountPassword -Identity Administrator -NewPassword (ConvertTo-SecureString "NeuesPasswort!" -AsPlainText -Force)
  6. Wieder normal booten:
     
    bcdedit /deletevalue safeboot
    reboot

Variante 2: Azure „Password Reset“ Blade mit Offline-Domain-Reset (seit 2022/2023 stark verbessert)

Azure hat wie o. g.  auch eine integrierte Funktion, die genau für einen Passwort-Reset gedacht ist. Bei einem DC muss man allerdings so vorgehen:

Schritt 1

Azure Portal → Ihre DC-VM → Hilfe → Kennwort zurücksetzen→ Modus „Nur Konfiguration zurücksetzen“. Danach können Sie mittels „Vorgänge / Skriptausführung → „ConfigureLocalAdmin“ oder ein Custom Script das Passwort des built-in Administrators setzen. Im Detail, hier ein passendes PS-Skript für Schritt 1

#Lokalen Administrator aktivieren und Passwort setzen

 net user Administrator DeinNeuesPasswort123! /active:yes

Sicherstellen, dass er beim nächsten Boot auch wirklich da ist (manchmal blockiert Azure das sonst noch) 

Set-LocalUser -Name Administrator -Password (ConvertTo-SecureString "DeinNeuesPasswort123!" -AsPlainText -Force) -PasswordNeverExpires $true

# Direkt in DSRM booten vorbereiten (spart dir einen weiteren Neustart) bcdedit /set safeboot dsrepair

# Neustart starten Restart-Computer -Force

Schritt 2

Anschließend im Offline-Modus (DSRM) das AD-Passwort zurücksetzen:

  • Warten Sie, bis die VM wieder hochkommt (dauert 2–4 Minuten).
  • Öffnen Sie erneut die Serial console (SAC) oder verbinden sich per RDP (falls RDP jetzt wieder geht).
  • Sie sehen jetzt den speziellen Anmeldebildschirm mit „Directory Services Restore Mode“.
  • Melde dich an als: .\Administrator an mit dem neuen Passwort

Schritt 3

Sobald Sie in der SAC sind öffnen Sie eine CMD als Administrator und führen Folgendes aus:

net user Administrator DomänenNeuesPasswort456! /domain

oder (noch sauberer) per PowerShell:

Import-Module ActiveDirectory
Set-ADAccountPassword -Identity "Administrator" -NewPassword (ConvertTo-SecureString "DomänenNeuesPasswort456!" -AsPlainText -Force) -Reset
Set-ADUser -Identity "Administrator" -ChangePasswordAtLogon $false

Schritt 4

Wieder normal booten. Dazu geben Sie in der CMD Folgendes ein:

bcdedit /deletevalue safeboot shutdown /r /t 0

Haben Sie tatsächlich auch das DRSM-Passwort vergessen, dann helfen nur härte Methoden, wie eine offline laufenden Domain-Controller-Reparatur. Hier müssen Sie die die DC-VM-OS-Disk de-tachen und in eine neue temporäre Reparatur-VM mounten und dort die  SAM-, SYSTEM- und SECURITY-Hives mit

reg load HKLM\TempSAM

in die Registry der Hilfs-VM laden. Das geht wahlweise mit Windows-Bordmitteln oder einem speziell dafür geeigneten Linux-Werkzeug. Wie das geht, zeige ich dann im Folge-Beitrag.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden.