Logo faq-o-matic.net
Logo faq-o-matic.net

Azure Active Directory Connect: Custom Installation

von veröffentlicht am9. November 2015, 06:51 Uhr Kurzlink und Zitatlink einblenden
Kategorie Kategorie: Azure Active Directory   Translate with Google Translate Translate EN   Die angezeigte Seite drucken

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.

clip_image002

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.

 
  clip_image004

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.

clip_image006

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.

clip_image008

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

clip_image010

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.

clip_image012

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.

clip_image014

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.

clip_image016

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.

clip_image018

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.

Notwendige Eingabe

Notwendige Berechtigung

Verwendungszweck

Lokale Active Directory-Anmeldeinformationen für jede Gesamtstruktur, die mit Azure AD verbunden wird.

· Die vom Assistenten geforderte Mindestberechtigung ist „Domänenbenutzer“.

· Jedoch muss das angegebene Konto die erforderlichen Berechtigungen für das gewünschte Szenario aufweisen.

· Wenn Sie beabsichtigen, die Kennwortsynchronisierung zu Azure AD zu konfigurieren, stellen Sie sicher, dass dieses Konto über die folgenden Berechtigungen verfügt: – Verzeichnisänderungen replizieren – Alle Verzeichnisänderungen replizieren

· Wenn Sie beabsichtigen, die Synchronisierung so zu konfigurieren, dass Informationen von Azure AD in Ihr lokales AD „zurückgeschrieben“ werden, stellen Sie sicher, dass das Konto über Schreibberechtigungen für Verzeichnisobjekte und -Attribute verfügt, die zurückgeschrieben werden sollen.

· Wenn Sie beabsichtigen, AD FS für die Anmeldung zu konfigurieren, stellen Sie sicher, dass das Konto mit den AD-Anmeldeinformationen, die Sie für die Gesamtstruktur bereitstellen, in der sich der AD FS-Server befindet, über Domänenadministratorberechtigungen verfügt.

Dies ist das Konto, das für das lokale Konto des Active Directory Verwaltungs-Agent-Kontos (AD MA-Konto, AD Management Agent-Konto) verwendet wird. Es wird zum Lesen und Schreiben der Objekte und Attribute im lokalen AD für den fortlaufenden Synchronisierungsvorgang verwendet.

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.

clip_image020

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.

clip_image022

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.

clip_image024

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.

clip_image026

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.

clip_image027

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.

clip_image029

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.

clip_image031

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.

clip_image033

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

clip_image035

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.

clip_image037

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.

clip_image039

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.

clip_image041

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.

clip_image043

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.

clip_image045

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.

clip_image047clip_image048

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?

clip_image050

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.

clip_image052

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.

clip_image053

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.

clip_image054

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.

clip_image056

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

clip_image058

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.

clip_image060

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.

clip_image062

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.

clip_image064

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

clip_image066

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

clip_image068

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.

clip_image070

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.

clip_image072

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.

clip_image074

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.

clip_image076

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.

clip_image078

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.

clip_image080

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.

clip_image081

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

clip_image083

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.

clip_image085

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.

clip_image087

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.

clip_image089

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.

clip_image091

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…

clip_image093

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

clip_image095

Und diesmal mit Erfolg…

clip_image097

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.

clip_image099

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“…

clip_image101

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

clip_image103

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.

© 2005-2019 bei faq-o-matic.net. Alle Rechte an den Texten liegen bei deren Autorinnen und Autoren.

Jede Wiederveröffentlichung der Texte oder von Auszügen daraus - egal ob kommerziell oder nicht - bedarf der ausdrücklichen Genehmigung durch die jeweiligen Urheberinnen oder Urheber.

Das Impressum findet sich unter: http://www.faq-o-matic.net/impressum/

Danke, dass du faq-o-matic.net nutzt. Du hast ein einfaches Blog sehr glücklich gemacht!