Active Directory Connector - Matching von Objekten

Wenn Sie mit dem ADC die beiden Verzeichnisdienste "Exchange 5.5 DIR.EDB" und das "Active Directory" verbinden, dann kann der ADC natürlich nicht einfach neue Objekte anlegen. Er muss sehen, ob es Objekte gibt, die zueinander passen. So hat jedes Exchange 5.5 Postfach ja ein "Primäres Windows-NT Konto", welches natürlich auf einen Active Directory passt.

Daher gibt es entsprechende Regeln im ADC, um diese Zuordnung herzustellen. Diese Zuordnung können Sie ändern, aber davon kann nur abraten.

Matching von Benutzern bei der Erstreplikation EX -> AD

Im Artikel "316047 XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts" ist sehr gut beschrieben, wie der ADC bei der Replikation auf bestehende Benutzer reagiert. Gerade in Umgebungen, in denen Exchange 5.5 mit Windows NT4 oder Windows 2000 Domänen Benutzern verbunden wird, ist es gewollt, dass der ADC die Exchange 5.5. Eigenschaften dem "passenden" NT Konto im Active Directory zuordnet. Und das geht so:

Kann der ADC keinen Benutzer finden, den er zuordnet, dann legt der ADC einen Exchange 2000/2003 Disabled Account an, welcher quasi als "Platzhalter" dient. Sie sollten diesen Benutzer nicht aktivieren und zur Anmeldung benutzen, da diese ja definitiv nicht der Benutzer ist, der bisher das Postfach genutzt hat. Sorgen Sie besser dafür, dass der Platzhalter Benutzer mit dem später in das AD migrierten Anwender verbunden und gelöscht wird (ADClean) oder wenn der Postfachbenutzer weiterhin in einer NT4 Domäne verbleibt, dann weisen Sie diesen als "Associated Externals Account" zu. Siehe "Q278888 XADM: How to Associate an Exchange 2000 Mailbox with a Windows NT 4.0 Account"

Matching von Benutzern bei der Erstreplikation AD->EX

Auch in der umgekehrten Richtung gibt es eine vergleichbare Logik:

Im Artikel "Q316047 XADM: How to Enable Disabled Accounts That the ADC Creates" ist sehr gut beschrieben, wie der ADC bei der Replikation auf bestehende Benutzer reagiert. Gerade in Umgebungen, in denen Exchange 5.5 mit Windows NT4 oder Windows 2000 Domänen Benutzern verbunden wird, ist es gewollt, dass der ADC die Exchange 5.5. Eigenschaften dem "passenden" NT Konto im Active Directory zuordnet. Und das geht so:

Erst wenn diese drei Tests fehlschlagen, dann legt der ADC ein passendes Objekt ausgehend vom LegacyExchangeDN an.

Steuern des Matching

Was viele nicht wissen, ist die Möglichkeit eigene Felder für das Erkennen von Zugehörigkeiten zu definieren. Allerdings ist diese Einstellung global für alle ADC-Verbindungsvereinbarungen im Forest. Die Konfiguration erfolgt einfach über die MMC

Diese Einstellungen werden in der "Default ADC Policy" im Active Directory gespeichert:

Hierzu möchte ich aus News vom  (englisch) zitieren:

Newsgroup: Microsoft.public.exchange2000.win2000
Subject: "ADC and Connection Agreements"
Date: Mi 24 Okt. 2001 03:43
Von: Jerry Wu (Microsoft Support )

The six default matching rules for Exchange Server 5.5 objects to Active
Directory are described in the following list:

- The first rule attempts to match the Exchange Server object's Assoc-NT-Account value with the ObjectSID value in Active Directory ensuring that all values are preserved (no deletions) and the conversion of ASCII data to binary.

ObjectMatch##
#Assoc-NT-Account#ObjectSID
#sid_match EscapeBinaryBlob#

- If the Exchange Server object's Extension-Attribute-10 contains the string "NTDS Contact", then ignore the previous rule.

