Microsoft Entra Connect in einer Multi Forest Umgebung ohne Vertrauensstellung

Hallo Leser,

heute möchte ich euch zum Thema Entra Connect in einer Multi Forest Umgebung aufschlauen. Natürlich muss ich euch Ermstal abholen wie die Ausgangslage ist und wie die Zielumgebung mal aussehen soll. Weiterhin zeige ich Stolpersteine im Entra Connect Rules Editor auf und berichte von meinen Erfahrungen.

Die Ausgangsituation (Ist-Zustand):

Ist Zustand Multi Forest

Hier sieht man gut wie der aktuelle Stand der Umgebung ist. Wir haben einen, bzw. sogar mehrere Forest’s. Der Forest A ist der Primär-Forest mit der Domäne cloud.local . In diesem „Ressource-Forest“ ist auch das Exchange Schema und dort werden die Postfächer für die primäre Empfängerdomäne „cloudcoop.de“ Bereitgestellt.

Hier ist eine Exchange Hybrid Umgebung konfiguriert und die Identitäten werden in den Microsoft Tenant Synchronisiert!

Der Forest B mit der Domäne sichel.local stellt die Benutzer des „Account-Forest“ bereit. Die Benutzer haben jedoch in beiden Umgebungen einen aktiviertes Benutzerobjekt. Dies ist wichtig zu wissen, denn wir haben keine Vertrauensstellung und somit auch keine Linked-Mailboxen. Sprich das AD-Objekt in der Domäne cloud.local wird aktiv für die Anmeldung auf dem Postfach verwendet.

Weiterhin werden im Forest A auch noch weitere Zentrale Dienste bereitgestellt an denen sich der Benutzer mit der Identität aus der cloud.local anmeldet.

Der Benutzer aus der sichel.local Domäne verwendet jedoch eben diese Identität um sich an seinem Arbeitsplatz zu authentifizieren. Der Zugriff auf sein Postfach erfolgt mit dem Benutzernamen und Kennwort aus der cloud.local –> Eine schlagendes Herz und zwei Identitäten sorgt zum Teil für Verwirrung bei den Benutzern, verständlich!

Einige Benutzer aus der cloud.local Domäne verwenden jedoch berits Cloud-Dienste wie Planner, Teams oder schlichtweg Apps for Enterprise. Auch hier muss der Benutzer sich mit seiner  cloud.local Identität am Entra authentifizieren, häufig passiert es jedoch dass Benutzer Anmeldedaten aus der sichel.local verwenden.

Es ist wichtig die Ausgangslage zu verstehen und welche Herausforderungen mit dieser einhergehen um das Zielbild zu erstellen.

Wichtig: Jeglicher Art einer AD-Vertrauensstellung ist weder gewünscht noch möglich!  Der Entra-Connect Server muss jedoch Netzwerkzugriffe zu den anderen Forest DCs haben! 

Die Zielumgebung (Soll-Zustand):

Ich zeige euch mal den geplanten Soll-Aufbau der Umgebung.

Domänenbenutzer der sichel.local sollen auf die dann migrierte Exchange Online Postfächer der Primären Empfängerdomäne cloudcoop.de zugreifen sollen.

Selbstredend sollen sich die Benutzer im Entra ID bzw. im Cloud-Stack mit ihrer Identität der sichel.local Domäne anmelden, und eben nicht mehr mit der Identität der cloud.local Domäne.

Weiterhin ist das Postfach quasi von der einen Identität auf die andere Identität übertragen worden. Jedoch ist im Forest B weiterhin kein Exchange Server installiert, somit auch kein Exchange Schema.

Weiterhin ist zu sehen das der Entra-Connect Service nicht mehr da steht wo er vorher mal stand, rein weg jedoch nur zur Verdeutlichung. Verortet ist dieser noch auf dem Member-Server im Forest A, jedoch steht dieser in einem anderen VLAN um von dort alle anderen Forest’s zu erreichen. Ich zeige hier das Bild mit Forest A & B auf. In der Kundenstruktur gibt es jedoch noch weitere Forest C & D! Hier ist das Ziel jedoch identisch.

Zudem ist ein Umzug des AAD-Connect-Server unausweichlich, später dazu mehr!

Ich zeige euch bewusst die Zielumgebung um euch gleich den Weg dorthin aufzeigen zu können. Der Grund dafür ist logisch, zum einem wollen wir den Benutzern die Anmeldung erleichtern um Zugriff auf Clouddienste zu erhalten. Zum anderen ist der Aufbau eines ZeroTrust Ansatzes ohne das Gerät nicht machbar. Die Geräte sollen im Intune HybridJoined sein und die Benutzer sich auf den Geräten mit der Hybriden Identität authentifizieren.

Aufbau Multi Forest Entra Connect Umgebung

