Microsoft Identity Manager Distribution Groups in gemischter Multi-Domain-Exchange-Umgebung

Setzt man den Microsoft Identity Manager (kurz MIM, ehemals Forefront Identity Manager/FIM) ein und hat in seiner Umgebung sowohl Linked Mailboxes als auch normale Accounts, die Mailboxes besitzen, so steht man sehr schnell vor einem entscheidenden Problem.

Anforderung:

• Verteilergruppen müssen über MIM verwaltet werden, der Anwender darf nicht in die Pflicht gebracht werden, den richtigen Account (Linked Mailbox/normalen Account) auszuwählen, sondern darf jeden Benutzer exakt einmal sehen
• Sicherheitsgruppen müssen ebenfalls über MIM verwaltet werden, alle Sicherheitsgruppen liegen in der contoso.com und müssen ggf. Mitglieder aus der contoso.com und der faq-o-matic.de beinhalten, somit normale User und Foreign Security Principals

Kurz zum Demo-Szenario:

• Zwei Domänen in separaten Forests (contoso.com und faq-o-matic.de)
• Exchange 2016 Cluster in contoso.com
• Native Mailboxen für User aus der contoso.com, Linked Mailboxes für User der faq-o-matic.com
• In der contoso.com existiert eine MIM Installation samt MIM Service & Portal
  • Es sind bereits beide Forests und dessen Domänen gemäß Microsofts Vorgaben im MIM Portal angelegt und die Foreign Security Principal Sets so wie Sync Rules für die „richtigen“ User Accounts aus beiden Domänen angelegt
  • Die Linked Mailboxes wurden über den Inbound Sync Filter der User Sync Rules ausgeschlossen

Der Identity Manager ist bereits von Haus aus in der Lage, Foreign Security Principals in Richtung Active Directory zu synchronisieren, sofern die Konfiguration der Domänen und Trusts vollständig ist, somit ist die Anforderung für die Sicherheitsgruppen bereits mit wenig Aufwand gedeckt.

Schwieriger wird es, wenn man auch Verteilergruppen verwalten will, denn hier müssen wir MIM beibringen, nicht die distinguishedNames der jeweiligen Quell Accounts in das Member Attribut der Gruppen zu synchronisieren, wie es für Sicherheitsgruppen richtig ist, sondern je nach Typ entweder den distinguishedName der vollwertigen Mailbox oder im Falle eines Users aus der faq-o-matic.de den distinguishedName der zugehörigen Linked Mailbox.

Die Lösung

Microsoft hat sich hierfür eine Lösung ausgedacht, die zwar technisch funktioniert, allerdings enorme Nachteile aufweist und meines Erachtens nicht wirklich praktikabel ist. Aufgrund einer technischen Limitierung der Management Agent Architektur kann bei Outbound Flow Rules lediglich die Reihenfolge der verlinkten Objekttypen manipuliert werden. Das bedeutet, dass man mit nativen Bordmitteln lediglich das Member Attribut beeinflussen kann, wenn die zu unterscheidenden Objekte auch unterschiedliche Objekttypen haben, sind z.B. beide vom Typ Person, wie es eben ein User Objekt und eine Linked Mailbox sind, so kann MIM diese beim Outbound Flow nicht unterscheiden.

Behält man diese technische Limitierung im Kopf, versteht man den Weg, wie Microsoft dies nativ gelöst hat:

In dieser Lösung wird für jeden User, der eine Linked Mailbox besitzt, ein Pseudo Kontakt erstellt, welcher dann anstatt des Quell Accounts in die Verteilerlisten geschrieben wird. Ein solcher Kontakt wird für jede Linked Mailbox erstellt und per Join Rule mit dem MIM User Objekt verbunden. Im Anschluss wird die Outbound Sync Rule für das Member Attribut so manipuliert, dass sofern vorhanden, der distinguishedName des verbundenen Kontaktes Vorrang gegenüber dem distinguishedNames des Quell Accounts hat und somit statt diesem in das Member Attribut geschrieben wird. Technisch gesehen, ist jeder User nun nur einmal im Portal vorhanden und MIM kümmert sich darum, dass gemischte Verteilergruppen jeweils den Kontakt für eine Linked Mailbox beinhaltet statt den Quell Account des Users.

In diesem Szenario erhält der Benutzer zwar die E-Mails, die an die Verteilergruppe gesandt werden, allerdings entstehen folgende Nachteile:

• Für jede Linked Mailbox wird zusätzlich ein Mail Kontakt im AD und Exchange angelegt
• Die Mitgliedschaft der Verteilergruppe ist nicht auf der Linked Mailbox sichtbar, da diese tatsächlich gar nicht Mitglied der Verteilergruppe ist, sondern nur der Kontakt, der auf diese Linked Mailbox weiterleitet
• Benutzer sehen im schlimmsten Fall jeden Benutzer, der über eine Linked Mailbox angebunden ist, zweimal in der Global Address List
• Verwaltung der Verteilergruppe ist bei Equal Precedence vom Gruppenbesitzer zwar noch möglich, allerdings wird dieser durch die Kontakte der Pseudo Kontakte unnötig verwirrt
• Die Presence Funktion von Skype for Business funktioniert nicht bei Mails, die an diese Verteilergruppen gesandt werden. Das liegt daran, dass die Exchange legacyDN des Kontakt für den Presence Lookup genutzt wird, diese hat natürlich keine Presence Informationen