ObjectMatch##user$organizationalPerson$person$top
#Extension-Attribute-10#"NTDS Contact"
#veto-previous#

- Similar check for the string "NTDSNOMatch":

ObjectMatch##user$organizationalPerson$person$top
#Extension-Attribute-10#"NTDSNoMatch"
#veto-previous#

- If the target Active Directory object contains a populated legacyExchangeDN, then ignore the first rule.

ObjectMatch##
#NotNULL#legacyExchangeDN
#veto-Previous#

- This rule attempts to match the Exchange Server object's Assoc-NT-Account value with the sIDHistory value to perform the match.

ObjectMatch##
#Assoc-NT-Account#sidhistory
#sid_match EscapeBinaryBlob#

- If the target Active Directory object contains a populated legacyExchangeDN, then ignore this rule.

ObjectMatch##
#NotNULL#legacyExchangeDN
#veto-Previous#

Diese News beschreibt den Aufbau der ADC-Regel und die Arbeitsweise des ADC zum Matchen von Objekten.

Matching von bereits existierenden Benutzern (msExchADCGlobalNames und ADC-Global-Names)

Nachdem der ADC ein Objekt miteinander verbunden hat, muss sichergestellt werden, dass die Objekte für immer miteinander gekoppelt sind. So wird sichergestellt, dass spätere Änderungen auf das gleiche Objekte repliziert werden, auch wenn diese verschoben werden. Dazu fügt der ADC bei den beiden Objekten, die miteinander repliziert werden, ein neues Feld hinzu, welches eine eindeutige Kennung enthält. (Siehe auch msExchADCGlobalNames)

Der ADC legt beide Felder an und füllt Sie mit mehreren Werten, so dass auch später immer noch eine Zuordnung selbst beim der Migration in andere Domänen mit ADMT möglich ist. Diese Feld ist auch Bestandteil des globalen Katalogs und damit auch Forrestweit wieder zu finden. Auch wenn der Benutzer nun in eine OU verschoben wurde, zu dem es gar keine Verbindungsvereinbarung gibt. Der ADC findet den Benutzer und ändert ihn auch dort, solange das Konto ausreichend Berechtigungen hat.

Die Felder werden nur dort angelegt, wo der ADC auch schreiben darf. Demnach wird das Feld es bei einer unidirektionalen Verbindung nur im Zielsystem und nicht im Quellsystem angelegt. Das Löschen dieses Feldes entspricht dem Zurücksetzen des Anwenders. Aus Sicht des ADC war dieser Anwender noch nie repliziert und wird beim nächsten Mal als möglicher Kandidat für eine Zuordnung betrachtet.

Haben Sie aber ein Quellobjekt, welches ein Feld msExchADCGlobalNames besitzt und das ursprüngliche Zielobjekt ist nicht auffindbar, dann verzögert der ADC die Replikation. Schließlich kann es ja sein, dass es mehrere ADCs gibt und das passende Zielobjekt einfach noch nicht auf dem angesprochenen Domainkontroller vorliegt. Der ADC versucht daher immer wieder das ursprüngliche Element zu finden.

Matchen von Gruppen und Verteilern

Nun haben wir lange genug über Benutzer, Kontakte und Postfächer diskutiert. Dabei gibt es auch noch Verteiler und Sicherheitsgruppen, die bei der Migration berücksichtigt werden wollen. Speziell bei der Migration von Exchange 5.5 nach Exchange 2000/2003 können wir davon ausgehen, dass es im Active Directory bzw. der früheren NT4-Domäne, die migriert wurde, sehr viele Sicherheitsgruppen gibt. Sicherheitsgruppen werden genutzt, um Berechtigungen zu vergeben.