Für den Aufbau der Umgebung ist es entscheidend das Konzept von Entra Connect zu verstehen und auch zu wissen wo die grenzen sind. Ich möchte hier jetzt nicht ins Detail darauf eingehen, daher lest gerne den Blog Artikel von Frank (ADSync – Topologien) oder schaut auf der Microsoft ( Microsoft Entra Connect: Unterstützte Topologien – Microsoft Entra ID | Microsoft Learn)Seite nach.

Da wir nun wissen, es gibt nur einen AD-Sync Server müssen wir demnach die einzelnen Forest über einen AD-Connect Server zum Ziel-Tenant verknüpfen.

Microsoft Entra Connect installieren

Ist die vorhanden Installation jedoch niemals darauf vorbereitet worden, steht im falschen Netz oder oder existiert nicht muss Entra Connect neu installiert werden. Hierbei ist zwingend darauf zu achten welche einmalige Option ausgewählt wird. Dies kann im nachhinein nicht mehr geändert werden.

Wenn Ihr Entra Connect Sync aus dem Tenent heruntergeladen habt (nicht mehr im Microsoft Downloadcenter verfügbar) und die Installation startet könntet ihr eure vorhanden Settings importieren. Hiervon würde ich jedoch absehen, da gerade bei dem Multi Forest Aufbau keine vorhanden Regeln mitkommen sollten (darauf gehe ich hier im Artikel nicht ein).

• Schaut euch euren vorhanden Sync-Service an
• Exportiert vorhanden Customized rules
• Prüft vorher die Settings welche gemacht wurden

Wichtig: Bei der Installation unbedingt die Benutzerdefinierten Einstellungen verwenden: 

Bei der Installation müsst ihr nun die erste Domäne angeben welche hinzugefügt werden soll. Ihr könnt auch schon mehrerer hinzufügen. Dazu gleich mehr!
Der wichtigste Punkt ist der beim Abschnitt „Uniquely identifying you users“:

Entra Connect sieht hier bereist den von mir beschriebenen Zustand vor, sicherlich geht Microsoft hier von einer Vertrauensstellung aus und das es einen echten Ressourcen und Account Forest gibt. Dennoch kann ich mir an der Stelle Entra Connect zur Hilfe nehmen um meinen Soll-Zustand zu erreichen.

Weiterhin lasse ich Azure entscheiden welches Attribut als „source anchor“ dient. Dies ist Entscheidender Punkt, da ich später den Anchor in allen Umgebungen identisch haben muss. Du kannst hier auch auf ein anderes Attribut setzen.

Sollte deine vorhanden Umgebung jedoch, auf ein anderen „source anchor“ setzen, prüfe dies bitte in deiner vorhanden Installation.

Da ich die anderen Forest erst im zweiten Schritt hinzugefügt habe, und die Konfiguration jetzt passt, kann diese abgeschlossen werden.

Umgang mit Identitäten in einer Multi Forest Umgebung

Beim aufrühren des Entra Connect Agent für das zweite mal, habe ich sichergestellt dass:

• Alle Domänen / Forest erreichbar sind
  • Firewall Regeln für LDAP, DNS, GC, Kerberos
• Anmeldedaten vorhanden sind:
  • Ich habe zuvor einen AAD-Connect Service Benutzer erstellt
  • Dieses Konto im Ziel AD Berechtigt Microsoft Entra Connect: Configure AD DS Connector Account Permissions – Microsoft Entra ID | Microsoft Learn
  • Ich habe ein PS-Script erstellt um auf den Domänen von Forest B / C /D usw. die Berechtigungen zu erhalten die Kennwortreplikation auszulesen –> Entscheidend! ( Findet ihr hier –> public/ActiveDirectory/Set-SyncServiceAccounttoReplication.ps1 at main · cloudcoopgmbh/public )
• Identitäten sich gleichen:
  • Die im Tenant hinterlegten Domänen sind auch die Suffixe im AD (@cloudcoop.de)
  • Jeder im Sync-Scope befindliche Benutzer hat einen korrekten UPN
  • Das Mail-Attribut ist gepflegt und gesetzt!!!!
  • E-Mail ist = UPN (Muss nicht aber du musst genau schauen welches Attribut deinen Entra Usernamen bildet, UPN ist der Standard)

Ich habe zuvor die Suffxe welche ich benötige hinzugefügt und dafür gesorgt dass in jedem Fall das Attribut „mail“ gesetzt ist. Daraus habe ich anschließend den UPN gebildet.

Hinzufügen eines weiteren Forest zu Entra Connect

Beim Hinzufügen der Domäne müssen die Berechtigungen des Accounts angegeben werden. In meinem Fall heißt die Domäne sichel.cloud und der Service Benutzer svc.AADC-SI. 

Wichtig ist die vollständige Angabe des Forest, wenn du beispielsweise intern.cloudcoop.de verwendets, muss dies auch so angeben werden.

Du kannst anschließend deine OUs auswählen welche für den Sync interessant sind und deine Objekte werden Synchronisiert! Achtung! Lies wirklich was du vorher tun solltest!

