Azure Active Directory Connect: Custom Installation

In diesem Artikel möchte ich euch nun endlich die Möglichkeiten, die Azure Active Directory Connect in der Custom Installation Variante mitbringt, näherbringen. Die Installation mittels der Express Variante habe ich ja bereits im Artikel http://www.faq-o-matic.net/2015/08/10/azure-active-directory-connect-komponenten-und-express-installation/ beleuchtet. Wie bisher ist der notwendige Installer im Microsoft Download Center (http://www.microsoft.com/en-us/download/details.aspx?id=47594) zu beziehen. Zum Zeitpunkt der Installation handelt es sich hierbei um die Version 1.0.8667.

Nach dem erfolgreichen Download der Installationsdatei wird die Einrichtung von Azure Active Directory Connect mit dem Aufruf der AzureADConnect.msi gestartet.

Direkt nach dem Aufruf erfolgt bereits die Installation der notwendigen Dateien auf dem System. Hierbei werden die notwendigen Komponenten zur eigentlichen Installation in das Verzeichnis „C:\Program Files\Microsoft Azure Active Directory Connect“ abgelegt und eine Desktop Verknüpfung für den Wizard des Microsoft Azure Active Directory Connect erstellt.

Nach dem erfolgreichen Kopieren der Dateien startet der Wizard zur eigentlichen Installation von AAD Connect. Als erstes müssen auf der Willkommensseite die Lizenzbedingungen bestätigt werden, bevor es mit der Installation weitergehen kann.

Nach dem Bestätigen der Bedingungen und Fortsetzen des Wizards kommen wir zu der entscheidenden Gabelung bei der Installation. Hier kann entweder die Installation mit den Express-Einstellungen fortgeführt werden, welche ich in dem bereits oben genannten Artikel beschrieben habe, oder wir führen die Custom Installation durch. Da dieses in diesem Fall gewünscht ist, wählen wir „Customize“ aus.

Durch diese Auswahl erhalten wir als erstes einige Möglichkeiten, welche die reine Installation des Azure Active Directory Connects betreffen. So können durch das Aktivieren der jeweiligen Checkbox die Einstellungen der folgenden Installationseinstellungen von der Default-Installation abweichen.

· Installationspfad

· SQL-Server (Möglichkeit zur Angabe eines bestehenden SQL-Servers)

· Service-Account (Möglichkeit zur Angabe eines bestehenden Service-Accounts)

· Namen für die lokalen AAD Connect spezifischen Sicherheitsgruppen

Nach Bestätigung der Wizards mit Install werden die notwendigen Komponenten auf dem Server installiert. Da keine abweichenden Konfigurationseinstellungen getroffen wurden, sind die folgenden Defaultwerte gültig.

· Installationsverzeichnis: C:\Program Files\Microsoft Azure AD Sync

· SQL-Server: Microsoft SQL Server 2012 Express

· Lokaler Service Account AAD_<ID>

· Sync groups:

o ADSyncAdmins

o ADSyncBrowse

o ADSyncOperators

o ADSyncPasswordSet

Sobald die Installation gestartet wurde, werden durch den Wizard die weiteren Voraussetzungen für die Verwendung Azure Active Directory Connect installiert.

Nach erfolgter Installation der Voraussetzungen erscheinen innerhalb des Wizards weitere Seiten mit Optionen, die während der Installation einer Konfiguration bedürfen. So muss als erstes die Entscheidung getroffen werden, um welche Art von Identity es sich später handeln soll. So kann zwischen der Synchronized Identity (Passwort Synchronization) oder der Federated Identity (Federation with AD FS) ausgewählt werden. Alternativ kann ebenfalls dieser Punkt erstmals nicht konfiguriert werden, wodurch nur die Synchronisation der Userkonten erreicht wird.

