Multi-Cloud ADConnect

Dieser Artikel erschien zuerst auf Ralfs Blog.

Hat mich einfach mal interessiert, wie man eine on-premise Domäne in mehrere Clouds verbinden kann, insbesondere sowohl in die globale Azure Cloud, als auch gleichzeitig in die Microsoft Cloud Deutschland. Also hab ich’s probiert, und hier das Ergebnis …

Wozu das Ganze?

Vorneweg vielleicht erst mal, warum man sowas tun will … Die Microsoft Cloud Deutschland kommt mit einem separierten Azure Active Directory, das bedeutet, dass Benutzer, die im AAD der globalen Azure Cloud angelegt sind (wie auch immer, also direkt oder synchronisiert), nicht im AAD der Microsoft Cloud Deutschland bekannt sind, und umgekehrt, und von daher eine Authentifizierung dieser (globalen) Benutzer an Azure Deutschland nicht möglich ist (und auch hier gilt umgekehrt das Gleiche). Daher stellt sich für viele die Frage, ob man nicht die lokalen Benutzer einfach in beide Clouds synchronisieren kann, und genau das war der Ausgangspunkt für diese Versuche.

Logische Sicht

Gleich mal eine Klarstellung, was nicht geht, nämlich gleicher Benutzername in Azure global und Azure Deutschland. Warum? Nun, Benutzernamen im AAD setzen sich immer aus dem Benutzer und dem Domänennamen zusammen, und der Domänenname muss unterschiedlich sein. Das fängt bei den “onmicrosoft“-Namen an: Die entsprechende Domäne für Azure Deutschland ist “onmicrosoft.de” und nicht “onmicrosoft.com” wie global. Damit kann ein Benutzer “ralf@demobag.onmicrosoft.com” schon mal nicht im AAD von Azure Deutschland sein.

Bei selbst hinzugefügten Domänen gilt, dass die Domäne nur zu einem Tenant hinzugefügt werden kann. Soll heißen, dass ich mich als “ralf@demobag.de” zum Beispiel am “deutschen” AAD anmelden kann, wenn ich zuvor mit meiner Subscription in Azure Deutschland diese Domäne hinzugefügt habe. Die gleiche Domäne kann dann aber nicht mehr meiner Subscription im globalen Azure hinzugefügt werden. Alles klar?

Technische Sicht

Von der Technik her betrachtet kann man natürlich auf mehreren Servern in einer lokalen Domäne das Synchronisierungstool “ADConnect” laufen lassen. Und man kann filtern, welche Accounts synchronisiert werden sollen, zum Beispiel auf Basis von Organizational Units, OUs. Das Problem ist nur, dass sich eben der Login-Name ändern würde, da die Zielpunkte in den AADs sich ja namentlich unterscheiden, mindestens im Domänennamen. Jetzt könnte man natürlich sich was mit Umbenennungen oder Alternativnamen ausdenken, aber ich habe mal einen anderen Weg ausprobiert, nämlich die Verwendung unterschiedlicher UPN-Suffixe in der lokalen Domäne.

UPN-Suffixe? Was ist das nochmal gleich? Ganz einfach. Standardmäßig lautet der UserPrincipalName eines AD-Domänenbenutzers so wie der DNS-Name der Domäne. Heißt die AD-Domäne also “DEMOBAG” und ist der DNS-Name “demobag.de“, dann heißt der Login-Name des Benutzer “DEMOBAG\ralf” oder als UPN eben “ralf@demobag.de“. Im lokalen AD kann man aber weitere UPN-Suffixe, also die Teile hinter dem “@”-Zeichen) definieren und damit die Benutzer innerhalb der Domäne mit verschiedenen Logins versorgen. Zum Beispiel wäre es machbar, einen Teil der Benutzer mit dem Login “@germany.demobag.de” zu versorgen, und einen anderen Teil mit “@global.demobag.de“, obwohl alle Benutzer in der gleichen “DEMOBAG“-Domäne sind. Und genau das hab ich gemacht. Zur besseren Übersicht hier mal ein erstes Bild…

Setup der on-premise Domäne

Wie man erkennen kann habe ich die Benutzer in der “OU=germany” mit dem UPN-Suffix “@germany.demobag.de” versehen, und entsprechend die Benutzer in der “OU=global” mit “@global.demobag.de“. Die Zuordnung der UPN-Suffixe erfolgt pro Benutzer und ist eigentlich von der OU völlig unabhängig, aber für den Filter von ADConnect war das einfacher und übersichtlicher.

Was bringt mir das?

Durch den UPN-Suffix haben wir etwas, das wie eine Subdomäne aussieht (aber eigentlich keine ist). Und durch diesen Trick können wir die beiden “Subdomänen” germany.demobag.de und global.demobag.de unterschiedlichen Azure Tenants hinzufügen, nämlich die germany.demobag.de der Subscription in Azure Deutschland, und global.demobag.de der Subscription in global Azure. Und setzt man dann noch eine Synchronisation zwischen lokalem AD und AAD auf (bzw. zwei Synchronisationen, pro Cloud eine), und schon können sich die Benutzer unserer lokalen Domäne mit dem Loginnamen “foo@germany.demobag.de” mit dem gleichen Benutzernamen (und Passwort falls gewünscht) an Azure Deutschland anmelden, und die Benutzer unserer lokalen Domäne mit dem Loginnamen “bar@global.demobag.de” ebenfalls mit dem gleichen Benutzernamen an Azure global anmelden. Als Einschränkung gilt aber nach wie vor, dass das dann nicht “über Kreuz” geht, also ein Login für “foo@germany.demobag.de” an Azure global ist nicht möglich und auch kein Login für “bar@global.demobag.de” an Azure Deutschland.