Exchange 5.5 hingegen nutzt Verteiler, um Benutzer zu logischen Gruppen zusammen zu fassen und Nachrichten zu verteilen. Diese Verteiler können auch genutzt werden, um Berechtigungen auf öffentliche Ordner oder Postfächer zu vergeben. Aber diese Verteiler haben keinen Bezug zu einer Windows Sicherheitsgruppe. Es gibt kein Feld "Primäre Gruppen SID" oder ähnliches. Damit wird es schwer für den ADC, Gruppen dann zuzuordnen. Eigentlich bliebe hier nur der Alias, der auf den Gruppennamen zugeordnet werden könnte.

Der ADC repliziert natürlich auch die Verteiler aus Exchange als Verteiler in das Active Directory und umgekehrt, Allerdings gibt es hier keine Möglichkeit eine Zuordnung festzustellen. Eine Gruppe hat keine SID und selbst wenn zwei Gruppen den gleichen Namen haben, dann kann die Liste der Mitglieder unterschiedlich sein. Vielleicht wollten Sie auch gar nicht, das eine Gruppe sowohl als Verteiler als auch als Sicherheitsgruppe für andere Dienste verwendet wird.

Kurz: Der ADC legt immer Gruppen an und verbindet nicht bestehende Gruppen. ´Der ADC versucht nicht, Exchange 5.5 Verteiler auf Windows Sicherheitsgruppen zu matchen, sondern er legt immer "Universal Distribution Groups" an. Dies ist erst einmal ein sehr guter Ansatz. Bislang wurden Verteiler und Sicherheitsgruppen immer getrennt betrachtet und gepflegt. Einige Administratoren sehen darin zwar einen Nachteil, da nun eventuell einige Gruppen ziemlich "gleich" sind und trotzdem getrennt gepflegt werden. Aber dies können Sie einfach lösen, indem Sie die Verteiler löschen und die vorhandenen Sicherheitsgruppen einfach "Exchange aktivieren".

Unterstützung durch Net at Work:
Ich kann mir vorstellen, das gerade große Firmen hier einen Automatismus suchen, um Gruppen zu matchen oder die Exchangeeigenschaften einer Gruppe auf eine andere Gruppe übertragen wollen.
Sprechen Sie mich an, wenn Sie Bedarf ein einer solchen Lösung haben.

Auf der anderen Seite sollten Sie froh sein, dass der ADC die Gruppen nicht matched, denn sehr viele Firmen möchten gerade eine getrennte Verwaltung. Sehr oft sollen Mitarbeiter z.B. im Verteiler "Vertrieb" aufgenommen werden, aber damit nicht zugleich auch alle Zugriffsrechte auf die Dateiserver des Vertriebs erhalten. Eine getrennte Verwaltung ist also durchaus üblich und oft gewünscht. Zudem entgehen Sie dann der umgekehrten Falle. Wenn Sie einen Mitarbeiter auf dem Verteiler entfernen, dann würde er auch aus der Sicherheitsgruppe entfallen, was auch oft nicht gewünscht ist. Das gleich passiert, wenn Sie einen Mitarbeiter nur das Postfach entfernen. Da er damit in Exchange 5.5 nicht mehr existiert, wird er dort aus den Verteilern entfernt, was wieder in das Active Directory repliziert wird. Der Mitarbeiter darf dann eigentlich auf gar keine Dateiserver mehr zugreifen.

Allerdings hat dieses "nicht matchen" auch Nachteile und anderer Effekte.

Das Problem haben Sie immer dann, wenn Sie folgendes Fenster sehen:

Ein universeller Verteiler kann nicht in eine Sicherheitsgruppe konvertiert werden. Wenn Sie eine Domäne im native Mode haben, dann sind die anderen Optionen nicht grau deaktiviert. Es ist natürlich denkbar, dass Sie ihre NT4-BDCs nicht so schnell deinstallieren können, besonders wenn diese selbst Exchange 5.5 Server sind, aber hier gibt es nur manuelle Wege:

Weitere Links

Keywords:ADC Replikation msExchADCGlobalNames ADC-Global-Names Matching