Share via

ADConnect und die Microsoft Cloud Deutschland

  • Article

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, ich richte mal 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 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 (für die Preview-Kunden der Microsoft Cloud Deutschland gibt es dafür aktuell noch einen Ersatz). Nach dem erfolgreichen Verbinden können wir dann 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 gutter="false"]
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 gutter="false"]
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 gutter="false"]
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 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...

Verifikation abschließen

Jetzt können wir wieder in PowerShell Azure auffordern, nach dem gewünschten TXT-Eintrag zu suchen:

[code gutter="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) 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 "Aure 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 gutter="false"]
Get-MsolUser | where {$_.UserPrincipalName –like "*ad.wigand.de*"}

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