In unserem Fall wird die Option „Federation with AD FS“ ausgewählt, worauf der Wizard direkt mitteilt, dass die Installation der notwendigen Rollen Active Directory Federation Services und Web Application Proxy automatisiert durchgeführt werden. Als Voraussetzung hierfür müssen Windows Server 2012 R2 Systeme bereitgestellt werden, auf denen die jeweiligen Funktionen bereitgestellt werden sollen. Zusätzlich wird noch auf die Notwendigkeit eines Zertifikats für die Veröffentlichung der Federation Services hingewiesen. Die einzelnen Punkte werden im Späteren genauer beleuchtet.

Nachdem die Auswahl erfolgt ist, muss ein Account zur Verbindungsherstellung zwischen dem Azure Active Directory Connects und dem Azure Active Directory angegeben werden. Wichtig hierbei ist, dass es sich um ein Konto mit globalen Administrator Rechten im Azure Active Directory handelt und nicht über einen Anmeldenamen verfügt, der die Domäne, die später für die Kopplung der Federation Services genutzt wird, beinhaltet. So fällt in meinem Fall die Wahl auf einen Account mit dem UPN-Suffix @mforchlive.onmicrosoft.com und nicht @learnazuread.com, da im späteren Verlauf die Domäne learnazuread.com für die Federation Services mit SSO verwendet wird.

