AADC im Multi Namespace Forest

emeriks
Goto Top
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.

Content-Key: 2112863930

Url: https://administrator.de/contentid/2112863930

Ausgedruckt am: 29.06.2022 um 09:06 Uhr

Mitglied: 7Gizmo7
Lösung 7Gizmo7 11.03.2022 um 13:32:40 Uhr
Goto Top
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
Mitglied: emeriks
emeriks 11.03.2022 um 13:37:51 Uhr
Goto Top
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.

Nein. Nur ein Forest.
Mitglied: emeriks
emeriks 11.03.2022 aktualisiert um 13:45:22 Uhr
Goto Top
aadc
Mitglied: 7Gizmo7
7Gizmo7 11.03.2022 um 14:39:50 Uhr
Goto Top
Mhm, also ein Forest mit zwei Gesamtstrukturen und Relationship.
forest-trust-relationship-v0.1a
11.
Mitglied: 7Gizmo7
7Gizmo7 11.03.2022 aktualisiert um 14:48:27 Uhr
Goto Top
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 ...
Mitglied: emeriks
emeriks 11.03.2022 aktualisiert um 14:56:19 Uhr
Goto Top
Nein!
Ein Forest mit mehreren Namespaces.
Da sind alle Trees automatisch im Trust.
Mitglied: 7Gizmo7
7Gizmo7 11.03.2022 um 14:57:43 Uhr
Goto Top
Hi,

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

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

Mit freundlichen Grüßen
Mitglied: emeriks
emeriks 11.03.2022 um 14:57:52 Uhr
Goto Top
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.
Mitglied: 7Gizmo7
7Gizmo7 11.03.2022 um 15:00:57 Uhr
Goto Top
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
Mitglied: emeriks
emeriks 11.03.2022 um 15:01:18 Uhr
Goto Top
Mitglied: 7Gizmo7
7Gizmo7 11.03.2022 um 15:02:06 Uhr
Goto Top
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 ?
Mitglied: emeriks
emeriks 11.03.2022 um 15:03:07 Uhr
Goto Top
Zitat von @7Gizmo7:
Ich will mich nicht streiten, Ports und Powershell wäre interessant.
Ich weiß Deine Unterstützungsansätze zu schätzen. Danke.
Mitglied: emeriks
emeriks 11.03.2022 um 15:05:14 Uhr
Goto Top
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.
Mitglied: 7Gizmo7
7Gizmo7 11.03.2022 aktualisiert um 15:07:00 Uhr
Goto Top
Zitat von @emeriks:

<code>
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.
Mitglied: emeriks
emeriks 11.03.2022 um 15:06:05 Uhr
Goto Top
Mhm , müsste das ADDS Konto nicht aus der Domäne userdom.rootdom.tld1\azure.service sein ?
Wieso?
Mitglied: 7Gizmo7
7Gizmo7 11.03.2022 aktualisiert um 15:10:29 Uhr
Goto Top
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
Mitglied: emeriks
emeriks 11.03.2022 um 15:11:34 Uhr
Goto Top
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.
Mitglied: 7Gizmo7
7Gizmo7 11.03.2022 aktualisiert um 15:27:40 Uhr
Goto Top
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 ?
bildschirmfoto 2022-03-11 um 15.24.13
Mitglied: emeriks
emeriks 11.03.2022 aktualisiert um 16:27:52 Uhr
Goto Top
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".
Mitglied: 7Gizmo7
7Gizmo7 11.03.2022 aktualisiert um 18:27:53 Uhr
Goto Top
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
Mitglied: emeriks
emeriks 14.03.2022 um 09:40:00 Uhr
Goto Top
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.
Mitglied: emeriks
emeriks 14.03.2022 aktualisiert um 12:18:15 Uhr
Goto Top
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!
Mitglied: 7Gizmo7
7Gizmo7 14.03.2022 um 20:44:05 Uhr
Goto Top
Zitat von @emeriks:

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

Büdde
Mitglied: rzlbrnft
rzlbrnft 19.03.2022 um 17:02:01 Uhr
Goto Top
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 ...