Benutzerkonten zwischen AD-Forests synchronisieren mit dem Microsoft Identity Manager


    Tags: , ,

    Microsoft Identity ManagerDer Microsoft Identity Manager (MIM) bietet einen Synchro­nization Service, der Objekte zwischen ver­schiedenen Ver­zeichnis­diensten über­tragen kann. Diese Anfor­derung besteht häufig bei der Synchro­nisierung von Be­nutzern zwischen AD-Forests. Die fol­gende An­leitung zeigt, wie man dies mit MIM bewerk­stelligt.

    Microsoft stellt für die beschriebene Aufgabe mit dem Active Directory Migration Tool (ADMT) auch ein kosten­loses Werkzeug zur Verfügung. Es ist jedoch auf wenige Objekttypen beschränkt und zum Beispiel nicht in der Lage, Exchange-Eigenschaften zu synchro­nisieren. MIM ist im Vergleich dazu wesentlich mächtiger.

    Aufbau der Testumgebung

    Meine Domänen heißen contoso.local und roland.local. Diese sind über einen bidirek­tionalen Trust miteinander verbunden (siehe dazu: Vertrauensstellung zwischen Forests im Active Directory einrichten). Sie enthalten jeweils einen Exchange- und einen SharePoint-Server.

    Lab-Umgebung, bestehend aus zwei Forests, deren Domänen über eine Vertrauensbeziehung verknüpft sind.

    Für den Test habe ich in beiden Domänen eine Organisations­einheit namens Migration angelegt, deren User ich nachher synchro­nisieren möchte. Natürlich wäre es auch möglich, den Sync über den gesamten Forest laufen zu lassen. Dies macht aber keinen Sinn, da beispiels­weise System­konten nicht mit übertragen werden sollen.

    Eigene OU für die spätere Synchronisierung von Benutzerkonten

    Agents für die Synchronisierung erstellen

    Das MIM Synchronization Server Manager Interface kann über das Startmenü geöffnet werden. Hier kann ich jetzt erste Synchro­nisationsjobs unter Management Agents => Create anlegen.

    Anlegen eines neuen Management Agents für die Synchronisierung

    Im Feld Management agent for: bleibt Active Directory Domain Services stehen. Zudem wird unter Name ein aussage­kräftiger Name vergeben.

    Management Agent für die AD Domain Services auswählen

    Im nächsten Feld wird es nun etwas interessanter, weil wir damit die Verbindung zum Forest aufbauen.

    Mit dem Forest durch Eingabe der Anmeldedaten verbinden

    Diese sollte sich ohne Probleme herstellen lassen. Danach zeigt der Wizard den Dialog Configure Directory Partitions.

    AD-Container auswählen, deren Benutzerobjekte synchronisiert werden sollen.

    Unter Containers wählen wir nun die Organisations­einheit Migration aus, welche wir oben für diesen Zweck bereits angelegt haben.

    Im Bereich Select Object Types ist es wichtig, dass wir einen Haken bei User setzen, weil wir diese ja synchronisieren wollen.

    Objekttypen für die Synchronisierung auswählen, in unserem Fall User

    Bei den Attributen bleibt es jedem selbst überlassen, welche davon er synchronisieren will. Man kann hier entweder alle oder nur bestimmte Felder übertragen.

    Attribute der Objekte auswählen, die synchronisiert werden sollen.

    Im Bereich Configure Join and Projection Rules sollte nach dem Klick auf User und dann auf die Schaltfläche New Projection Rule als Auswahl person stehen.

    Dem AD-Objekt user steht person als Metaverse Attribute im Zeilverzeichnis gegenüber.

    Im nächsten Schritt erfolgt die Zuordnung von Data Source Attribute zu Metaverse Attribute, also das Mapping der Felder aus der Datenquelle zu jenen im Ziel.

    Mapping der Attribute konfigurieren

    Die Konfiguration kann danach abgeschlossen werden.

    Die gleichen Konfigurations­schritte müssen nun auch für die andere Domäne durchgeführt werden, allerdings mit folgenden Ausnahmen:

    • Unter Configure Join an Projection Rules wird keine Projection Rule angelegt
    • Im Fenster Configure Attribute Flow müss der Flow auf Export und nicht auf Import stehen, die Pfeile somit von rechts nach links zeigen.

    Der Indikator für den Attribut Flow muss beim Export nach links zeigen.

    Run Profiles konfigurieren

    Um nun die Synchronisation ausführen zu können, müssen für beide Agents Run Profiles erstellt werden. Dazu öffnet man das Kontextmenü der Agents und führt den Befehl Configure Run Profiles aus.

    Run Profiles für die Sync-Agents konfigurieren

    Für den Agent Contoso brauchen wir die Profile

    • Delta Synchronization
    • Full Import (Stage Only)
    • Full Synchronization
    • Delta Import (Stage Only)

    Der Agent Roland benötigt die Run Profile

    • Full Import (Stage Only)
    • Full Synchronization
    • Export
    • Delta Import (Stage Only)

    Alle anderen Werte bei den Run-Profilen werden nicht verändert oder angepasst.

    Run Profile für den Sync-Agent der Ausgangsdomäne konfigurieren

    Damit wäre die Synchronisation der User vom Forest Contoso in den Forest Roland eigentlich schon möglich. Gebraucht wird nun aber noch eine so genannte extension.dll, welche die Übergabe der Attribute regelt.

    Diese kann mit dem Befehl Create Rules Extension Project unter Tools => Options erstellt werden.

    extension.dll für die Synchronisierung erstellen

    An dieser Stelle möchte ich auf folgendes E-Book verweisen, welches die Erstellung der Extension mit Visual Studio beschreibt. Daraus stammt auch der folgende Beispiel-Code. Zudem habe ich die Erfahrung gemacht, dass der Autor für Rückfragen gerne zur Verfügung steht.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Roland Eich

    Roland Eich ist gelernter Fach­infor­matiker für System­inte­gration und in der IT seit über 14 Jahren zu Hause. Roland deckt auf­grund seiner Erfah­rungen ein breites Spek­trum der Microsoft-Produkt­palette ab.Zudem besitzt er ver­schiedene Zertifi­zierungen (MCITP, MCSA und MCSE, ITIL, PRINCE2).
    // Kontakt: E-Mail //

    Verwandte Beiträge

    Weitere Links

    2 Kommentare

    Och nö... :-((( Nicht .local als Domänenendung. :-///

    .local ist seit Anfang der 2000er Jahre für mDNS (Multicast-DNS) reserviert. Selbst Microsoft rät seit dem Jahr 2003 davon ab, ".local" zu benutzen.

    Für technische Dokumentationen gibt es example.com (auch IPv4- und IPv6-Adressen - alles in einem RFC normiert).

    Für produktive Zwecke können Buchstabenkombinationen verwendet werden (z. B. .xa - .xz), die gemäß IANA, RFCs und ISO nicht verwendet werden.

    Bild von Wolfgang Sommergut

    Grundsätzlich korrekter Einwand. Aber der Beitrag empfiehlt ja niemandem, .local zu verwenden. Vielmehr ist klar, dass man den FQDN aus dem Beispiel durch seine eigene Domäne ersetzen muss.