Identity Bridge Part4: AzureAD – AD Strategie und Installation

Folgende zwei Kernfragen müssen unbedingt betrachtet werden, bevor mit der Installation begonnen wird:

  1. Sollen Passwörter zur Microsoft Cloud synchronisiert werden, oder nicht?

Wenn die Synchronisation von Passwörtern zur Microsoft Cloud als unkritisch eingeschätzt wird, reicht die einfache Installation des Azure AD Connect.

Falls sie aber nicht gewünscht ist, werden zusätzlich die Active Directory Federation Services (ADFS) benötigt oder das neue Azure AD pass-through authentication. Falls diese nicht vorhanden sein sollten, kann man sie bei der Installation von Azure AD Connect mit installieren. Die Anbindung an existierende ADFS-Installationen ist natürlich möglich.

Details zur Passwortsynchronisation findet man unter https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-implement-password-synchronization

13.1.2017 Update:

Azure AD pass-through authentication

Azure AD pass-through authentication provides a simple, secure, and scalable model for validation of passwords against your on-premises Active Directory via a simple connector deployed in the on-premises environment. This connector uses only secure outbound communications, so no DMZ is required, nor are there any unauthenticated end points on the Internet.

Thats right. User passwords are validated against your on-premises Active Directory, without needing to deploy ADFS servers!

We also automatically balance the load between the set of available connectors for both high availability and redundancy without requiring additional infrastructure. We made the connector super light-weight so it can be easily incorporated into your existing infrastructure and even deployed on your Active Directory controllers.

The system works by passing the password entered on the Azure AD login page down to the on-premises connector. That connector then validates it against the on-premises domain controllers and returns the results. Weve also made sure to integrate with self-service password reset (SSPR) so that, should the user need to change their password, it can be routed back to on-premises for a complete solution. There is absolutely no caching of the password in the cloud. Find more details about this process in our documentation.

(Quelle: https://blogs.technet.microsoft.com/enterprisemobility/2016/12/07/introducing-azuread-pass-through-authentication-and-seamless-single-sign-on/)

2. Welches Attribut soll als Anmeldename genutzt werden?

Sofern die Benutzer nur in einem Verzeichnis vorhanden sind, kann die Auswahl des Installationswizards bestehen bleiben. Ansonsten ist hier zu definieren, anhand von welchem Attribut ein sinnvolles Mapping der identischen Benutzer erfolgen kann. Ein weiterer Teil der Standardkonfiguration ist der sogenannte „Source Anchor“, der mit dem Attribut „objectGUID“ vorbelegt ist, sowie der „User Principal Name“, wo das Attribut „userPrincipalName“ verwendet wird.

Beim Source Anchor handelt es sich um die eindeutige Zuordnung eines Active Directory Kontos zu einem Azure AD Konto. Dort den Standard „objectGUID“ zu wählen ist grundsätzlich 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. Ein sehr guter Artikel mit tiefergehenden Informationen zu diesem Thema ist unter dem folgenden Link zu finden: http://blogs.perficient.com/microsoft/2015/04/office-365-why-you-need-to-understand-immutableid/.

Dass für den Anmeldenamen im Azure AD standardmäßig der „userPrincipalName“ (UPN) aus dem Active Directory vorbelegt ist, ist grundsätzlich sinnvoll. Allerdings sind hier zwei Fakten zu betrachten. Einerseits ist der UPN für den Anwender nicht immer schlüssig und andererseits besteht eine technische Einschränkung von Seiten Microsofts. Es ist nämlich zwingend notwendig, dass der UPN „routebar“ sein muss. Dies bedeutet, dass die Endung des UPN-Suffixes nicht auf einen nicht offiziell verwendbaren DNS-Namen enden darf und ausserdem der DNS-Name dem eigenen Unternehmen zugewiesen sein muss. Somit können Benutzerkonten aus Domänen, die auf einen UPN-Suffix, der zum Bespiel auf .local oder .ads endet, nicht innerhalb des Azure AD verwenden werden.

Um diese Problematik zu lösen gibt es zwei Möglichkeiten. Erstens besteht die Möglichkeit den UPN-Suffix bei allen Konten im Active Directory, 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. Dies ist innerhalb von wenigen Sekunden über die Konsole „Active Directory Domains and Trusts“ zu erledigen.

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 sogenannte „Alternate LoginID“, ist noch nicht allzu lange möglich und basiert auf der Nutzung eines anderen Attributes als Anmeldename im Azure AD. Hierbei wird grundsätzlich die Nutzung des Mail-Attributes empfohlen. Das ist auch für die Benutzerakzeptanz sinnvoll, da die meisten Anwender durchaus in der Lage sind sich ihre E-Mail-Adresse zu merken. Um dies zu ermöglichen wird im Wizard unter „User Principal Name“ das Active Directory-Attribut „mail“ ausgewählt. Jedoch kann dies auch als Security-Schwäche angesehen werden, da bei einer Brute-Force-Attacke der Nutzername offensichtlicher ist.

 

Zum Thema Domainname: hierbei ist Vorsicht geboten. Seit August 2016 hat Microsoft das Verhalten von registrierten Domains geändert:

„Starting today, we’re blocking the ability to create a new personal Microsoft account using a work/school email address, when the email domain is configured in Azure AD.”

(Quelle: https://blogs.technet.microsoft.com/enterprisemobility/2016/09/15/cleaning-up-the-azure-ad-and-microsoft-account-overlap/)

 

In einem mir bekannten Fall führte das dazu, dass sich die Mitarbeiter keine neuen Windows/Live Accounts mit der Firmenmaildomain mehr anlegen konnten, was zur Nutzung eines Services aber erforderlich war.

 

 

Sobald die beiden Kernfragen beantwortet sind, kann ich grundsätzlich loslegen und testen. Da der Standard Azure AD Service ohne weiteres kostenlos ist, kann man sich auch mal ohne weiteres eine Testumgebung aufbauen.

 

Aber bitte das Domainnamen Thema beachten! J

Empfohlene Referenzen für die Installation

Zum Glück gibt es bereits einige Blogger, die eine detaillierte Installation beschrieben haben. Hier meine Empfehlungen:

http://www.faq-o-matic.net/2015/11/09/azure-active-directory-connect-custom-installation/

http://www.msxfaq.de/cloud/identity/adsync.htm

https://docs.microsoft.com/de-de/azure/active-directory/active-directory-whatis

PowerShell:

Natürlich kann man vieles per PowerShell steueren, siehe dazu New AzureAD Module for Office 365

 

Viele Grüße,

Jean.

Inhalt:

Identity Bridge Part1: Einleitung

Identity Bridge Part2: Azure AD – Was ist das?

Identity Bridge Part3: AzureAD – Archtitektur

Identity Bridge Part4: AzureAD – AD Strategie und Installation

Share Button

Ersten Kommentar schreiben

Antworten

Ihre E-Mail-Adresse wird nicht veröffentlicht.


*