Durchführung

So, jetzt noch zu den Details und wie man das aufsetzt. Ich mache das hier beispielhaft für die Domäne demobag.de, die mir gehört und die ich selbst verwalten kann (das ist wichtig, weil wir nachher DNS-Einträge vornehmen müssen).

Schritt 1: Die Subscriptions

Zuerst braucht man 2 Subscriptions, eine in Azure und eine in Azure Deutschland. Im Beispiel habe ich den Tenant “demobag.onmicrosoft.com” angelegt über die Seite https://account.windowsazure.com/organization, und den Tenant “demobag.onmicrosoft.de” über die Seite https://account.windowsazure.de/organization (die beiden Links unterscheiden sich nur durch die Endung .com vs. .de!), jeweils mit dem Benutzer “admin“.

Schritt 2: Die DNS-Geschichte

Für unsere DNS-Verwaltung brauchen wir die beiden DNS-Subdomänen “germany” und “global“, die uns der DNS-Amin anlegt (das überspringe ich hier mal, da gibt es so viele unterschiedliche Tools dafür, da hab ich keine Ahnung, was andere so verwenden). Nochmal zur Klarstellung: Wir legen nur eine DNS-Subdomäne an, keine AD-Domäne, da verwenden wir nur die “DEMOBAG” bzw. “demobag.de“.

Schritt 3: DNS-Domänen zu AAD hinzufügen

Das habe ich schon mal in einem anderen Blogbeitrag zu ADConnect beschrieben, wie das geht. Prinzipiell loggen wir uns in Azure ein, fügen die Domäne hinzu, und Azure gibt uns einen Testeintrag vor, den wir in unseren Nameserver eintragen müssen. Das ist quasi der “Beweis”, dass wir die DNS-Domäne administrieren, sie also uns “gehört”. Für unser Szenario hier machen wir das einmal mit unserer Subscription in Azure global, d. h. wir melden uns an mit unserem Admin-User auf demobag.onmicrosoft.com und fügen die DNS-Domäne “global.demobag.de” hinzu, und dann melden wir uns an Azure Deutschland an mit “admin@demobag.onmicrosoft.de” und fügen die DNS-Domäne “germany.demobag.de” hinzu. Die Verifizierungs-Einträge im eigenen Nameserver vornehmen, Azure jeweils überprüfen lassen, und wir sind bereit für ADConnect…

Schritt 4: ADConnect

Das Setup für ADConnect habe ich schon in diesem Artikel beschrieben, das spare ich mir hier jetzt. Wichtig ist, dass wir zwei Server verwenden: Einen, um ein ADConnect zum globalen AAD herzustellen, und einen zweiten, um zum AAD in Azure Deutschland zu synchronisieren. ADConnect erkennt am Tenant-Namen, in welche Azure-Umgebung synchronisiert werden soll, wir können also das gleiche ADConnect Installationspaket verwenden. Wir filtern beim Setup einfach auf OU-Ebene wie oben beschrieben, einmal für “OU=global” und einmal für “OU=germany“.

Schritt 5: Testen

Nach erfolgter Synchronisation können sich nun alle Benutzer der OU “germany“, die ein UPN-Suffix “germany.demobag.de” haben, zum Beispiel am deutschen Azure Management Portal anmelden mit ihrem gewohnten (vollständigen) Benutzernamen, also zum Beispiel “foo@germany.demobag.de“. Gleiches gilt für die Benutzer der OU “global” mit dem UPN-Suffix “global.demobag.de“. Die können sich am globalen Azure Management Portal mit ihrem gewohnten Benutzernamen “bar@global.demobag.de” anmelden. Bitte beachten, dass es sich um unterschiedliche Portale handelt!

Schritt 6: Dokumentation

Macht ja sowieso keiner, steht nur der Vollständigkeit halber hier :-). Und ein Übersichtsbild, das hoffentlich mehr sagt als tausend Worte…

Zusammenfassung

Mit Hilfe der unterschiedlichen UPN-Suffixe ist es möglich, Sub-Domänen zu simulieren und damit eine einzelne on-premise AD Domäne in zwei verschiedene Azure ADs zu synchronisieren mittels zweier Instanzen von ADConnect. Eine Trennung der Benutzer erfolgt durch Filterregeln innerhalb von ADConnect auf Basis unterschiedlicher Eigenschaften, im Beispiel wurde einfach auf OU-Ebene unterschieden.

Wer das mal testen will, der kann das übrigens auch ganz gut komplett in Azure erledigen (egal in welchem :-)). Ein Domaincontroller, zwei Memberserver als VM, und das war’s. So hab ich’s gemacht…