Dieser teil ist zunächst unspektakulär, entscheidend ist was nun mit den Identitäten passiert. Dies schauen wir uns jetzt an.

Abgleich der Identitäten

Wenn die Konfigurationen wie oben erfolgt muss man nun wissen wir Entra Connect arbeitet. Oben habe ich erwähnt welches Kennwort für den Benutzer verantwortlich ist. Werfen wir ein Blick auf die Tabelle:

Hier ist klar zu erkennen das beide Accounts aus beiden Domänen ein aktiviertes Kennwort haben. Nun ist wichtig zu verstehen was Entra Connect daraus macht. Werfen wir einen Blick auf die Sync-Rules:

Insgesamt habe ich vier Forest Connectoren für Account Enabled. Für Entra ID gilt derjenige mit der niedrigsten Precedence für das Kennwort bzw. den Anchor in der Cloud. Da es sich hierbei jedoch um System-Regeln handelt können wir diese nicht bearbeiten.

Grundsätzlich lassen sich Systemregeln bearbeiten, indem davon Kopien erstellt werden. Dies hat jedoch keinen Einfluss auf das Objekt welches im Entra ID für die Kennwortvergabe zuständig ist.

Schauen wir mal auf das Objekt im Metaverse als auch im Entra ID:

Dabei fällt auf:

• Der User wird aus mehreren Connectoren sychronisiert
•  Damit war das Matching, wie vorgestellt, erfolgreich
• Das „cloudSourceAnchor“ Attribut simmt mit dem in Entra ID überein
• In Entra ID werden die Informationen beider Objekte zusammengefasst
• Der User hat ProxyAdressen
• Im Entra ID ist die Primäre Quelle die Domäne cloud.local – also mein Forest A
• Die Sync Rule welches das Attribut „accountEnabled“ definiert stammt aus Forest A

Somit gilt. Die Anmeldung am Entra ID wird mit den Daten des Users aus dem Forest A ausgeübt!

Noch ein Blick auf das AD-Objekt in beiden Forest. Dafür habe ich mir ein PowerShellScript erstellt. das findet ihr ebenfalls hier  (public/ActiveDirectory/Test-ConsistencyGuidParity.ps1 at main · cloudcoopgmbh/public)–> um über den UPN den SourceAnchor  (mS-DS-ConsistencyGuid) abzugleichen

Exchange Online Migration

Ich habe nun aus zwei AD-Objekten ein Cloud Objekt erstellt. Das Matching hat funktioniert, doch wie soll es nun weitergehen um das Ziel zu erreichen?

1. Migration des Postfach zu Exchange Online
2. Userobjekt erhält über AD-Gruppe in Forest B seine Zuordnung zu der Lizenz
3. Nachdem die Migration abgeschlossen ist, wird das Objekt zur RemoteMailbox in Forest A

Ändern der primären Authorität in Entra ID

Wow, ein harter Weg bis hierhin. Doch was nun?

Die Herausforderung in diesem Fall. ich darf das AD-Objekt nicht deaktivieren da noch andere Zentrale Drittanbieter-Services daran hängen. Sprich dies kam leider nicht in Frage.

Wir wir vorhin gelernt haben ist die Änderung der Systemregeln weniger sinnvoll. Dies bringt uns demnach nicht an das Ziel. Mein nächster Gedanke war naheliegend „CloudFilterd“. Doch das war der entscheidende Moment um mich nochmals damit auseinanderzusetzen.

Ich habe auf dem Objekt ein Attribut gesetzt und eine Sync-Regel erstellt um aufgrund der Regel das Objekt auszuklammern:

Bis zu dem Moment konnte der User noch mit seinen Anmeldedaten im Entra ID auf die Mailbox zugreifen. Maßgeblich waren immer noch die Daten aus Forest A. Jetzt hat das Attribut zugeschlagen.

Dieses verhalten kam jedoch Unerwartet, da die Filterung ja nur auf dem Connector ausgeführt wird. Nu gut. Regel deaktiviert. Sync gestartet, Mailbox, Objekt usw wieder vorhanden! Doch was nun?

Durch das entfernen des Objektes bekommt es aus dem Connectorspace ein „delete“. Somit ist die Zuordnung nur noch durch einen anderen Connector möglich. Sämtliche Exchange Attribute blieben vorhanden und de2r Anchor wird auf das Objekt aus Forest B verlagert. Ab dem Moment meldet sich der User mit seinem Kennwort aus Forest B an. Dadurch das es in Forest A nicht gelöscht ist bleibt auch das Exchange-Routing vorhanden und der User kann wie gewohnt per Mail erreicht werden.

Wenn in EXO die Attribute noch geändert werden sollen musst noch „t isExchangeCloudManaged=true“ konfiguriert werden (Wieder zu Frank: IsExchangeCloudManaged)

Wenn dieses Verhalten, jetzt auch für euch, bekannt ist, Hilft es ggf. bei komplexeren Migrationen zu Planen und somit aus mehr eins zu machen :) !