Tags: Identity-Management, Synchronisierung, Active Directory
Der Microsoft Identity Manager (MIM) bietet einen Synchronization Service, der Objekte zwischen verschiedenen Verzeichnisdiensten übertragen kann. Diese Anforderung besteht häufig bei der Synchronisierung von Benutzern zwischen AD-Forests. Die folgende Anleitung zeigt, wie man dies mit MIM bewerkstelligt.
Microsoft stellt für die beschriebene Aufgabe mit dem Active Directory Migration Tool (ADMT) auch ein kostenloses Werkzeug zur Verfügung. Es ist jedoch auf wenige Objekttypen beschränkt und zum Beispiel nicht in der Lage, Exchange-Eigenschaften zu synchronisieren. 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 bidirektionalen Trust miteinander verbunden (siehe dazu: Vertrauensstellung zwischen Forests im Active Directory einrichten). Sie enthalten jeweils einen Exchange- und einen SharePoint-Server.
Für den Test habe ich in beiden Domänen eine Organisationseinheit namens Migration angelegt, deren User ich nachher synchronisieren 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 beispielsweise Systemkonten nicht mit übertragen werden sollen.
Agents für die Synchronisierung erstellen
Das MIM Synchronization Server Manager Interface kann über das Startmenü geöffnet werden. Hier kann ich jetzt erste Synchronisationsjobs unter Management Agents => Create anlegen.
Im Feld Management agent for: bleibt Active Directory Domain Services stehen. Zudem wird unter Name ein aussagekräftiger Name vergeben.
Im nächsten Feld wird es nun etwas interessanter, weil wir damit die Verbindung zum Forest aufbauen.
Diese sollte sich ohne Probleme herstellen lassen. Danach zeigt der Wizard den Dialog Configure Directory Partitions.
Unter Containers wählen wir nun die Organisationseinheit 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.
Bei den Attributen bleibt es jedem selbst überlassen, welche davon er synchronisieren will. Man kann hier entweder alle oder nur bestimmte Felder übertragen.
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.
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.
Die Konfiguration kann danach abgeschlossen werden.
Die gleichen Konfigurationsschritte 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.
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.
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.
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.
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
Roland Eich ist gelernter Fachinformatiker für Systemintegration und in der IT seit über 14 Jahren zu Hause. Roland deckt aufgrund seiner Erfahrungen ein breites Spektrum der Microsoft-Produktpalette ab.Zudem besitzt er verschiedene Zertifizierungen (MCITP, MCSA und MCSE, ITIL, PRINCE2).
// Kontakt: E-Mail //
Verwandte Beiträge
- Identitäten für Microsoft 365: nur Cloud, synchronisiert oder föderiert
- AD-Passwörter synchronisieren mit Microsoft Identitiy Manager 2016
- Microsoft Identity Manager 2016 Synchronization Service installieren
- Microsoft Identity Manager 2016: Überblick über die Funktionen
- Verknüpfte Microsoft-Konten in Windows 8 mit GPOs verwalten
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.
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.