共用方式為

ADConnect und die Microsoft Cloud Deutschland

  • 發行項

Nachdem ich gelesen habe, dass die neue Version von ADConnect (ab 1.1.180.0) jetzt auch die Microsoft Cloud Deutschland unterstützt, war meine Neugier geweckt, und was soll ich sagen, es klappt. Wie? Steht hier in Kurzform...

ADConnect ist der (würdige) Nachfolger von Windows Azure Active Directory Sync (DirSync) und Azure AD Sync und da die beiden letztgenannten Tools abgekündigt wurden und der Support April 2017 ausläuft, wäre es jetzt übrigens eine gute Zeit für den Wechsel... ADConnect gibt es zum Download hier: (https://www.microsoft.com/en-us/download/details.aspx?id=47594).

Mittels ADConnect kann man eine Synchronisation zwischen seinem on-premise Active Directory und dem Azure Active Directory herstellen. Hierzu gibt es verschiedene Konfigurationsmöglichkeiten, die ich jetzt nicht alle aufzählen oder erklären möchte, sondern einfach mal auf die Artikel von Martin Forch verweise (https://www.faq-o-matic.net/2015/06/24/azure-active-directory-tools-zur-synchronisation/). Ich richte den einfachsten Fall ein, nämlich eine Synchronisation bestimmter Benutzer nach Azure, ohne Passwort.

Los geht’s

Für meinen Test habe ich mir in Azure einen Windows Server 2012 R2 installiert, den zum DC gemacht und ein paar Benutzer angelegt. Anschließend hab ich das ADConnect da drauf geladen. Wenn man – aber wer tut das schon – sich die Anleitungen vorher mal durchliest, dann trifft man auf eine Stelle, an der von verifizierten Domänen (“verified domains”) die Rede ist. Hm. Was ist das denn? Ganz einfach: Damit man im Azure AD einen Domänennamen verwenden kann für seine Benutzer, muss man erst mal beweisen, dass einem die Domäne auch gehört. Warum? Nun, es kann das Login ja nur einmal in Azure geben, und wenn jetzt irgendjemand sein lokales AD “wigand.de” genannt hat (und das kann man ja) und dann nach Azure die Benutzer synchronisiert, dann würde ich ziemlich alt aussehen, weil ich das dann nicht mehr könnte… Daher gibt es die Domänen-Verifikation, d. h. man beweist, dass man die Hoheit über den Domänennamen hat. Das geht auf mehrere Arten, die einfachste ist oft, einen TXT-Eintrag im DNS-Server zu machen, denn dann gehört mir offensichtlich die Domäne bzw. ich bin der Administrator derselben.

Das Problem, das sich hier für die Microsoft Cloud Deutschland stellt, ist, dass das gewohnte Frontend für diese Domänenverifizierung im Azure Portal für die Microsoft Cloud Deutschland noch nicht vollständig zur Verfügung steht… Aber wieder einmal rettet uns PowerShell aus diesem Dilemma mit den folgenden wenigen Schritten:

Verbinden mit MSOL

Erster Schritt ist, die Verbindung mit AzureAD herzustellen. Hierzu gibt es den Befehl Connect-MsolService. Das entsprechende PowerShell-Modul MSOnline muss eventuell noch installiert werden, bitte unbedingt eine neuere Version (mindestens 1.1.160.0-GA) installieren, die älteren Versionen unterstützen die Microsoft Cloud Deutschland noch nicht (Download Link). Nach erfolgreicher Installation (und Import-Module MSOnline) bitte beachten, dass für ein Anmelden an der Microsoft Cloud Deutschland der neue Parameter AzureEnvironment benutzt werden muss:

[code light="true"]
Connect-MsolService -AzureEnvironment AzureGermanyCloud

Jetzt können wir die ganzen Msol-Cmdlets verwenden wie Get-MsolUser, Get-MsolGroup, und zum Beispiel auch Get-MsolDomain. Wir probieren das letzte Cmdlet einfach mal aus und sehen unter anderem eine Spalte mit der Überschrift “Status”. Das erst mal nur zur Info, wir brauchen das später nochmal.

Neue Domäne hinzufügen

Als nächster Schritt kommt das Hinzufügen unserer gewünschten Domäne. Hierzu gibt es das Cmdlet New-MsolDomain mit ein paar Parametern.

  • -Authentication: Managed oder federated. Das bezieht sich darauf, wie wir mit dieser Domäne später arbeiten wollen, also ob wir eine Federation bauen möchten oder nicht. Ich hatte ja oben schon geschrieben, dass wir das erst mal langsam angehen lassen und daher machen wir keine Federation, sondern nehmen managed.
  • -Name: Der Name unserer Domäne, zum Beispiel wigand.de, oder eben auch eine Subdomäne wie ad.wigand.de
  • -VerificationMethod: Wie beweisen wir, dass wir die notwendigen Rechte an der Domäne haben? Hier wählen wir DNSRecord.

Unser Kommando sieht also so aus:

[code light="true"]
New-MsolDomain -Authentication Managed -Name ad.wigand.de -VerificationMethod DnsRecord

Wenn wir alles richtig eingegeben haben, dann sehen wir in der Ausgabe unsere neue Domäne mit dem Status “Unverified” und “Managed”.

Domäne verifizieren

Das verifizieren der Domäne geht in zwei Schritten, ok, eigentlich in drei Schritten:

Domänenverifikation starten

Azure gibt uns einen DNS-Eintrag, den wir in unserem DNS-Server eintragen müssen, und wenn wir das geschafft haben, dann glaubt uns Azure auch die Domäne. Also los. Wir können wählen zwischen einem MX- oder einem TXT-Eintrag, hier mal der TXT-Eintrag:

[code light="true"]
Get-MsolDomainVerificationDns -DomainName ad.wigand.de -Mode DnsTxtRecord

Bitte beachten: Hier heißt der Parameter jetzt -DomainName. In der Antwort sehen wir den geforderten Eintrag:

[code light="true"]
Label : ad.wigand.de
Text  : MS=ms59666891
Ttl   : 3600

DNS-Eintrag vornehmen

Da kann ich jetzt wenig helfen, wie auch immer man den Eintrag hinbekommt, sei es über die eigene Konfigurationsdatei, einem Web Frontend oder einem Serviceticket, auf jeden Fall brauchen wir in der Subdomain “ad.wigand.de” den TXT-Record mit dem Inhalt “MS=ms59666891” oder was auch immer bei ihnen da steht natürlich. Ist das geschehen, dann kann es weiter gehen. Eventuell lassen wir hier ein paar Minuten Zeit vergehen, bis alle Caches, Secondary DNS etc. sich über den neuen Eintrag einig sind… Falls Sie das selbst überprüfen möchten, dann denken Sie bitte daran, einen externen DNS-Server zu verwenden, um Seiteneffekten bei internen DNS-Servern vorzubeugen. Azure kann zur Überprüfung schließlich auch nicht auf ihren internen DNS-Server zugreifen.

Verifikation abschließen

Jetzt können wir wieder in PowerShell Azure auffordern, nach dem gewünschten TXT-Eintrag zu suchen:
[code light="true" autolinks="false"]
Confirm-MsolDomain -DomainName "ad.wigand.de"

Kommt hier eine Fehlermeldung mit der Bitte, das später nochmal zu versuchen, dann haben wir entweder den Eintrag falsch gemacht (da muss vornedran wirklich “ms=” stehen!) oder der DNS-Server hat noch eine alte Antwort geliefert und wir müssen echt noch etwas warten. Ansonsten ist unsere Domäne verifiziert, was wir auch mit dem oben schon erwähnten Cmdlet Get-MsolDomain überprüfen können (da steht dann ein “Verified” in der Status-Spalte).

ADConnect konfigurieren

Die Voraussetzungen sind geschaffen, wir können die Installation von ADConnect starten. Das steht wunderbar einfach hier (https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-get-started-express/) beschrieben. Ein paar Hinweise, wobei der Großteil einfach intuitiv eingegeben werden kann, zumindest bei der einfachen Variante ohne Passwort-Sync:

  • Bei “Connect to Azure AD” verwenden wir natürlich den gleichen Benutzernamen, mit dem wir uns oben mit Connect-MsolService angemeldet hatten.
  • Bei “Azure AD sign-in” sollten wir die Früchte unserer vorherigen Arbeit sehen können, denn dort wählen wir den UPN-Suffix aus, der für das Login verwendet werden soll, und da sollte auch unsere verifizierte Domäne auftauchen.
  • Filtern nach OU, festlegen des “Anker”-Attributs etc, das sind alles normale Einstellungen…

Fertig. Nach etwas Zeit können wir dann die on-premise AD Benutzer im AAD finden:
[code light="true"]
Get-MsolUser | where {$_.UserPrincipalName –like "*ad.wigand.de*"}

...und bitte -like verwenden und nicht -contains :-). Alle synchronisierten Einträge enthalten übrigens im Attribut “ImmutableID” die Original-GUID in Base64-Darstellung, das bietet sich zum Beispiel als Filter-Kriterium an...

Comments

  • Anonymous
    December 21, 2016
    Artikel aktualisiert. Kurzer Hinweis: Sollte nach der Eingabe der AzureAD credentials eine Box mit einer weiteren Authentifizierung hochpoppen, dann einfach schließen.