10.03.2022, aktualisiert um 17:26:10 Uhr

1869

AADC im Multi Namespace Forest

Hi,
hat jemand von Euch schon einmal erfolgreich ein AADC eingerichtet, wo folgende Bedingungen zutreffen:

Das lokale AD besteht aus einem Forest mit mehreren Domains in mehreren Namespaces.
Es sollen nur die Konten ab einer bestimmten OU aus nur einer der Subdomains synchronisiert werden.
Das AD-Konto für die Verbindung zum lokalen AD befindet sich in einer anderen Domain (nicht die Root Domain), in einen anderen Namespace, als die Domain, in welcher sich die zu synchronisierende OU befindet.

Bsp:

Forest "rootdom.tld1"
User-Domain "userdom.rootdom.tld1" (mit der o.g. OU)
Admin-User-Domain "admindom.tld2" (mit welchem konfiguriert wird, Konto ist Enterprise Admin)
AD-Konto für Sync in "admindom.tld2"

Wir bekommen den Abgleich nicht zum Laufen. Er importiert nichts ins Metaverse. Meckert aber auch nicht, dass er irgendwo keine Rechte hätte oder irgendwas nicht erreichen könnte.

Dabei sind uns dann noch eine Menge Bugs über die Füße gelaufen. z.B.

Wenn man mit dem "Azure AD Connect" Wizard das Konto für den AD-Zugriff automatisch erstellen lässt ("MSOL_....."), dann legt er dieses einfach in der Domain des ausführenden Admin-Kontos an. Man wird nicht gefragt, in welcher Domain er dieses anlegen soll.
Wenn man das Konto manuell erstellt, und dann die Berechtigungen dafür mit den mitgelieferten CMDlets erteilen will (Set-ADSyncMsDsConsistencyGuidPermissions, usw.), selektiv nur für die User-Domain und die dort gelegene OU, dann funktioniert das nur, wenn der Computer, auf welchem man dieses CMDlet ausführt, in einer Domain im Namespace der User-Domain ist.
Wenn man alle Berechtigungen für dieses Konto aus dem AD wieder entfernt, dann meckert der Sync Dienst das noch nicht mal an. Das lässt uns schlussfolgern, dass er beim Filtern der zu synchronisierenden Objekte schon nichts findet. Die speziellen Rechte also (noch) gar nicht braucht.

Wir haben es sowohl mit eigenen Regeln versucht, als auch nur mit den Standard-Regeln.

Im Moment stehen wir voll auf dem Schlauch.

E.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 2112863930

Url: https://administrator.de/forum/aadc-im-multi-namespace-forest-2112863930.html

Ausgedruckt am: 11.04.2025 um 01:04 Uhr

24 Kommentare

Neuester Kommentar

Hi,

also es eigentlich ein unterstützes Szenario . Ich nehme mal an rootdom.tld1 und admindom.tld2 haben eine Vertrauensstellung ?

Ich würde es so machen.

Managed Service Account (gMSA) für Sync Service in admindom.tld2
AD-Account in userdom.rootdom.tld1 anlegen und mal volle Rechte auf OU für Benutzer delegieren.
Prüfen ob aus admindom.tld2 mit dem AD-Account auf die Benutzer-Objekte zugegriffen werden kann.

Dann alles manuell in AAD-Connect konfigurieren.

Ich glaube das ist ja dein Szenario.
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/plan-conn ...

Mit freundlichen Grüßen

Zitat von @7Gizmo7:
also es eigentlich ein unterstützes Szenario . Ich nehme mal an rootdom.tld1 und admindom.tld2 haben eine Vertrauensstellung ?

Sie sind im selben Forest.

Managed Service Account (gMSA) für Sync Service in admindom.tld2
AD-Account in userdom.rootdom.tld1 anlegen und mal volle Rechte auf OU für Benutzer delegieren.
Prüfen ob aus admindom.tld2 mit dem AD-Account auf die Benutzer-Objekte zugegriffen werden kann.

Genau das haben wir auch schon probiert. Es ändert leider nichts.

Ich glaube das ist ja dein Szenario.
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/plan-conn ...

Nein. Nur ein Forest.

Mhm, also ein Forest mit zwei Gesamtstrukturen und Relationship.

AD-Anbindung ist grün und OU werden auch angezeigt ?

Ports zur AD alle geöffnet ?
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/reference ...

Nein!
Ein Forest mit mehreren Namespaces.
Da sind alle Trees automatisch im Trust.