Als nächstes müssen die zu synchronisierenden Active Directory Forests angegeben werden. Die notwendigen Berechtigungen des zu verwendenden Benutzerkontos hängen hierbei stark von dem geplanten Szenario und den jeweils verwendeten optionalen Features ab. So ist für den Wizard erstmals ein Konto mit Leseberechtigungen im Active Directory ausreichend, allerdings ist hierbei relativ schnell Schluss mit den möglichen Einsatzszenarien. Eine Übersicht der benötigten Berechtigungen ist in der nachfolgenden Tabelle (Quelle: Microsoft – https://azure.microsoft.com/de-de/documentation/articles/active-directory-aadconnect-account-summary/) ersichtlich.

In meinem Fall erstelle ich hierfür einen neuen Service-Account, der über Domänen-Administrator-Berechtigungen verfügt. Sinnvollerweise sollte das Konto so konfiguriert sein, dass es über ein nicht ablaufendes Passwort verfügt und das Passwort durch einen organisatorischen Prozess regelmäßig geändert wird. Bei jeder Änderung ist das Kennwort ebenfalls in der AAD Connect Konfiguration anzupassen.

Nach Auswahl des Forest und der Angabe des Benutzernamens und des Passworts lässt sich der Forest zum Azure Active Directory Connect hinzufügen. So können alle notwendigen Active Directory Gesamtstrukturen dem Azure Active Directory Connect bekannt gemacht werden.

Auf der nächsten Seite des Wizards kommen wir nun zu einer sehr entscheidenden Frage, nämlich wie die User im Azure Active Directory identifiziert werden und welches Attribute für die Anmeldung im Azure Active Directory verwendet werden soll. Die Defaultwerte sind in dem nachfolgenden Screenshot dargestellt. Sofern die Benutzer nur in einem Verzeichnis vorhanden sind, kann die erste Auswahl schon mal bestehen bleiben, ansonsten ist hier zu definieren, anhand welchem Attribut ein sinnvolles Mapping der identischen Benutzer erfolgen kann. Im nächsten Teil der Konfiguration ist ersichtlich, dass der Source Anchor auf das Attribut „objectGUID“ und der User Principal Name auf das Attribut „userPrincipalName“ festgelegt ist.

Beim Source Anchor handelt es sich um die eindeutige Zuordnung eines Active Directory Kontos zu einem Azure Active Directory Kontos. Die Defaultauswahl „objectGUID“ ist eine sinnvolle Wahl, da dieser Wert innerhalb eines Active Directory Forests einmalig ist und auch beim Verschieben eines Anwenders in eine andere Domäne bestehen bleibt. Sollte jedoch eine Active Directory Migration geplant sein, so kann ist es sinnvoll auf ein anderes Attribut auszuweichen, welches bei der Migration mit übernommen wird. Einen sehr guten Artikel mit tiefgreifenden Informationen zu diesem Thema ist unter dem folgenden Link http://blogs.perficient.com/microsoft/2015/04/office-365-why-you-need-to-understand-immutableid/ zu finden. Die per Default definierte Verwendung des Active Directory UserPrincipalNames als Anmeldenamen im Azure Active Directory ist grundsätzlich sinnvoll, allerdings sind hier zwei Fakten zu betrachten. Einerseits ist der UPN nicht immer für den Anwender schlüssig und zweitens besteht eine technische Einschränkung von Seiten Microsofts. Es ist nämlich zwingend notwendig, dass der UPN „routebar“ sein muss. Dieses bedeutet, dass die Endung des UPN-Suffixes nicht auf einen nicht offiziell verwendbaren DNS-Namen enden darf und ebenfalls der DNS-Name dem eigenen Unternehmen zugewiesen ist. Somit können Userkonten aus Domänen, die auf einen UPN-Suffix, der zum Bespiel auf .local oder .ads endet, nicht innerhalb des Azure Active Directory verwenden werden.

Um diese Problematik zu lösen gibt es zwei Möglichkeiten. Erstens besteht die Möglichkeit den UPN-Suffix auf allen Active Directory Konten, die synchronisiert werden sollen, auf den offiziellen externen DNS-Namen zu ändern. Hierzu kann man ohne viel Aufwand den externen DNS-Namen als zusätzliches UPN-Suffix der Domäne hinzufügen. Dieses ist innerhalb von wenigen Sekunden über die Konsole „Active Directory Domains and Trusts“ erledigt.

Allerdings ist in diesem Fall darauf zu achten, dass alle zu synchronisierenden Domänenkonten über das korrekte UPN-Suffix verfügen. Dieses kann pro Konto im Active Directory konfiguriert werden.

Der zweite Lösungsansatz, die Alternate LoginID, ist noch nicht allzu lange möglich und ermöglicht die Nutzung eines anderen Attributes zur Verwendung als Anmeldenamens im Azure Active Directory. Hierbei wird grundsätzlich die Nutzung des Mail-Attributes empfohlen. Dieses ist auch für die Benutzerakzeptanz sinnvoll, da die meisten Anwender durchaus in der Lage sind sich ihre E-Mail-Adresse zu merken J. Um dieses zu ermöglichen wird im Wizard einfach unter User Principal Name das Attribute mail ausgewählt.

Als nächstes kann ausgewählt werden, ob alle Benutzer- und Computerkonten ins Azure Active Directory synchronisiert werden sollen oder nur die Mitglieder einer bestimmten Active Directory Gruppe. Dieses lässt sich, wie eigentlich alle Konfigurationen, auch später wieder ändern. Ich wähle hierfür die Gruppe AAD-Sync aus, die ich zuvor in der Domäne angelegt habe.

Nun kommt die Abfrage welche optionalen Features ebenfalls aktiviert werden sollen. Hierbei ist die Auswahl natürlich von den organisatorischen Anforderungen abhängig. So kann zum Beispiel auch bei der Verwendung der Federated Identity, wie in unserem Fall, die Synchronisation der Passwort Hashes durchgeführt werden. Auch die Möglichkeit zum Zurückschreiben des Passwortes vom Azure AD in Richtung AD lässt sich hier aktivieren. Hierdurch besteht die Möglichkeit zur Einführung eines Passwort Self Services Resets für Anwender ohne die Einführung einer OnPremise Microsoft Identity Manager Infrastruktur. Ebenfalls können hier einige zukünftige Features, die sich noch in der Preview Phase befinden, aktiviert werden.

In diesem Fall aktiviere ich einfach mal ein paar Features und wir sehen, dass sich der Wizard entsprechend verändert.

In dem nächsten Wizardfenster ist nun die Auswahl zu treffen, in welche OU die Gruppen erstellt werden sollen, die mit Hilfe der Writeback Funktion den Weg aus dem Azure Active Directory ins lokale AD finden.

Die nächste Auswahl bezieht sich auf die notwendigen Attribute, die für die Nutzung der entsprechenden Azure Anwendungen vom lokalen Active Directory ins AAD synchronisiert werden. Hierzu können die geplanten Anwendungen ausgewählt werden, womit sichergestellt wird, dass die notwendigen Attribute für einen reibungslosen Betrieb auch im Azure Active Directory vorhanden sind. Eine Übersicht der notwendigen Attribute ist unter folgendem Link (https://msdn.microsoft.com/en-us/library/azure/dn764938.aspx) zu finden.

In dem nächsten Fenster werden die Attribute nochmals einzeln angezeigt, die Anhand der vorher getroffenen Auswahl der Anwendungen, ins Azure Active Directory synchronisiert werden würden. Hierbei besteht allerdings noch die Möglichkeit bestimmte Attribute durch das Aktivieren der Checkbox „I want to further limit …“ abzuwählen. Allerdings ist dabei darauf zu achten, das unter Umständen bestimmte Funktionen innerhalb der Anwendungen nicht mehr wie erwartet funktionieren, da bestimmte Informationen in den Attributen erwartet werden.

Als nächstes hat man die Möglichkeit, die für die „Federated Identity“ notwendige ADFS Farm einzurichten. Hierbei liefert der Wizard die Option entweder eine bestehende ADFS Farm zu nutzen oder eine neue ADFS Farm auf Basis von Windows Server 2012 R2 einzurichten. Hierfür ist als erstes das Zertifikat für die Nutzung der ADFS Dienste auszuwählen. Sobald das Zertifikat ausgewählt wurde, ist der Subject Name der ADFS Farm auszuwählen, in diesem Fall sts.learnazuread.com.

Im nächsten Schritt sind die zukünftigen ADFS-Farm-Member hinzuzufügen. Damit das Hinzufügen auch funktioniert ist sicherzustellen, dass die Systeme bereits Mitglied der Domäne sind und auch netzwerktechnisch zu erreichen sind.

Um die ADFS-Funktion hochverfügbar zur Verfügung zu stellen, ist natürlich ein zweiter Server hinzuzufügen. Der vorher im Wizard ausgewählte Subject Name für die Farm, in meinem Fall sts.learnazuread.com sollte in diesem Fall natürlich über einen Loadbalancer entsprechend zur Verfügung gestellt werden.

Nach dem Hinzufügen der ADFS Server steht als nächstes das Hinzufügen des späteren Web Application Proxy Server auf dem Programm. Hierzu wird in dem Wizard der spätere Web Application Proxy Server eingetragen. Da dieser Server sinnvollerweise in einer DMZ steht, da er die Anfragen aus dem Internet annimmt und mittels der ADFS-Proxy-Funktion an die internen ADFS-Server weiterleitet, sollte das Systeme nicht Mitglied der Domäne sein. Daher wird beim Hinzufügen des Systems nach entsprechenden lokalen Credentials gefragt. Auch hier besteht natürlich die Möglichkeit gleich mehrere WAP hinzuzufügen, welches in einem produktiven Einsatzszenario auch sinnvollerweise erfolgen sollte. In diesem Fall wäre auch der Einsatz eines Loadbalancers sinnvoll.

So nun habe ich die Credentials eingegeben und sichergestellt, dass die Netzwerkkonnektivität zwischen den Systemen gegeben ist und ich erhalte wie im Screenshot ersichtlich trotzdem eine Fehlermeldung. Was ist los?

Auch wenn der Wizard einiges an Arbeit abnimmt, so muss in der Konfiguration doch noch einiges „zu Fuß“ duchgeführt werden. So dann fangen wir mal an….

Als erstes ist sicherzustellen, dass die Namensauflösung des DNS-Namens für den angegebenen ADFS Subject Names auf die interne ADFS-Farm verweist. Dieses kann entweder über Anpassungen an den DNS-Servern in der DMZ oder einfach über Anpassen der HOST-Datei erfolgen. Ich für meinen Fall habe mich für den zweiten Weg entschieden und den DNS-Namen sts.learnazuread.com und die zugehörige IP-Adresse in der HOST-Datei gepflegt.

Ein weiterer notwendiger Schritt ist das Hinzufügen des Web Application Servers als TrustedHost mit dem Befehl Set-Item WSMan:\localhost\Client\TrustedHosts –Value <DMZServerFQDN> -Force –Concatenate, dieses ist notwendig da der Web Application Proxy sich nicht in einer Domäne befindet.

Zusätzlich ist sinnvoll der Web Application Proxy Server im Server Manager des Azure Active Directory Connect Servers als zusätzlichen verwalteten Server hinzuzufügen. Dieses erfolgt über Manage à Add Servers à DNS und der Angabe des Servernamens als FQDN. Dieses setzt voraus, dass auch der Web Application Proxy im interne DNS gepflegt wurde. Sollte dieses bisher noch nicht erfolgt sein, so ist auch für den Client ein entsprechender HOST Record einzutragen.

Nachdem der Server hinzugefügt wurde, ist der Server unter All Server auszuwählen und dort sind die richtigen Credentials unter Manage As … einzutragen. Dieses sind in diesem Fall die lokalen Administrator Credentials. Diese zusätzlichen Schritte sind ebenfalls in dem folgenden Microsoft Artikel https://msdn.microsoft.com/en-us/library/azure/dn832696.aspx beschrieben.

Nachdem diese Vorarbeiten nun durchgeführt wurden, lässt sich der Web Application Procy auch ohne Fehlermeldung dem Wizard hinzufügen.

Der nächste Schritt erfordert die Angabe eines Kontos, welches für die Anfrage vom Web Application Proxy in Richtung ADFS-Server genutzt wird, um ein notwendiges Proxy Trust Zertifikat zu beziehen. Für diesen einmaligen Schritt wähle ich meinen Domänen-Admin aus.

Als nächstes ist ein Account für die ADFS-Farm auszuwählen. Hier bieten sich zwei Optionen an, als erstes ist die Verwendung eines Group Managed Service Accounts (gMSA) möglich, welcher durch den Wizard erstellt wird. Alternativ kann auch ein normaler Domänen-Account verwendet werden. Allerdings ist die Verwendung eines gMSA wesentlich sinnvoller, da hierbei die Verwaltung des Kontos inklusive einer regelmäßigen Kennwortänderung durch die Domänen Controller übernommen wird.

Als nächstes ist noch die Auswahl zu treffen, welche der hinterlegten Domänen im Azure AD als Federated Domain mit dem lokalen AD verwendet werden soll. Der Wizard weist darauf hin, dass die ausgewählte Domäne derzeit eine „managed domain“ ist und in eine „federated domain“ umgewandelt wird und dieses zu Unterbrechungen bei der Verfügbarkeit der Anmeldedienste bei Azure Diensten führen kann.

Als nächstes sehen wir noch die gesamte Übersicht der getroffenen Einstellungen und können die eigentliche Installation mit „Install“ beginnen.

Nun ist der Zeitpunkt gekommen, in der man entspannt eine Tasse Tee oder Kaffee trinken und dem Wizard in Ruhe weiter zuschauen kann.

Nachdem die Installation von allen Komponenten erfolgreich durchgeführt wurde, steht noch die Überprüfung der Federation Services aus. Dafür muss sichergestellt sein, dass sowohl von intern als auch extern die Namensauflösung auf den gewählten DNS-Namen, in diesem Fall sts.learnazuread.com, einwandfrei funktioniert. Dieses kann mit „Verify“ entsprechend geprüft werden. Sollten die notwendigen DNS-Einträge noch nicht erstellt worden sein, so kann der Wizard bereits mit „Exit“ verlassen werden und die Prüfung kann später manuell erfolgen.

Sofern man sich doch fürs „Verify“ entschieden hat, erhält man in er nachfolgenden Übersicht sowohl die internen als auch externen IPs für den gewählten Federation Services DNS-Namen.

Mit dieser Seite endet der Wizard und die Installation von Azure Active Directory Connect ist abgeschlossen. Nun ist die Überprüfung der Funktion angesagt. Hierzu prüfe ich als erstes die Übertragung der Benutzerkonten und Gruppen ins Azure Active Directory. Dafür melde ich mich wie gewohnt an der Website https://manage.windowsazure.com an und wähle mein Standardverzeichnis aus. Nun sollte ich in der Übersicht die lokalen Benutzer meines onPremise ADs sehen. Sollte dieses nicht der Fall sein, so kann dieses an mehreren Gründen liegen. Einer wäre, dass die Synchronisation noch im Gange ist und dieses je nach Größe der Umgebung etwas Zeit in Anspruch nimmt. Nachdem ich dieses ausschließen kann, geht es ans Troubleshooten. In diesem Fall ist als erstes das Eventlog auf dem AAD Connect Server zu prüfen.

Sofern im Eventlog Meldungen, wie die folgenden auftauchen, scheint etwas mit dem verwendeten Account für die Synchronisation nicht zu stimmen.

Beim Aufruf des Synchronization Service Managers (C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe) konnte ich feststellen, dass die Synchronisation in Richtung Azure AD jeweils mit dem Fehler stopped-extension-dll-exception abgebrochen wurde.

Dieser Fehrler ist sehr gut in dem folgenden Artikel (http://blog.kloud.com.au/2015/07/21/azure-ad-connect-connect-service-error-stopped-extension-dll-exception/) beschrieben. Wie bereits vermutet, handelt es sich um ein Problem mit dem verwendeten Synchronisationskonto. Um dieses Problem zu lösen habe ich mich, wie in dem Artikel erleutert, ebenfalls für die Anpassung des verwendeten Synchronisationskontos entschieden. Hierfür habe ich als erstes im Azure Active Directory ein neues Konto mit globalen Administrator Rechten angelegt. Ebenfalls ist es sinnvoll das Konto so zu konfigurieren, dass das Kennwort nicht abläuft. Dieses ist unter dem folgenden Link (https://support.office.com/en-us/article/Set-an-individual-user-s-password-to-never-expire-f493e3af-e1d8-4668-9211-230c245a0466) beschrieben.

Als nächstes habe ich dieses Konto für die Synchronisation ausgewählt. Hierzu muss unter den Connector-Eigenschaften in dem Synchronization Service Manager das neu angelegte Konto hinterlegt werden.

Nach den Anpassungen habe ich den initialen Sync mittels der PowerShell und dem Aufruf des DirectorySyncClientCmd.exe mit dem Parameter initial aus dem Verzeichnis C:\Program Files\Microsoft Azure AD Sync\Bin gestartet.

Nun lief auch die Synchronisation in Richtung Azure AD ohne Fehlermeldungen durch und die entsprechenden Konten wurden erfolgreich ins Azure AD synchronisiert.

Da die Synchronisation der Benutzerkonten nun funktioniert hat, möchte ich nun als nächsten Schritt die eigentliche Anmeldung an den Active Directory Federation Services testen. Hierzu rufe ich mit einem Browser die URL https://sts.learnazuread.com/adfs/ls/idpinitiatedsignon.aspx auf.

Nach dem Klick auf „Anmelden“ erhalte ich die Möglichkeit mich an dem ADFS anzumelden. Da ich mich während der Installation dafür entschieden habe als Anmeldenamen das E-Mail-Attribute zu verwenden, melde ich mich auch nun mit der hinterlegten E-Mail-Adresse des Anwenders an.

Leider erscheint als nächstes eine Fehlermeldung, die mir mitteilt, dass entweder das Benutzer-ID oder das Kennwort falsch ist. Da ich mir sicher bin, dass ich das richtige Kennwort eingegeben habe, heißt es nun wieder Troubleshooten.

Hierfür wähle ich als Mittel die PowerShell auf dem ADFS Server und schaue mir mit Hilfe des Befehls Get-AdfsClaimProviderTrust mal die notwendigen Attribute AlternateLoginID und LookupForests an. Wie in dem Screenshot ersichtlich, sind beide Attribute nicht mit den notwendigen Informationen gefüllt, die für eine erfolgreiche Anmeldung mittels der gewählten AlternateLoginID notwendig wären.

Also setzen wir mit dem Befehl Set-AdfsClaimProviderTrust die notwendigen Attribute. Hierfür werden die Parameter AlternateLoginID <gewünschtes Attribut>, LookupForests <FQDN der Domäne> und TargetIdentifier „AD AUTHORITY“ benötigt.

In meinem Fall also…

Nach dem Eintragen der notwendigen Attribute, teste ich erneut die Anmeldung mittels der E-Mail-Adresse des Anwenders.

Und diesmal mit Erfolg…

Als nächsten und letzten Testschritt teste ich die Anmeldung mit dem Account an einem Azure Services. Ich habe mich für die Verwendung des Azure Active Directory Anwendungsportals https://myapps.microsoft.com entschieden. Mithilfe dieses Portals erhalten Anwender die Möglichkeit auf zugewiesene SaaS-Apps oder veröffentliche OnPremise-Anwendungen über einem zentralen Einstiegspunkt zuzugreifen. Nach dem Aufrufen der Seite wird man aufgefordert, die E-Mail-Adresse des Accounts einzugeben.

Nach Eingabe der E-Mail-Adresse erfolgt nun die Umleitung von der Microsoft Website auf die OnPremise gehostete ADFS-Farm beziehungsweise auf den veröffentlichten ADFS-Proxy (Web Application Proxy) in der DMZ. An diesem Server erfolgt nun die Eingabe der gültigen Anmeldeinformationen. Nach dem Bestätigen des Ganzen mit „Anmelden“…

…. Geht es weiter und wir sind erfolgreich im Zugriffspanel angemeldet und können nun von dort aus unsere gewünschte Anwendung starten.

Somit konnten alle Funktionen zur Anmeldung erfolgreich getestet werden. Und den Anwendern steht nun der Zugriff auf Microsoft Cloud Services wie Office 365 oder Azure mittels der bekannten E-Mail-Adresse und dem Active Directory Kennwort zur Verfügung.

Fazit

Azure Active Directory Connect bietet in der Customize Variante eine Vielzahl an Möglichkeiten. So können im Gegensatz zu der Express Variante einige grundlegenden Einstellungen, wie die Auswahl eines bestehenden SQL-Servers oder der Installationspfad, angepasst werden.

Davon abgesehen bringt diese Variante des Azure Active Directory Connect alle Möglichkeiten mit, um die Synchronisation des lokalen Active Directory in Richtung Azure AD an die organisatorischen Gegebenheiten anzupassen. So ist zum Beispiel die Festlegung der zu übertragenen Attribute ins Azure Active Directory ohne viel Aufwand anpassbar.

Allerdings sind einige Automatismen, von denen ich erwartet hätte, dass sie die Konfiguration vollumfänglich übernehmen, noch nicht zu 100% ausgereift. Wenn man die Hinweise in dem Artikel berücksichtigt, erhält man mit dem Azure Active Directory Connect trotzdem eine gute Unterstützung, um einige bisher notwendige manuelle Installationsschritte, zum Beispiel beim Einrichtung einer ADFS-Farm in Verbindung mit Web Application Proxys, schneller durchführen zu können. Allerdings sehe ich hier noch Potential für Verbesserungen von Microsoft in der nächsten Variante des AAD Connect.