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:

  • Primary NT Account = SID
    Der ADC versucht im Active Directory einen Benutzer zu finden, der die gleiche ObjectSID oder SIDHistory hat, wie der primäre Account in Exchange 5.5 (Feld "Assoc-NT-Account"). Dies trifft immer dann zu, wenn der Benutzer im AD der gleiche ist, wie im Exchange 5.5 (Inplace Update der Domain) oder der Benutzer mit ADMT migriert wurde. Weitere "Übereinstimmungen", wie z.B. Alias, Mailadresse oder so werden nicht herangezogen !
  • DN = LegacyExchangDN
    Nur wenn das Zielobjekt mit der SID bereits ein Mailattribut hat, dann zieht der ADC das Feld LegacyExchangeDN hinzu.  Ist dieses Feld identisch, dann verfolgt ein Match.

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:

  • GUID = ObjectGUI
    Hier durchsucht der ADC den Exchange Verzeichnisdienst um für das gerade aktive Objekte im Active Directory und dessen GUID ein passendes Objekt in Exchange 5.5 zu finden.
  • LegacyExchangDN = DN
    Dann versucht der ADC, das Objekt zu finden, was im Active Directory Objekt im LegacyExchangeDN hinerlegt ist. Wenn das Objekt in Exchange 5.5 nicht gelöscht oder in einer andere Site migriert wurde, dann wird es gefunden
  • SID = primäry NT Account
    Zuletzt wird auch hier dann die SID des Benutzers im AD genommen, um ein Postfach mit einem passenden primären NT-Account in Exchange 5.5 zu finden

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:

  • msExchServer1ObjectMatch
    Enthält die Regeln zum Matchen für die Replikation vom Active Directory nach Exchange 5.5
  • msExchServer2ObjectMatch
    Enthält die Regeln zum Matchen für die Replikation von Exchange 5.5 ins Active Directory

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 für 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 für 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.

  • doppelte Sicherheitsgruppen
    Wird so ein Verteiler nun genutzt, um auf öffentliche Ordner Rechte zu erhalten, dann wird aus der Verteilergruppe durch den Store eine Sicherheitsgruppe gemacht !. Damit tauchen nach und nach immer mehr Verteiler auch in den Dialogfeldern für Freigaben etc. auf. Hier sollten dann alle Administratoren wissen, welche richtige "Sicherheitsgruppen" und welche "nur" konvertierte Verteiler sind. Es ist sehr ratsam, diese Gruppen durch klare Benennungen zu unterscheiden. für Sicherheitsgruppen könnte ein Präfix (SGG-  o.ä.) sinnvoll sein.
  • Windows Mixed Domain
    Zwar legt der ADC die entsprechenden Verteiler an, aber in einer gemischten Domäne mit Windows NT 4 Domain Controllern kann diese Gruppe nicht zu einer Sicherheitsgruppe konvertiert werden. In der Folge funktionieren zugriffe auf öffentliche Ordner nicht. Microsoft schreibt zwar immer, dass für die Funktion eine nativ Domäne ratsam wäre, aber das ist der Grund, warum Verteiler in einer nativ Mode Domäne liegen müssen. Bringen Sie daher ihre Domäne möglichst schnell in den Native Mode oder replizieren Sie ihre Verteiler in eine eigens dafür installierte temporäre Domäne.

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:

  • NT4-BDC Downgrade
    Ein NT4BDC kann nicht zum Memberserver werden. Aber Sie können ja die Dienste darauf sichern, den Server mit gleichem Namen neu installieren und die Dienste wieder restaurieren. Mit Datei und Druckdiensten ist das sehr einfach. DHCP, DNS und WINS sind auch einfach zu übernehmen. Selbst Exchange 5.5 könnte über ein Offline Backup mit nachfolgendem Recovery Setup (SETUP /R) und Offline Restore ziemlich schnell umgestellt werden
  • NT4 upgrade
    Sie können einen NT4BDC auf Windows 2000 aktualisieren. Dann ist er nur noch ein Member Server und stört nicht mehr die Domäne auf den Weg zum Native Mode
  • Gruppen umbauen
    Sie können aber auch versuchen, das gleiche von Hand zu machen, was ADClean für Postfächer automatisch macht. Sie könnten neue Sicherheitsgruppen anlegen und die Eigenschaften der Verteiler kopieren. Allerdings ist dieser Prozess eher mühsam und bei mehreren Gruppen lohnt sich hier schon ein Skript. Leider habe ich hierfür aber keine Lösung, da die zwei anderen Optionen bislang immer vorgezogen wurden.

Weitere Links