Hi,

kannst du mal vom AAD_Connect Server die Powershell ausführen.

Show-ADSyncADObjectPermissions -ADobjectDN '<DistinguishedName>' aus userdom.rootdom.tld1 ?

Mit freundlichen Grüßen

Zitat von @7Gizmo7:
Ports zur AD alle geöffnet ?

Soweit sind wir noch gar nicht. Erstmal müssen wir ihn doch dazu bekommen, die Objekte ins Metaverse zu importieren.
AADC und DC's sind im selben Subnet, ohne FW dazwischen.

Zitat von @emeriks:

Nein!
Ein Forest mit mehreren Namespaces.
Das sind alle Trees automatisch im Trust.

Ich will mich nicht streiten, Ports und Powershell wäre interessant.

Mit freundlichen Grüßen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Vererbt auf contact
Zulassen   ADMINDOM\azure.service        Beschränkter Zugriff
                                           WRITE PROPERTY
                                           READ PROPERTY
Vererbt auf user
Zulassen   ADMINDOM\azure.service        Beschränkter Zugriff
                                           WRITE PROPERTY
                                           READ PROPERTY
Vererbt auf group
Zulassen   ADMINDOM\azure.service        Beschränkter Zugriff
                                           WRITE PROPERTY
                                           READ PROPERTY
Vererbt auf inetOrgPerson
Zulassen   ADMINDOM\azure.service        Beschränkter Zugriff
                                           WRITE PROPERTY
                                           READ PROPERTY
Vererbt auf contact
Zulassen   ADMINDOM\azure.service        Beschränkter Zugriff
                                           READ PROPERTY
Vererbt auf user
Zulassen   ADMINDOM\azure.service        Beschränkter Zugriff
                                           READ PROPERTY
Vererbt auf group
Zulassen   ADMINDOM\azure.service        Beschränkter Zugriff
                                           READ PROPERTY
Vererbt auf device
Zulassen   ADMINDOM\azure.service        Beschränkter Zugriff
                                           READ PROPERTY
Vererbt auf computer
Zulassen   ADMINDOM\azure.service        Beschränkter Zugriff
                                           READ PROPERTY
Vererbt auf inetOrgPerson
Zulassen   ADMINDOM\azure.service        Beschränkter Zugriff
                                           READ PROPERTY
Vererbt auf foreignSecurityPrincipal
Zulassen   ADMINDOM\azure.service        Beschränkter Zugriff
                                           READ PROPERTY
Vererbt auf user
Zulassen   ADMINDOM\azure.service        Beschränkter Zugriff für mS-DS-ConsistencyGuid
                                           WRITE PROPERTY
                                           READ PROPERTY
Vererbt auf group
Zulassen   ADMINDOM\azure.service        Beschränkter Zugriff für mS-DS-ConsistencyGuid
                                           WRITE PROPERTY
                                           READ PROPERTY

Zitat von @emeriks:

Zitat von @7Gizmo7:
Ports zur AD alle geöffnet ?

Soweit sind wir noch gar nicht. Erstmal müssen wir ihn doch dazu bekommen, die Objekte ins Metaverse zu importieren.
AADC und DC's sind im selben Subnet, ohne FW dazwischen.

Okay und mit Test-Netconnection geprüft ?

Zitat von @7Gizmo7:
Ich will mich nicht streiten, Ports und Powershell wäre interessant.

Ich weiß Deine Unterstützungsansätze zu schätzen. Danke.

Okay und mit Test-Netconnection geprüft ?

Der AADC kann voll auf das AD zugreifen. Er zeigt mir alles mögliche an. Alle OU, alle Objekte. usw.

Vor ein paar Minuten hat er mir sogar gemeldet, dass er in der OU eine neue Gruppe zum Synchronisieren gefunden hätte. Die Benutzer immer noch nicht. Und die Gruppe ist auch nicht im AAD angekommen.

Zitat von @emeriks:

Vererbt auf contact
Zulassen ADMINDOM\azure.service Beschränkter Zugriff
WRITE PROPERTY
READ PROPERTY

Mhm , müsste das ADDS Konto nicht aus der Domäne userdom.rootdom.tld1\azure.service sein ?

Bitte mal ein Konto aus der Domain userdom.rootdom.tld1 für den AD-DS-Connector verwenden.

Mhm , müsste das ADDS Konto nicht aus der Domäne userdom.rootdom.tld1\azure.service sein ?

Wieso?

Zitat von @emeriks:

Mhm , müsste das ADDS Konto nicht aus der Domäne userdom.rootdom.tld1\azure.service sein ?

Wieso?

Weil da der globale Katalog auch ist. Das AD-DS Connector Konto sollte auch aus der Domain sein. Unabhängig von Trust .etc wahrscheinlich geht auch ein Konto aus rootdom.tld1

Der GC ist überall. Alle DC's sind bei uns auch GC.
Außerdem ist userdom.rootdom.tld1 ja nicht die Root Domain, falls Du das meinen solltest.

Zitat von @emeriks:

Der GC ist überall. Alle DC's sind bei uns auch GC.
Außerdem ist userdom.rootdom.tld1 ja nicht die Root Domain, falls Du das meinen solltest.

Auch da möchte ich mich nicht streiten, ich würde es mit einem Account aus der userdom.rootdom.tld1 testen.

Wenn du im AD DS Connector Space Search einen DN suchst wird nichts gefunden ?

Zitat von @7Gizmo7:
Auch da möchte ich mich nicht streiten, ich würde es mit einem Account aus der userdom.rootdom.tld1 testen.

Das haben wir auch schon. Wir haben sogar den AADC-Server in diese Domäne verfrachtet. Es ändert leider nichts.

Wenn du im AD DS Connector Space Search einen DN suchst wird nichts gefunden ?

Doch.

Und wie gesagt: Alles noch mit den Standard-Regeln.

Edit:
Bei Gruppen steht "object type group" und "connector true".
Bei Benutzer steht "object type placeholder" (?) und "connector false".

Zitat von @emeriks:

Edit:
Bei Gruppen steht "object type group" und "connector true".
Bei Benutzer steht "object type placeholder" (?) und "connector false".

Mhm,

https://docs.microsoft.com/de-de/azure/active-directory/hybrid/concept-a ...

https://www.hayesjupe.com/azure-ad-sync-objects-not-syncing-specifically ...

https://social.technet.microsoft.com/Forums/en-US/3f2763b1-7057-4096-ae9 ...

Also unter Operations steht auch nichts , kein Add , kein Update beim Export. Was ist denn dein eindeutiger Identifer zu Azure AD oder soll der Account neu erstellt werden ?

Mit freundlichen Grüßen

Danke.
Ich hatte schon bei MS über diese "placeholder" gelesen, aber irgendwie nicht ganz aufgenommen. Ein WE drüber geschlafen ...

Klar. Der Benutzer (jetzt zwei, habe noch einen erstellt, abenfalls mit Postfach) erscheint als Platzhalter, weil er in der Gruppe als Mitglied steht, aber als Benutzer selbst nicht gefunden wird. Sobald ich die Benutzer aus der Gruppe entferne und einen Delta-Abgleich fahre, erscheinen sie bei "Search Connector Space" auch nicht mehr als "placeholder". Sie erscheinen gar nicht mehr.

Aus irgendeinem unerfindlichen Grund filtert der AADC bei uns die Benutzerobjekt komplett raus. Wohl gemerkt: Nur mit Standard-Regeln.

Wir haben es nun so gelöst bekommen, dass wir den AADC noch einmal neu installiert haben. Seit dem funktioniert es.

@7Gizmo7
Danke für Deine Unterstützung!

Zitat von @emeriks:

@7Gizmo7
Danke für Deine Unterstützung!

Büdde

Zitat von @emeriks:

Wir haben es nun so gelöst bekommen, dass wir den AADC noch einmal neu installiert haben. Seit dem funktioniert es.

@7Gizmo7
Danke für Deine Unterstützung!

Falls dir das nochmal passiert, bei uns war das Problem das der Sync User mit in die MFA Registration Campaign gerutscht ist, und von Azure dann MFA gefordert wurde, was bei einem Dienstkonto ja nicht funktionieren kann.
Bei der Neuinstallation wird dieses Konto normalerweise mit einem Flag versehen, das es aus der MFA ausschließt.

https://docs.microsoft.com/en-us/azure/active-directory/authentication/h ...

gelöst Frage Microsoft Windows Server

Mehr von emeriks

SharePoint Online - Recht zum Erstellen von Sitesemeriks - 6 Kommentare

VS Code Fehler mit Klassenemeriks - 6 Kommentare

Erfahrungen mit Copilot PC mit Snapdragonemeriks - 2 Kommentare

Trouble mit Lizenzen für MS Teamsemeriks - 2 Kommentare

Heiß diskutiert