Die bessere Lösung

Nun zu der meines Erachtens nachhaltigeren Lösung, die auch wesentlich bessere User Experience bringt und ohne zusätzliche Kontakte arbeitet:

Die kurze Version: Wir sorgen dafür, dass jeder User ein weiteres Attribut hat, welches wir als „relevantMailboxDN“ bezeichnen. Dieses Attribut hält den für Verteilergruppen relevanten distinguishedName eines Benutzers, des Weiteren bauen wir einen Workflow, welcher nach Änderung einer Verteilergruppe ein Array des Attributes relevantMailboxDN der Gruppenmitglieder baut. Nun schreiben wir für Verteilergruppen statt dem „member“ Attribut das vom Workflow kalkulierte Array der Mailbox DNs zurück in die contoso.com.

Die lange Version Schritt für Schritt:

1. Zuerst brauchen wir zwei Zusatzkomponenten, die aber ohnehin in jeder größeren MIM Installation vorhanden sind:
   • Die Advanced Workflow Library “MIMWAL”, welche von Microsoft stammt: https://github.com/Microsoft/MIMWAL
   • Der weitbekannte PowerShell Management Agent von Søren Granfeldt: https://github.com/sorengranfeldt/psma
2. Ein Attribut im Metaverse und MIM Service namens „relevantMailboxDN“ vom Typ String anlegen und an den ObjectTyp „user“ (im Metaverse „person“) binden
   • Dieses Attribut fügen wir als Export Attribut im Flow des MIM Service Connectors an (Schema Refresh notwendig)
3. Ein Attribut im Metaverse und MIM Service namens „distGroupMembers“ vom Typ Multi Line Array anlegen und an den ObjectTyp „group“ binden
   • Dieses Attribut fügen wir als Import Attribut im Flow des MIM Service Connectors an (Schema Refresh notwendig)
4. Nun legen wir einen weiteren Active Directory Connector für die contoso.com an
   • Den Sync Scope auf die Linked Mailbox OUs beschränken
   • Eine Inbound Sync Rule im MIM Portal anlegen

• „Create Ressource in FIM“ nicht aktivieren
• Relationship „objectSid“ (Metaverse) <-> „msExchMasterAccountSid“ (ConnectedSystem)
• Attribute Flow:
  • dn => relevantMailboxDN
• Den Sync Scope auf die Linked Mailbox OUs beschränken

5. Für jeden Active Directory Connector den Attribut Flow wie folgt weitern:
   • dn => relevantMailboxDN
6. Im Metaverse Designer beim Object Type „Person“ die Precedence des Attributes relevantMailboxDN so konfigurieren, dass der frisch angelegte Linked Mailbox Active Directory Connector an erster Stelle und der MIM Service Connector am Ende steht
7. Einen Workflow erstellen, welcher das Array der relevantMailboxDN Attribute der Gruppenmitglieder baut:

8. Ein Set anlegen, welches alle Gruppen mit dem Gruppentyp „Distribution“ beinhaltet
9. Eine Management Policy Rule des Types „Request” anlegen:
   • Specific Set of Requestors: All People
   • Operation:

o Add a value to a multivalued attribute

o Remove a value from a multivalued attribute

• Target Resource Definition Before Request: <Das erstellte Set>
• Target Resource Definition After Request: <Das erstellte Set>
• Resource Attributes: Select specific attributes

o Manually-managed Membership

• Action Workflow: <Der erstellte Workflow>

10. Einen neuen Powershell Management Agent anlegen
    • Agent Files von diesem Repository runterladen: https://github.com/RobinBeismann/MIM-Projects/tree/master/PSMA-based/PSMA_DistributionGroups
    • Run As Account mit ausreichenden AD Berechtigungen hinterlegen
    • Eine Outbound Sync Rule im MIM Portal anlegen

• Relationship „objectGUID“ (Metaverse) <-> „ objectGUID“ (ConnectedSystem)
• Attribute Flow:
  • distGroupMembers => members
• “Enable Deprovisioning” aktivieren

11. Im Metaverse Designer beim Object Type „group“ die Precedence des Attributes distGroupMembers so konfigurieren, dass der MIM Service Connector an erster Stelle steht
12. Einen Full Import / Full Sync auf allen Management Agents durchführen, angefangen mit dem MIM Service Management Agent, da dieser die neuen Sync Rules bereitstellt

Fazit:

Sobald dies getan ist, werden alle Linked Mailboxes mit dem nativen Account im Metaverse verbunden und der für MIM relevante Mailbox distinguishedName fließt in das Attribut „relevantMailboxDN“. Dieser Join sorgt ebenfalls dafür, dass der MIM Service automatisch die Verteilergruppenmitglieder auf deren MIMService Identität auflöst und wie gewollt anzeigt. Wenn nun eine Verteilergruppe bearbeitet wird, wird der erstellte Workflow gestartet, welcher das „distGroupMembers“ Attribut mit den korrekten distinguishedNames füllt und anschließend über den PowerShell Management Agent in das Active Directory schreibt. Der Active Directory Management Agent für contoso.com liest nun beim nächsten Import die vom Powershell Management Agent geschriebene Änderung ein und reflektiert diese im Metaverse, sodass keine „Exported Change not reimported“ Fehler auftreten.