In Azure ausgeführte Server und Clients können selbstverständlich Mitglied einer ADDS-Domäne sein. Das ist aus verschiedenen Gründen manchmal zwingend notwendig, etwa wenn Sie ihre Server via Gruppenrichtlinien oder SCCM verwalten/konfigurieren müssen. Ein weiteres Szenario bestünde darin, dass Sie Anwendungen in die Cloud migrieren, die nur Legacy-Protokolle verstehen oder Authentifizierungsmechanismen nutzen, die nur im ADDS-Domänen-Kontext funktionieren, wie Kerberos oder NTLMv2.
Selbstverständlich ist Microsoft mittel- und langfristig bestrebt, die Abhängigkeiten im Rahmen einer Cloud-Migration von einem lokalen Active Directory zu reduzieren. Ansätze dazu gibt es Viele, daher habe ich einen neuen Kurs „Azure-Hybrid-Workshop“ (Termine und Agenda in Kürze; individuelle Anfragen an sofort via Kontakt oder telefonisch) konzipiert, denn die allermeisten Unternehmen finden sich nicht in der luxuriösen Situation wieder, Ihr Geschäftsmodell auf der grünen Wiese in der Cloud umsetzen zu können, sondern stecken in einem mehr oder weniger komplexen Hybrid-Szenario. Solchen Hybrid-Szenarien umfassen viele unterschiedliche Aspekte wie z.B. …
- Identitäten, SingleSignOn und Entra ID Connet
- Netzwerk, VPN, Express Route, Firewall
- Server- und Client-Management, hier vor allem mit dem Fokus Intune, Azure Arc und Azure Local
All diese Aspekte werden in meinen neuen 3-tägigen Powerworkshop thematisiert.
Möchten Sie aus den in der Einleitung genannten Gründen ihre in Azure ausgeführten Server- und Clients über eine lokale Active Directory Domäne verwalten gibt es ebenfalls zahlreiche Möglichkeiten, die in meinem neuen Kurs besprochen werden. Sie könnten z. B. auch Ihren Domänen-Controller ganz oder teilweise in die Cloud migrieren. Das geht auch step-by-step, wenn Sie für die Multimaster-Replication eine private Sichtverbindung bereitstellen, z. B. via VPN.
Auf die gleiche Weise könnten Sie beispielsweise auch eine zweite ADDS-Domäne in der Cloud auf Basis von Azure-VMs betreiben, die die eine Vertrauensstellung zu Ihrer ADDS-Domäne pflegt. Ferner bietet Microsoft mit dem „Entra ID Domain Services“ auch einen verwalteten Dienst in Azure an, der für Sie eine Cloud-basierte ADDS-Domäne hostet, die dem Entra ID vertraut und bei der Sie sich nicht um das Bereitstellen und Warten virtueller Maschinen kümmern müssen. Auch diese Themen werden in meinen neuen Hybrid-Kurs erklärt.
Domänen-Beitritt – die Methoden
In diesem Beitrag hier möchte ich Ihnen zunächst nur zwei Methoden zeigen, wie ihre Azure-Windows-VM einer bestehenden ADDS-Domäne beitreten kann, abgesehen von „manuell“, wäre das per „VM-Extension“ oder unter Zuhilfenahme eines fertigen ARM-Templates aus der Quickstart-Galerie, welches letztendlich ebenfalls eine VM-Erweiterung initiiert. Selbstverständlich können Sie alles, was Sie im Azure-Portal klicken, auch per Azure Powershell oder Azure CLI initiieren oder selbst (on-the-fly oder nachträglich) in ein ARM- oder Bicep-Template verpacken.
DNS-Server und „Sichtverbindung“
Wie in der Einleitung skizziert, müssen Sie für den Domänenbetritt technische Voraussetzungen schaffen vor allem in puncto Netzwerkwerk, d. h. Ihr Member-Server oder Client muss den Domaincontroller (über seine private IP-Adresse) „sehen“ können und zur Namensauflösung den DNS-Server der ADDS-Domäne verwenden. Auch diese Themen werden in meine Hybrid-Kurs behandelt.
Für diesen Beitrag mache ich es mir insofern einfach, dass ich den im „gedachten“ Hybrid-Szenario lokalen Domain Controller auf einer Azure-VM betreibe. Domain Controller und Member-Server sind dann beide Azure VMs (Erstere als „Fake“ für einen lokalen DC), befinden sich also im gleichen virtuellen Azure-Netzwerk, was das Problem der „Sichtverbindung“ zum Domaincontroller löst. Sie müssen dann nur noch die private IP-Adresse der Domain-Controller VM in ihrem Member-Server-Netzwerk als benutzerdefinierten DNS-Server verwenden, zumindest dann, wenn der Domain-Controller gleichzeitig auch als DNS-Server fungiert.
Die Member-Server-VMs müssen also den „richtigen“ Nameserver zur Namensauflösung nutzt. Dazu müssen Sie den Standard-DNS-Server des virtuellen Azure Netzwerks durch einen benutzerdefinierten DNS-Server ersetzen, in unserem Fall also der Domaincontroller selbst wie folgende Abbildung zeigt.
Methode 1: VM-Erweiterung bei der grafischen VM-Bereitstellung im Azure-Portal
Lassen Sie uns nun einen ersten Member-Server mit dem Namen „memserv1“ direkt im Rahmen der Bereitstellung hinzufügen. Das Illustrieren des manuellen Beitritts über die Systemsteuerung, bzw. den Einstellungs-Dialog in Windows spare ich mir hier, weil der genauso funktioniert, wie bei jedem anderen virtuellen oder physischen Windows-Device.
Klicken Sie daher nun im Bereitstellungsassistent einer neuen Azure-VM mit Windows (hier Server 20219) im Tab „Erweitert“ auf den etwas unscheinbaren Link „Zu installierende Erweiterung auswählen“.
Suchen Sie dann im Extensions-Marktplatz „Erweiterungen installieren“ nach „Custom script extension“.
Klicken Sie auf „Weiter“, können Sie ein (PS) „Script file“ auswählen, welches Sie zuvor in einem Blob-Speicher auf einem Storage Account bereitgestellt haben müssten. Das können Sie aber auch „On-the-Fly“ erledigen.
Klicken Sie also auf „Durchsuchen“ und wählen ein passendes Speicherkonto aus oder erstellen mit „+ Speicherkonto“ ein Neues. Erstellen Sie dann mit „+ Container“ einen neuen Blob-Container mit dem Namen „scripts“ (oder ähnlich). Der Name selbst tut nichts zur Sache.
Navigieren Sie dann „in“ den neuen Container und laden mit „Hochladen“ eine vorher vorbereitete Powershell-Datei (.ps1) mit folgendem Inhalt hoch:
Set-AzVMExtension -ResourceGroupName „<Resourcegroup-Name>“ -VMName „<VM-Name>“ -Name „JsonADDomainExtension“ -Publisher „Microsoft.Compute“ -Type „JsonADDomainExtension“ -TypeHandlerVersion „1.3“ -Settings @{
„Name“ = „<ADDS-Domain-name>“;
„OUPath“ = „OU=<Your OU>,DC=“<ADDS-Domain-name>,DC=de“;
„User“ = „<Domain-Admin-User-Name>“;
„Restart“ = „true“;
„Options“ = „3“;
} -ProtectedSettings @{
„Password“ = „<Your Password>“;
}
Ersetzen Sie dabei „<Resourcegroup-Name>“,“<VM-Name>“,“<ADDS-Domain-name>“,“<Your OU>“ und „<Domain-Admin-User-Name>” durch Ihre Daten.
Markieren Sie dann die hochgeladene Skript-Datei und klicken auf „Auswählen“ …
… und zurück auf der Dialog-Ebene „Configure Custom script Extension“ auf „Erstellen“.
Klicken Sie abschließend auf „Überprüfen und Erstellen“ und beobachten entweder den Verlauf oder kontrollieren das Aktivitätsprotokoll. Hier sollten Sie nach einigen Minuten eine erfolgreiche Vollzugsmeldung der CustomScript-Erweiterung beobachten können.
Methode 2: ARM-Template
Die Methode 2 nutzt intern zwar die gleiche Extension ist aber formal in ein deklaratives Bereitstellungstemplate verpackt. Sie finden es u. a. in der Azure Quickstart Templates Gallery. Suchen Sie z. B. nach „Join“ und wählen das Template „Join a VM to an existing domain“.
Von der Detailseite „Join“ und wählen das Template „Join a VM to an existing domain“ aus haben Sie die Möglichkeit, diese Extension mit „Deploy to Azure“ direkt in Ihrem Azure-Account bereitzustellen oder Sie wechseln mit „Browse code“ in das zugehörige GitHub-Repository, um die Vorlage von dort aus herunterzuladen (etwa für persönliche Anpassungen) oder von dort aus bereitzustellen.
Ich entscheide mit für die direkte Bereitstellung in Azure. Hierzu müssen Sie sich zunächst mit dem gewünschten Azure-Account anmelden und dann die Parameter-Werte für das Template entsprechend Ihrer Umgebung bestücken. Das betrifft neben „Abonnement“, „Ressourcengruppe und „Region“ folgende Parameter:
- Existing Vnet Name
- Existing Subnet Name
- DNS Label Prefix
- Domain to Join
- Domain Username
- Domain Password
- OU Path
- Domain Join Options
- Admin User Name
- Admin Password
- Storage Account Name
- Location
Die meisten Werte sind selbsterklärend. Das Template erzeugt eine neue VM und fügt diese dann einer bestehenden ADDS-Domäne zu. Achten Sie darauf, den Domain-Admin vom VM-Admin zu unterschieden, sofern Sie für beide unterschiedliche Kontonamen verwendet haben. Der Storage Account wird nur für Diagnosedaten benötigt und automatisch erzeugt. Die vorgeschlagene VM-Größe „A1“ habe ich gegen eine „B2S“ getauscht. Bei mir sieht das z. B. so aus:
Klicken Sie dann wie üblich auf „Überprüfen und Erstellen“ und dann auf „Erstellen.
Am Ende dieses kleinen Experimentes haben wir zwei neue VMs „memserv1“ und „memserv2“ mit Windows Server 2019 Datacenter, die beide der Domäne „adatumadds.de“ beigetreten sind und sich in der OU „Infra“ befinden.
Zur Überprüfung könnten Sie beide VMs über die Console verbinden und dann im Server Manager bei „Benutzer und Computer“ nachsehen oder Sie führen einfach von „außen“ mit Hilfe des Azure-VM-Agenten im Azure-Portal unter „Vorgänge“ eine Skriptausführung durch, z. B. „dsregcmd /status“:
