Azure Active Directory – Teil III

Synchronisierung Active Directory <> Azure Active Directory

Viele kleinere Organisationen nutzen die Microsoft 365 Dienste mit eigenständigen Identitäten. In größeren Unternehmen trifft man häufig das Szenario an, dass das eigene lokale Active Directory (AD) mit dem Azure Active Directory (AAD) synchronisiert wird. Es gibt keine unteren oder oberen Schwellenwerte von AD-Objekten, wo eine Synchronisierung empfohlen wird. Je größer die lokalen Verzeichnisstrukturen sind, desto sinnvoller ist es natürlich, eine Synchronisierung der beiden Verzeichnisse bereitzustellen. Azure AD Connect ist das Microsoft-Tool zum Implementieren der Verzeichnissynchronisierung mit Azure AD.

Wenn Mitarbeiter im Unternehmen über ein lokales AD-Konto verfügen, möchte man in der Regel eine hybride Identität verwenden, um die Identität sowie das Kennwort nicht an zwei Stellen verwalten zu  müssen. Der erste Schritt zum Aufbau einer hybriden Identitätsinfrastruktur besteht darin, die Verzeichnissynchronisierung zu konfigurieren. Dieses wird mit dem kostenfreien Dienst Azure AD Connect (ADC) realisiert. ADC ist das Microsoft-Tool zum Implementieren der Verzeichnissynchronisierung mit dem Azure AD.

Um auf Workloads in Microsoft 365 zugreifen zu können, muss ein Benutzer über eine sogenannte Cloud-Identität verfügen. Mit Microsoft 365 können Unternehmen das vorhandene lokale AD mit Azure AD über den als Verzeichnissynchronisierung bezeichneten Prozess verwenden.

In diesem Prozess werden einige Kontoeigenschaften und Attribute von lokalen Benutzern, Gruppen, Kontakte und anderer Objekttypen aus dem lokalem AD mit dem Azure AD synchronisiert.

Zusätzlich zu den Attributen von Benutzern kann ADC auch die Synchronisierung von Kennwort-Hashes umfassen, um den Endanwendern eine „nahtlose Anmeldeerfahrung“ zu bieten, bei der sie denselben Benutzernamen und dasselbe Kennwort verwenden ohne die tatsächlichen Kennwörter in Microsoft 365 zu speichern.

Für bestimmte Funktionen ist auch eine Verzeichnissynchronisierung erforderlich. Beispiele sind hier der Einsatz einer hybriden Exchange-Infrastruktur oder aber der Einsatz von Active Directory Federation Service (AD FS).

Aus der Praxis – Exchange Migrationszenarien

Die Verzeichnissynchronisierung untermauert die Hybrid-Migrationsszenarien für Exchange Online. Wenn eine Cutover-Migration durchgeführt wird, kann die Verzeichnissynchronisierung vor oder während der Migration nicht verwendet werden. Die Synchronisierung kann jedoch implementiert werden, sobald die Migration abgeschlossen ist. In Situationen, in denen Migrationstools von Drittanbietern verwendet werden, ist es wichtig, dass die vom Anbieter bereitgestellte Dokumentation sorgfältig geprüft wird, bevor Migrationsaktivitäten beginnen. In vielen Fällen können die Microsoft-Verzeichnissynchronisierungstools nicht vor oder während der Verwendung eines Migrationstools eines Drittanbieters implementiert werden, da der Anbieter möglicherweise eigene Synchronisierungstools bereitstellt.

Fragestellungen

Aufgrund der entscheidenden Rolle, die die Verzeichnissynchronisierung in der Verwaltung von Identitäten spielt, müssen mehrere Entscheidungen getroffen werden:

  • Werden Objekte aus einer einzelnen AD-Gesamtstruktur oder aus mehreren Gesamtstrukturen synchronisiert ?
  • Welche Art von Authentifizierung soll im Unternehmen verwendet werden ? Hier stehen die Optionen „Passwort-Hash-Synchronisation“, Pass-Through-Authentication oder AD FS zur Verfügung.
  • Sollen alle AD-Objekte oder nur bestimmte OUs/ Gruppen synchronisiert werden ?
  • Ist eine dedizierte SQL Server-Instanz erforderlich würde die integrierte SQL Server-Instanz (LocalDB) für die eigene Umgebung ausreichen ?
  • Soll Azure AD Connect auf einem vorhandenen Server, einem dedizierten Server oder sogar in Microsoft Azure installiert werden ?
  • Ist der ADC-Server in ein eventuell vorhandenes Zonenkonzept eingebunden ?

Zwei mögliche Optionen zur Synchronisierung

Microsoft bietet zwei Tools zur Verzeichnissynchronisierung an:

  • Azure Active Directory-Verbindung (Azure AD Connect oder ADC):
    Dieses Tool ist das von Microsoft empfohlene Synchronisierungstool für die Verbindung lokaler Verzeichnisse und Office 365-Verzeichnisse. Es ist auch das Tool, das als Download angeboten wird, wenn Kunden die Verzeichnissynchronisierung über das AAD konfigurieren.
  • Microsoft Identity Manager (MIM): MIM ist der Nachfolger von Forefront Identity Manager. Vor Azure AD Connect gab es bestimmte Anwendungsfälle für die Verzeichnissynchronisierung, die mit den Vorgängern des ADC nicht erfüllt werden konnten. Diese Anwendungsfälle wurden in den aktuellen Versionen des Azure AD Connect integriert. Die Synchronisierungs-Engine im ADC wird kontinuierlich weiterentwickelt und verfügt über weitere Funktionen, die speziell auf die Synchronisierung mit dem Azure AD ausgerichtet sind.

Daher konzentriere ich mich in diesem Beitrag auf das Tool Azure AD Connect.

Technischer Hintergrund

Bei der Einführung des ADC spielen verschiedene Konzepte eine sehr wichtige Rolle:

  • Metaverse:
    Die Metaverse ist die konsolidierte Ansicht aller verbundenen Identitäten aus den verschiedenen Datenquellen (Connector Spaces) in Azure AD Connect. Es kombiniert die Identitätsinformationen für ein Objekt und wird in einer SQL Server-Datenbank gespeichert.
  • Connector:
    Früher als Management-Agents bezeichnet, sind die Connectoren die Module im Azure AD Connect, die eine Verbindung zu den Datenquellen (Lokales AD/ Azure AD) herstellen.
  • Connector Space:
    Der Connector Space ist im Grunde ein Cache, der zwischen einer verbundenen Datenquelle und der Metaverse integriert ist. Jede Art von Änderungen an Objekten (Hinzufügen, Änderung oder Löschung) werden im Connector Space gespeichert, bis der nächste Synchronisierungsvorgang ausgeführt wird. Wichtig ist zu wissen, dass der Connector Space nicht das tatsächlich synchronisierte Objekt speichert, sondern eine Schattenkopie mit den geänderten Attributen bis zur nächsten Synchronisierung speichert. Jeder Connector verfügt über einen eigenen Connector Space und definiert, welche Objekte und Attribute im Connector Space gespeichert werden.
  • Attribute Flow:
    Dies ist der Prozess, bei dem Daten von einer verbundenen Datenquelle in eine andere kopiert werden.
  • Source anchor:
    Das Attribut „Source anchor“ sorgt für die Verknüpfung mit dem Objekt in Azure AD. Standardmäßig wird der Wert des objectGUID-Attributs des Objekts verwendet. Der Wert des objectGUID-Attributs wird als base64-codierte Zeichenfolge im ImmutableID-Attribut des entsprechenden Objekts in Azure AD gespeichert.
    Ab Version 1.1.524.0 vom ADC verwendet das Tool das Attribut msDs-ConsistencyGuid anstelle des Attributs schreibgeschützt objectGUID, wenn das Attribut msDS-ConsistencyGuid nicht bereits befüllt ist.
    Wenn ADC die msDS-ConsistencyGuid verwendet, nimmt es den Wert der objectGUID und schreibt ihn in binärer Form zurück in die msDs-ConsistencyGuid. Auf diese Weise können Sie die Referenz später manuell aktualisieren.

    Beispiel: Wenn ein Objekt mit einem anderen (bereits vorhandenen) Cloud-Objekt verknüpft werden muss oder wenn Organisationen mehrere lokale Gesamtstrukturen haben und das Objekt von einer anderen Gesamtstruktur erneut mit dem entsprechenden Objekt in der Cloud verknüpft werden muss, nachdem ein Konto von einem lokalen Forrest in einen anderen Forrest umgezogen ist. ADC speichert den Source anchor in seiner Metaverse im Attribut sourceAnchor.

    WICHTIG:
    Das ausgewählte Attribut darf sich während der Lebensdauer des Objekts nicht ändern. Andernfalls treten Synchronisierungsprobleme, Authentifizierungsprobleme bei Verwendung eines ADFS-Verbundes und andere unerwünschte Auswirkungen auf die Microsoft 365-Dienste auf.

Source of Authority

Administratoren können nur eine geringe Anzahl an Eigenschaften eines synchronisierten Objekts direkt in im AAD verwalteten. Beim Versuch, andere synchronisierte Eigenschaften über das M365 –  Admin Center oder PowerShell zu bearbeiten, wird ein Fehler generiert.

Ein Beispiel:
Wenn ein Administrator versucht, einen Benutzer aus dem Adressbuch auszublenden, indem er das Cmdlet Set-Mailbox in Exchange Online ausführt, führt zu einer Fehlermeldung:

[PS] C:\> Set-MailUser max.mustermann -HiddenFromAddressListsEnabled $True

The operation on mailbox "Max Mustermann" failed because it's out of the current user's write scope. The action 'Set-MailUser', 'HiddenFromAddressListsEnabled', can't be performed on the object 'Max Mustermann' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

Dies liegt daran, dass die Synchronisierung hauptsächlich in eine Richtung erfolgt und von der lokalen Organisation in das Azure AD fließt. Die lokale Version des Objekts ist die Quelle der Autorität. Objekte, die direkt in Microsoft 365 erstellt werden, gelten als reine Cloud-Objekte und werden standardmäßig nicht mit dem lokalen AD synchronisiert.

Die einzige Ausnahme von dieser Regel ist, wenn im ADC die Writeback-Funktion aktiviert wurde. Writeback ist eine Funktion in Azure AD Connect, mit der einige Empfängertypen (z. B. Gruppen) und Attribute wieder in die lokale AD-Gesamtstruktur synchronisiert werden können. Wichtig ist zu beachten, dass die Entscheidung zur Implementierung des Writeback Auswirkungen darauf haben kann, wie Hybridempfänger verwaltet werden.

Trotz der allgemeinen Regel, dass lokal synchronisierte Objekte nicht mit Online-Tools verwaltet werden können, können einige Postfachfunktionen in beiden Umgebungen verwaltet werden. Dies gilt insbesondere für Funktionen, für die der Synchronisierungsprozess Attribute in die lokale Umgebung zurückschreibt oder für die keine lokalen Verwaltungsfunktionen vorhanden sind.

Welche Objekte vom AD synchronisiert werden, ist im M365-Portal > Benutzerverwaltung einsehbar (Synchronisierungstyp). Alternativ kann über die PowerShell (Modul Azure AD) die folgende Abfrage ausgeführt werden:

[PS] C:\> Get-AzureADUser -Filter „DirSyncEnabled eq true“
ObjectId DisplayName UserPrincipalName
——– ———– —————–
4f9f6f4e-f12c-4528-949a-86bfb588048c Torben Ritter tritter@tri-demolab.de
7561973e-3ec1-4c42-bdbc-aa336dededc4 Max Mustermann
mmustermann@tri-demolab.de

Die serverseitige Filterung unterstützt jedoch nicht die Verwendung aller Operatoren. Beispielsweise kann der Befehl „DirSyncEnabled true“ nicht verwendet werden, um nicht synchronisierte Konten abzufragen. Es wird hier die clientseitige Filterung aller (Benutzer-) Objekte zuerst in die Pipeline verschoben. Dieser Ansatz kann zwar mehr Zeit und Speicher beanspruchen, insbesondere bei der Arbeit mit großen Objektgruppen. Er bietet jedoch mehr Flexibilität, z. B. die Verwendung des Parameters „NotEquals (-ne)“, mit dem nach nicht synchronisierten Benutzern gefiltert werden kann.

Synchronisationsintervall

Azure AD Connect synchronisiert synchronisiert sich mit dem Azure AD alle 30 Minuten. Ein Administrator kann verschiedene Aspekte des Synchronisierungszeitplans steuern, z. B. das Intervall zwischen den Synchronisierungen (bis zu einem von Microsoft erzwungenen Mindestintervall von 30 Minuten) und die Art der Synchronisierung. Administratoren können auch eine Synchronisierung außerhalb des regulären Zeitplans erzwingen. In einigen Fällen ist der Zeitraum zwischen Änderung und Wirkung länger.

Wenn zum Beispiel ein Cloud-basiertes Archiv für ein lokales Postfach aktiviert wird, ist dieses Archiv erst verfügbar, wenn die Verzeichnissynchronisierung zweimal ausgeführt wurde: ein Zyklus zum Übertragen der Änderung von der Cloud in das lokale Postfach und ein Zyklus zum Re-Sync. Dies bedeutet, dass zwischen der Aktivierung des Archivs und dem Zugriff auf Clientschnittstellen länger dauert, als man erwartet.

Unterstützte Topologien

Die erste Empfehlung gegenüber Organisationen ist immer, das Design so einfach wie möglich zu halten. Dies spiegelt sich in der Empfehlung wider, wann immer möglich, eine einzelne AD-Gesamtstruktur zu verwenden. Dieses ist jedoch nicht immer möglich, da einige Organisationen noch eine ältere Infrastrukturen unterhalten, die komplexer als erforderlich sind.

Fusionen und Übernahmen können Sie beispielsweise dazu zwingen, mehrere lokale AD-Gesamtstrukturen zu verwalten. Einige dieser Verzeichnisse enthalten möglicherweise nur Benutzerkonten, andere haben möglicherweise auch Exchange Server bereitgestellt.

Hier ist aber ein wesentlicher Vorteil, dass Microsoft die Synchronisierung mehrerer AD-Gesamtstrukturen in einem einzigen Microsoft 365-Mandanten unterstützt. Obwohl ADC die Dinge erheblich vereinfacht, indem über einen schrittweisen Assistenten problemlos mehrere lokale Domänen hinzufügt werden können, die mit Azure AD synchronisiert werden sollen, empfiehlt Microsoft dennoch, wann immer möglich eine einzige synchronisierte Gesamtstruktur zu verwalten.

Die Verwendung mehrerer Gesamtstrukturen erhöht nur die Wahrscheinlichkeit von Synchronisierungsfehlern und vielen anderen Problemen, die sich aus diesen Fehlern ergeben. Die in den folgenden Abschnitten beschriebenen Synchronisationsszenarien werden von Microsoft unterstützt:

  • Single forest, Single Azure AD tenant
    Diese Topologie ist das einfachste und das in Organisationen am ehesten eingesetzte Synchronisationsszenario. Eine einzelne lokale AD-Gesamtstruktur wird über einen einzelnen Azure AD Connect-Server mit dem Azure AD synchronisiert. Mit Ausnahme eines Servers im Staging-Modus (Teil IV dieser Serie) können nicht mehrere Verzeichnissynchronisierungsserver für die Synchronisierung mit Azure AD verwendet werden.

    Obwohl man theoretisch mehrere Synchronisationsserver so konfigurieren könnte, dass nur eine Teilmenge von Objekten durch das Konfigurieren von Ausschlüssen synchronisiert wird, funktioniert dies nicht ordnungsgemäß.
  • Single forest, Multiple Azure AD tenants
    In diesem Szenario wird eine einzelne lokale Gesamtstruktur (mit mehreren Domänen) mit mehreren Azure AD-Mandanten synchronisiert.

    Ein Beispiel:
    Ein großes multinationales Unternehmen hat in jedem Land, in dem es tätig ist, separate Domänen und möchte separate Microsoft 365-Mandanten verwenden.

    Da zwischen einem Azure AD Connect-Server und einem Azure AD-Mandanten eine 1: 1-Beziehung besteht, muss für jeden Azure AD-Mandanten ein separater Server verwendet werden. Darüber hinaus muss jeder Azure AD Connect-Server so konfiguriert sein, dass Objekte ausgeschlossen werden, die von den anderen Servern synchronisiert werden, um sicherzustellen, dass Objekte nur mit einem Azure AD-Mandanten synchronisiert werden.

    Dieses Synchronisierungsszenario kann nicht nur eine Teilmenge der Benutzer mit jedem Azure AD-Mandanten synchronisieren, sondern weist auch andere Einschränkungen auf. Beispielsweise können in dieser Topologie nicht der selbe UPN-Suffix für verschiedene Azure AD-Mandanten verwendet werden, da eine Domäne nur in einem einzelnen Mandanten registriert werden kann. Daher müssen Organisationen sicherstellen, dass alle synchronisierten Objekte abhängig vom Azure AD-Mandanten, mit dem sie synchronisiert sind, alle ein anderes UPN-Suffix verwenden.

    WICHTIG:
    Diese Namespace-Einschränkung überträgt sich auch auf Microsoft 365, insbesondere im Hinblick auf den Nachrichtenfluss.

Wie geht es im nächsten Teil weiter..?

Im nächsten (Teil IV) gehe ich auf die detaillierten Features im Bezug zum Azure AD-Connect Server (Exchange Hybrid, Pass-Through-Authentication, Staging Mode) ein.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.