VMs in Azure verwalten
Mit selektivem und restriktivem Zugriff auf das WAC verbessert sich automatisch die Sicherheit der Managementumgebung. Doch mit WAC können Sie nicht nur Server im lokalen Datenzentrum verwalten. Auch Systeme in der Azure-Cloud lassen sich damit administrieren.

Damit das lokale WAC mit Azure-Diensten kommunizieren kann, muss WAC als Gateway einmalig in Azure registriert werden. Diese Konfigurationsoption steht beim ersten Start des WAC-Portals zur Auswahl. Wer das Pop-up weggeklickt hat, kann die Einstellung über das Zahnradsymbol und das linke Menü "Register" wiederfinden. Im Rahmen der Konfiguration wird eine Applikation in Azure AD angelegt. Diese ist für die spätere Kommunikation zwischen WAC und Azure erforderlich und kommt auch dafür zum Einsatz, Single Sign-on (SSO) über Azure AD anzubieten.

Für die Verwaltung von virtuellen Maschinen über WAC in Azure ist der Installationsort des Portals entscheidend, denn natürlich müssen die Verwaltungsmaschinen mit den Zielcomputern Kontakt aufnehmen können. Wenn die Verwaltung überwiegend in Azure stattfindet, lohnt eine Installation von WAC in eine Azure-VM. Dann gilt es, die Konfiguration der VMs und der Azure Ressourcen anzupassen, sodass sich WAC mit allen Rechnern besprechen kann. Das bedeutet, dass Firewalls zwischen VNets geöffnet werden. Werden die allermeisten Server weiterhin on-premises laufen, ist es einfacher, das Windows Admin Center lokal zu betreiben und dann mit Azure zu verbinden, als das WAC in Azure zu nutzen und dann per VPN zu verbinden.

Damit der Zugriff auf die Server durch WAC erfolgen kann, muss WinRM entsprechend konfiguriert sein. Dies führen Sie wie in manch anderen Szenarien mittels winrm quickconfig in einer Kommandozeile auf dem Zielsystem durch. Weiter müssen Sie den TCP-Port 5985 für "WinRM over http" zur Verwaltung für "inbound connections" öffnen. Auch dies lässt sich einfach per Befehl einrichten:

Set-NetFirewallRule -Name WINRM-HTTP-In-TCP-PUBLIC -RemoteAddress Any

Entsprechend müssen Sie diesen Port bei Azure Networking konfigurieren. Es bietet sich hier an, eine statische IP-Adresse für WAC zu verwenden, damit sich der Zugriff auf die Zielsysteme entsprechend auf einen Server oder ein System einschränken lässt. Damit der Zugriff erfolgt, müssen Sie nun lediglich das System in WAC hinzufügen.

Dies erfolgt zum Beispiel über eine öffentliche IP-Adresse. Kommen interne IP-Adressen zum Einsatz, muss entsprechend eine Point-to-Site-VPN-, Site-toSite-VPN- oder ExpressRoute-Verbindung nach Azure bestehen. Ein Artikel auf der Microsoft-Homepage bietet eine gute Anlaufstelle, sollte diese Verbindung noch nicht bestehen.

Authentifizierung via Entra ID
Die Integration des Windows Admin Centers funktioniert in dreierlei Form: Zum einen können Sie Entra ID – vormals Azure AD – als Identity Provider nutzen, um Single Sign-on zu WAC anbieten zu können. Das ist hilfreich, wenn schon eine SSO-Unterstützung für andere Clouddienste besteht. Da das WAC-Portal strikt auf HTTPS basiert, ist eine Integration einfach. Der zweite Grund für eine Integration sind die Schutzmöglichkeiten mit Conditional Access. Administratoren des WAC-Portals können gezwungen werden, sich auf einer verwalteten Maschine und mindestens einmal mit Multifaktor-Authentifizierung (MFA) zu verifizieren. Das schützt die im WAC administrierten Server und geht mit Entra ID deutlich einfacher als mit Mechanismen im Windows-AD.

Zuletzt bietet Entra ID Funktionen, das WAC-Portal sicher ins Internet zu veröffentlichen. Wer WAC auf einem internen Server betreibt, für bestimmte Tätigkeiten aber auch von zu Hause ohne VPN-Administration zur Verfügung stellen will oder zumindest lesend für Troubleshooting oder Hilfestellung von Admin-Kollegen, könnte davon profitieren. Mit dem Entra ID AppProxy und dem Schutz von Conditional Access veröffentlichen Sie WAC sicher, ohne die Firewall aufbohren zu müssen.

Den ersten Schritt, SSO zu erlauben, führen Sie in WAC selbst aus. In den Einstellungen des WAC navigieren Sie zu "Settings" und dann "Access". Nachdem Sie Ihren Tenant-Namen angegeben haben, öffnet sich ein Pop-up-Fenster im Browser, das sie zur Anmeldung mit den Azure-AD-Anmeldedaten auffordert. Für die automatische Erstellung benötigen Sie Tenant-Administrator-Berechtigungen oder die Rolle "Application Administrator".

Wenn Sie das manuelle Erstellen des Service Principals bevorzugen, ist dies im Entra ID wie bei Microsoft beschrieben möglich. Sie hinterlegen dabei eine Applikationsregistrierung und ein Service Principal ("Enterprise Registration") mit der notwendigen Konfiguration und GraphBerechtigungen sowei Consent. Dann ist das Admin Center als Referenz unter "Enterprise Apps" im Azure-AD-Portal zu finden. Die Referenz trägt den Namen "WindowsAdminCenter", gefolgt von der URL, unter der sie registriert wurde.

Für SSO müssen Sie den WAC-Administratoren die Anwendung zuweisen – das geht unter "Users and Groups" im Azure-AD-Portal, nachdem Sie die neu erstellte Anwendung ausgewählt haben. Bei der Zuweisung von Benutzern können Sie sowohl Benutzer als auch Gruppen wählen – in diesem Schritt definieren Sie ferner, ob die Zieladministratoren Gateway-Administratoren oder Gateway-Benutzer sind. Die Unterscheidung ist für WAC wichtig – hier dürfen die Gateway-Administratoren Veränderungen am WAC-Portal durchführen, während die Benutzer allein auf die Zielmaschinen Zugriff haben und dort Administration betreiben dürfen.

Sind die Benutzer zugewiesen, navigieren Sie zu "Permissions" und erteilen WAC die Erlaubnis, auf die Profile anzumeldender Benutzer zuzugreifen. In "Admin Consent" klicken Sie auf "Grant admin consent". Anschließend sind Sie dann in der Lage, eine Conditional-Access-Regel für Ihre Bedürfnisse zu erstellen.

Fazit
Das Windows Admin Center hilft beim Delegieren von Berechtigungen auf Windows-Servern. Die Systeme können dabei klassische Server im eigenen Datenzentrum sein, hybride Implementierungen mit Rechnern im eigenen Datenzentrum und Azure – oder komplett in Azure. Sie können dabei steuern, welche Administratoren auf welche Funktionen auf Zielservern zugreifen können, ohne dass die Mitarbeiter eine physische oder RDP-Verbindung auf die Maschinen benötigen.

ln/jp/Frank Tess

Im ersten Teil des Workshops gingen wir darauf ein, wie bei der rollenbasierten Administration das Tier-Modell von Microsoft helfen kann und was es dabei mit PowerShell JEA auf sich hat. Im zweiten Teil haben wir erklärt, wie Sie Standardrollen anpassen, lokale Gruppen in AD-Gruppen umwandeln und JEA auf mehreren Servern ausrollen.