Azure-Tipp: Was tun, wenn du dich aus der eigenen Azure-VM ausgesperrt hast

Legst du täglich sehr viele Azure-VMs an oder bist für die Verwaltung einer großen Zahl von Azure-VMs verantwortlich, kann es schon Mal passieren, dass die Anmeldedaten verloren gehen, sei es wegen mangelnder Dokumentation oder dadurch, dass ehemals verantwortliche Admins das Unternehmen verlassen oder du eine bestehende Azure-Infrastruktur von einem Kunden übernommen hast. Wie du dann wieder an deine VM(s) herankommst, zeigt dir dieser Kurztipp.

Du benötigst mehr Know-how rund um MS Azure? Dann empfehlen wir dir unsere Microsoft Azure Schulungen!

Um ein vergessenes oder verlorenes Passwort zurücksetzen zu können, musst du zunächst einmal das Benutzerkonto wissen, das bei der Erstellung der VM ursprünglich angelegt wurde. Hier gibt es verschiedene Wege, den verwendeten Anmeldenamen herauszubekommen.

Du kannst z. B. im Azure Portal bei ausgewählter VM im Menüabschnitt „Operations“ den Eintrag „Run command“ aufrufen, um sozusagen „von außen“ ein Powershell-Command oder Skript gegen die VM laufen zu lassen, wie z. B. „Get-LocalUser“. Die Ausführung kann allerdings etwas Zeit in Anspruch nehmen, weil das Ausführen von PowerShell-Befehlen gegen die Azure-VM auf der Kommunikation über den Azure-VM-Agenten basiert:

Offensichtlich hieß das Konto hier „azureuser“.

Dieser Weg setzt voraus, dass auf der VM der Azure-VM-Agent auch läuft. Bei Machine Images, die aus dem Marketplace von Microsoft stammen, wird dessen Installation automatisch bei der Bereitstellung erfolgen. Bei Custom Images musst du dagegen selbst dafür sorgen müssen, den Azure-VM-Agenten zu https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/agent-windows installieren. Per Default wird die entsprechende Funktionalität bei Windows-VMs (Gastkonfigurationserweiterung) mit dem Namen „AzurePolicyforWindows“ im Rahmen eine Azure-Policy erzwungen, die wiederrum als VM-Extension bereitgestellt wird. Du kannst das leicht kontrollieren, indem du im Abschnitt „Settings“ auf „Extensions + applications“ klickst.

Liest man das eben Gesagte genau, klingt es wie ein Zirkelschluss. Genau genommen besteht nämlich das Windows-Gast-Agent-Paket aus zwei Teilen, dem Bereitstellungs-Agent (PA) und dem Windows-Gast-Agent (WinGA). Beim Starten einer VM (aus einem Machine Image) muss nur der PA auf der VM installiert, d. h. Teil des Machine Images sein, nicht aber der WinGA. Dessen Installation wird bei der Bereitstellung über den beschriebenen Mechanismus nachgezogen. Für das Ausführen des Windows-VM-Agenten sind mindestens Windows Server 2008 SP2 (64 Bit) und .NET Framework 4.0 erforderlich. Ferner muss die betreffende VM-Zugriff auf die IP-Adresse 168.63.129.16 haben. Hierbei handelt es sich in der Azure-Plattform um eine virtuelle öffentliche IP-Adresse, die Azure verwendet, um einen Kommunikationskanal zu den Ressourcen der Azure-Plattform zu etablieren. Ferner muss DHCP auf der Gast-VM aktiviert sein, damit die Host- oder Fabric-Adresse des Dynamic Host Configuration-Protokolls (DHCP) für den IaaS-VM-Agent und die Erweiterungen funktioniert. 

Azure Ressource Manager (ARM) Vorlage nutzen

Ein anderer (schnellerer) Weg zum Ermitteln des Benutzernamens läuft nicht über den VM-Agenten, sondern macht sich die deklarative Bereitstellungs-Vorlage einer jeden Azure-Bereitstellung (Azure Resource Manager Template – ARM) zunutze, welche der Azure Resource Manger aus jeder bestehenden Bereitstellung zu erzeugen in der Lage ist, sofern du die VM-Bereitstellung nicht ohnehin schon deklarativ vorgenommen hast. Hierzu musst du im Anschnitt „Automation“ auf „Export template“ klicken. Das verwendete Benutzerkonto findest du dann im Abschnitt „osProfile“:

Dass du auf diesem Weg nicht an das verwendete Passwort heran kommst, versteht sich von selbst, denn dies würde ein Sicherheitsrisiko darstellen.

Passwort-Reset

Was du aber tun kannst, ist das verwendete Passwort zurückzusetzen. Dazu navigierst du im Abschnitt „Help“ zu „Reset password“ und setzt ein neues Kennwort für den ermittelten Benutzernamen, indem du auf „Update“ klickst.

Allerdings läuft auch dieser Vorgang über den oben erwähnten VM-Agenten. Davon kannst du sich leicht überzeugen, wenn du das Passwort per Powershell zurücksetzt:

$SubID = "<SUBSCRIPTION ID>"
$RgName = "<RESOURCE GROUP NAME>"
$VmName = "<VM NAME>"
$Location = "<LOCATION>"

Connect-AzAccount
Select-AzSubscription -SubscriptionId $SubID
Set-AzVMAccessExtension -ResourceGroupName $RgName -Location $Location -VMName $VmName -Credential (get-credential) -typeHandlerVersion "2.0" -Name VMAccessAgent

Offline-Reset

Selbstverständlich funktioniert dieser Weg nicht für Domain Controller-VMs. Solltest du auf diesem Wege nicht weiterkommen, musst du das Konto offline zurücksetzen. Hier gehst du im Prinzip wie folgt vor:

1. Beende die betroffene VM.
2. Erstelle einen Snapshot für den Betriebssystem-Datenträger der VM.
3. Erstelle aus dem Snapshot eine Kopie des Betriebssystem-Datenträgers.
4. Hänge den kopierten Betriebssystem-Datenträger an eine andere Windows-VM an, deren Zugangsdaten du hast, bzw. mounte den kopierten Datenträger und erstelle dann einige Konfigurationsdateien auf diesem, die dir helfen, das Passwort zurückzusetzen.
5. Hebe die Bereitstellung auf und trenne den kopierten Betriebssystem-Datenträger von der Fehlerbehebungs-VM.
6. Tausche den Betriebssystemdatenträger für die betroffene VM aus.

Was dabei im Detail für https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/reset-local-password-without-agent Windows-VMs, bzw. https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/reset-password Linux-Ms zu tun ist, erläutert Microsoft sehr ausführlich in der jeweiligen Dokumentation.

Neues Konto

Manchmal wirst du beim Zurücksetzen des Zugangs zu deiner Azure-VM auch gleich ein neues Konto anlegen wollen, auch wenn der reine Passwort-Reset in der Regel ausreicht, weil solche „Admin“-Konten selten personalisiert sind. Du kannst im gleichen Dialog zum Zurücksetzen des Passworts einfach ein neues Konto angeben und damit anlegen; bestimmte User-Namen wie „admin“ sind in Azure natürlich tabu.

Damit wird bei einer Windows-VM auch gleich die RDP-Konfiguration zurückgesetzt und du kannst dich mit den neuen Benutzerdaten per RDP mit der VM verbinden, sofern diese über eine öffentliche IP-Adresse verfügt, über einen Bastion-Host, eine Destination-NAT-Rule in einem Azure Loadbalancer oder über eine Destination-NAT-Rule in der Azure Firewall erreichbar ist.