Das Windows Azure Pack bietet von Haus kein AD Single Sign On an. Das heißt für das Admin Portal wird zwar auf die Windows Authentication zurückgegriffen, aber wer auf das Portal zugreifen darf wird in einer lokalen Gruppe auf dem Server des Windows Azure Pack definiert. Damit können auch lokale Benutzerkonten Zugriff auf das Admin Portal erhalten. Um das Tenant Portal benutzen zu können, muss man sich mit seiner E-Mailadresse und einem benutzerdefinierten Passwort anmelden beziehungsweise vorher registrieren. Das mag alles für einen Cloud Service Provider wunderbar passen, aber wenn das Windows Azure Pack nur für On-Premise Zwecke zum Einsatz kommt möchte man die Authentifizierung über das Active Directory durchführen.
Für die Einrichtung des Admin & Tenant Portal AD Single Sign On werden die folgenden Komponenten benötigt:
- Mehrere Zertifikate oder alternativ ein Wildcard Zertifikat für die Domain
- Drei DNS A-Record Einträge
- Ein ADFS Server
Meine Infrastruktur in der Demo Umgebung besteht aus den folgenden Systemen.
| Rolle | Server | Funktion |
| Active Directory | DC-1.neumanndaniel.local (10.0.0.1) DC-2.neumanndaniel.local (10.0.0.2) |
ADDS, DHCP, DNS, WSUS ADDS, DHCP, DNS, ADFS |
| VMM | SRV-1.neumanndaniel.local (10.0.0.5) | VMM, App Controller, SQL |
| SCOM SPF |
SRV-2.neumanndaniel.local (10.0.0.6) | SCOM, SPF, SQL |
| Orchestrator SMA |
SRV-3.neumanndaniel.local (10.0.0.7) | Orchestrator, SMA, SQL |
| DPM | SRV-4.neumanndaniel.local (10.0.0.4) | DPM, SQL |
| Windows Azure Pack | SRV-5.neumanndaniel.local (10.0.0.27) | Windows Azure Pack Express Install, Cloud Cruiser, SQL |
Die Konfiguration wird wie folgt ablaufen:
- Zertifikate erzeugen
- DNS Einträge setzen
- WAP Portalnamen, Ports und Zertifikate neukonfigurieren
- ADFS installieren
- ADFS einrichten
- WAP Authentifizierung umstellen
1.) Zertifikate erzeugen
Wie man oben aus meiner Infrastrukturliste entnehmen kann habe ich keine CA in meiner Demo Umgebung. Daher bediene ich mich eines selbstsignierten Wildcard Zertifikats. Dieses kann man mit makecert aus dem Windows 8.1 SDK erzeugen. Dazu habe ich makecert mit den folgenden Parametern aufgerufen.
makecert.exe -r -pe -n CN=*.neumanndaniel.local -ss my -sr localmachine -len 2048 -e 01/01/2016 ADFSWAP.cer
Danach exportiert man noch per MMC und dem SnapIn Certificates den privaten Schlüssel, so dass man einmal die ADFSWAP.cer und die ADFSWAP.pfx Dateien hat. Um das Wildcard Zertifikat in der kompletten Domain zu verteilen, kann man dieses zum Beispiel in der Default Domain Policy unter folgenden Pfad importieren.
Computer Configuration->Policies->Windows Settings->Security Settings->Public Key Policies->Trusted Root Certification Authorities
2.) DNS Einträge setzen
Nun wechselt man in die DNS Management Konsole und legt die drei A-Records an.
| FQDN | Record Type | IP-Adresse |
| adfs.neumanndaniel.local | A | 10.0.0.2 |
| wapadmin.neumanndaniel.local | A | 10.0.0.27 |
| wapcloud.neumanndaniel.local | A | 10.0.0.27 |
3.) WAP Portalnamen, Ports und Zertifikate neukonfigurieren
Hierzu wechselt man auf den Server des Windows Azure Packs und ruft den IIS Manager auf. Dort wird zuerst das Wildcard Zertifikat importiert.
Anschließend werden die Einstellungen des Binding für die Website MgmtSvc-AdminSite geändert. Diese läuft per Default auf Port 30091 und wird auf Port 443 gelegt. Als Hostname wird wapadmin.neumanndaniel.local vergeben sowie das Wildcard Zertifikat ausgewählt.
Danach wird die Website neugestartet bevor an der Website MgmtSvc-WindowsAuthSite das Wildcard Zertifikat gesetzt wird.
Damit sind die grundlegenden Änderungen für das Admin Portal getätigt. Nun folgen die Änderungen für das Tenant Portal. Hier werden die Einstellungen des Binding für die Website MgmtSvc-TenantSite geändert. Diese läuft per Default auf Port 30081 und wird auf Port 443 gelegt. Als Hostname wird wapcloud.neumanndaniel.local vergeben sowie das Wildcard Zertifikat ausgewählt.
Danach wird die Website neugestartet bevor an der Website MgmtSvc-AuthSite das Wildcard Zertifikat setzt und der Port von 30071 auf 444 geändert wird.
Auch hier wird die Website neugestartet. Nun müssen die Einstellungen nur noch persistent in der Windows Azure Pack Datenbank hinterlegt werden. Dazu verwendet man die folgenden PowerShell Befehle.
Admin Portal
Import-Module MgmtSvcConfig
Set-MgmtSvcFqdn -Namespace “AdminSite” -FullyQualifiedDomainName “wapadmin.neumanndaniel.local” -Port 443 -Server “SRV-5”
Set-MgmtSvcRelyingPartySettings -Target Admin -MetadataEndpoint ‘https://srv-5.neumanndaniel.local:30072/FederationMetadata/2007-06/FederationMetadata.xml’ -ConnectionString “Data Source=srv-5.neumanndaniel.local;User ID=sa;Password=**********”
Set-MgmtSvcIdentityProviderSettings -Target Windows -MetadataEndpoint ‘https://wapadmin.neumanndaniel.local/FederationMetadata/2007-06/FederationMetadata.xml’ -ConnectionString “Data Source=srv-5.neumanndaniel.local;User ID=sa;Password=*********”
Tenant Portal
Import-Module MgmtSvcConfig
Set-MgmtSvcFqdn -Namespace “TenantSite” -FullyQualifiedDomainName “wapcloud.neumanndaniel.local” -Port 443 -Server “SRV-5”
Set-MgmtSvcFqdn -Namespace “AuthSite” -FullyQualifiedDomainName “wapcloud.neumanndaniel.local” -Port 444 -Server “SRV-5”
Set-MgmtSvcRelyingPartySettings -Target Tenant -MetadataEndpoint ‘https://wapcloud.neumanndaniel.local:444/FederationMetadata/2007-06/FederationMetadata.xml’ -ConnectionString “Data Source=srv-5.neumanndaniel.local;User ID=sa;Password=*********”
Set-MgmtSvcIdentityProviderSettings -Target Membership -MetadataEndpoint ‘https://wapcloud.neumanndaniel.local/FederationMetadata/2007-06/FederationMetadata.xml’ -ConnectionString “Data Source=srv-5.neumanndaniel.local;User ID=sa;Password=*********”
Anschließend kann der Zugriff auf das Admin Portal (https://wapadmin.neumanndaniel.local) und das Tenant Portal (https://wapcloud.neumanndaniel.local) über die neuen URLs getestet werden.
4.) ADFS installieren
Um die Active Directory Federation Services zu installieren ruft man den Server Manager auf dem entsprechenden Server auf und startet den Add Roles and Features Wizard.
Nach der erfolgreichen Installation kann die Konfiguration beginnen. Hierzu klickt man auf das Fähnchen im Server Manager, um den ADFS Configuration Wizard zu starten.
Im Abschnitt Welcome wählt man Create the first federation server in a federation server farm aus. Das Benutzerkonto zum Verbinden zum AD sollte Domain Adminrechte besitzen. Unter Specify Service Properties importiert man das Wildcard Zertifikat und wählt dieses dann aus. Als Federation Service Name habe ich adfs.neumanndaniel.local ausgewählt. Der Federation Service Display Name ist in diesem Beispiel ADFS neumanndaniel.local. Bei Specify Database wird in diesem Beispiel die Windows Internal Database verwendet. Danach kann die Konfiguration gestartet werden. Sobald diese Abgeschlossen ist, steht der eigentlichen Einrichtung nichts mehr im Wege.
5.) ADFS einrichten
Für die Einrichtung des ADFS startet man das ADFS Management. Dort wird der Add Relying Party Trust Wizard über die Leiste Actions im rechten Teil des Managements aufgerufen.
Admin Portal
Danach wird mittels eines Rechtsklicks auf den neuen Trust und Edit Claim Rules die Regeln für den Trust hinzugefügt. Der Trust befindet sich dabei unter Trust Relationships->Relying Party Trusts. Die ersten beiden Regeln verwenden die Vorlage Send LDAP Attributes as Claims.
Die zwei weiteren Regeln dann die Vorlage Pass Through or Filter an Incoming Claim.
Jetzt folgt nur noch die Aktivierung der JWT Tokens über das folgende PowerShell Skript.
$WAPAdminTrust=Get-AdfsRelyingPartyTrust -Name “WAP Admin Portal”
Set-AdfsRelyingPartyTrust -TargetIdentifier $WAPAdminTrust.Identifier -EnableJWT $true
Tenant Portal
Wieder ruft man den Add Relying Party Trust Wizard auf. Die Einstellungen sind fast dieselben. Nur die Federation Metadata Address und der Display Name unterscheiden sich.
Die Claim Rules sind identisch mit denen für das WAP Admin Portal.
Abschließend erfolgt die Aktivierung der JWT Tokens.
$WAPTenantTrust=Get-AdfsRelyingPartyTrust -Name “WAP Tenant Portal”
Set-AdfsRelyingPartyTrust -TargetIdentifier $WAPTenantTrust.Identifier -EnableJWT $true
6.) WAP Authentifizierung umstellen
Nun wird wieder auf den Server des Windows Azure Packs gewechselt, um die Authentifizierung umzustellen.
Admin Portal
Import-Module MgmtSvcConfig
Set-MgmtSvcRelyingPartySettings -Target Admin -MetadataEndpoint ‘https://adfs.neumanndaniel.local/FederationMetadata/2007-06/FederationMetadata.xml’ -ConnectionString “Data Source=srv-5.neumanndaniel.local;Initial Catalog=Microsoft.MgmtSvc.PortalConfigStore;User ID=sa;Password=**********”
Danach habe ich die Gruppe der Enterprise Admins für den Zugriff auf das Admin Portal freigeschaltet. Hier kann man entweder einzelne Benutzer oder Gruppen angeben.
Add-MgmtSvcAdminUser -Principal ‘NEUMANNDANIELEnterprise Admins’ -ConnectionString “Data Source=srv-5.neumanndaniel.local;Initial Catalog=Microsoft.MgmtSvc.Store;User ID=sa;Password=**********”
Tenant Portal
Import-Module MgmtSvcConfig
Set-MgmtSvcRelyingPartySettings -Target Tenant -MetadataEndpoint ‘https://adfs.neumanndaniel.local/FederationMetadata/2007-06/FederationMetadata.xml’ -ConnectionString “Data Source=srv-5.neumanndaniel.local;Initial Catalog=Microsoft.MgmtSvc.PortalConfigStore;User ID=sa;Password=**********”
Danach kann man den Zugriff testen. Die URLs sollten allerdings in der Internet Explorer Zone Lokales Intranet gelistet sein, da man ansonsten erst einmal wieder nach Benutzername und Passwort gefragt wird.
Hier als Beispiel der Aufruf der beiden Portale per Firefox, so dass man sehr schön die Weiterleitung zum ADFS Server für die Authentifizierung sehen kann.
Damit ist die Konfiguration des AD Single Sign On für das Windows Azure Pack Admin & Tenant Portal abgeschlossen.
Der Vollständigkeit halber möchte ich auf die Original Blogartikel hinweisen, die als Grundlage für diesen Blogartikel dienten.
-> http://blogs.technet.com/b/privatecloud/archive/2013/12/10/windows-azure-pack-reconfigure-portal-names-ports-and-use-trusted-certificates.aspx
-> http://blogs.technet.com/b/privatecloud/archive/2013/12/02/federated-identities-to-windows-azure-pack-through-ad-fs-part-1-of-3.aspx
-> http://blogs.technet.com/b/privatecloud/archive/2013/12/17/federated-identities-to-windows-azure-pack-through-ad-fs-part-2-of-3.aspx
-> http://blogs.technet.com/b/privatecloud/archive/2013/12/18/federated-identities-to-windows-azure-pack-through-ad-fs-part-3-of-3.aspx