Ja, du mußt eben einen Filter bauen, der dir genau die User synct, die diesem Filter entsprechen. Statt Attributen könnte man sicher auch mittels Gruppenmitgliedschaften filtern afair. Aber ist schon eine Weile her, dass ich mich damit befaßt habe.
AADSync - lokale Gruppen
- Maier
- Thread is marked as Resolved.
-
-
Kleine technische Erklärung: Das Sync-Tool ist befindet quasi in der MItte zwischen dem AD und AAD. Es synct nicht direkt, sondern führt eine eigene Datenbank über alle Synch-Datensätze aus dem AD. In die Datenbank gibt es "Inbound" Rules, aus der Datenbank gibt es "Outbound" Rules. Das ist für das Verständnis wichtig, den sonst denkt man auf den ersten Blick, dass "Inbound" und "Outbound" für die Synchronisation zwischen AD und AAD steht. In Wirklichkeit gibt es aber Inbound-Regeln für AD -> DB (Standardname "in from AD....") und für AAD -> DB (Standardname "in from AAD....").
Damit ist aber noch keine Snychronisation passiert, es wird nur die Datenbank in der Mitte gefüllt. Für die Synchronisation aus der Datenbank gibt es dann die Outbound-Regeln, auch wieder für beide Richtungen: DB -> AAD und DB -> AD. Die Standardnamen sind dann hier "Out to AAD...." und "Out to AD....".
Falls Du in der Programmierung unterwegs bist, das ist nichts anderes als ein ETL Prozess und AAD Sync technisch nichts anderes als ein Software-Integrations-Werkzeug.
Muss dies evtl. im Synchronization Rules Editor eingestellt werden?
Korrekt.
Inbound Rule
Connected System -> Dein AD
Connected System Object Type -> user
Metaverse Object Type -> person
Link Type -> Join
Precedence -> eine Zahl höher als die höchste Regel (bei uns ist die angepassten Regeln im 5xx Bereich)Beim Scripting Filter muss man Microsoft-Typisch in einer "Verneinung" denken, das liegt an der Transformation-Rule. Bei uns steht da drin:
"extensionAttribute14" "NOTEQUAL" "Office365"Join Rules -> leer
Transformations -> "Constant" "cloudFiltered" "True" "Updates"
Durch diese Einstellung werden zwar alle User in die Sync-Datenbank kopiert, aber es wird das Attribute "cloudFiltered" bei allen gesetzt, die kein Office 365 bekommen sollen (bei uns im Extension Attribute 14 markiert). Daher auch die "Verneinung" oben.
Passend dazu gibt eine Standard-Regel "Outbound" mit dem Namen "Out to AAD - User Join". In dieser Regel gibt es einen "Scoping Filter" mit dem Namen "cloudFiltered" "NOTEQUAL" "True". Dieser Filter sorgt dafür, dass nur User ohne das Attribute "cloudFiltered" synchronisiert werden.
-
Statt Attributen könnte man sicher auch mittels Gruppenmitgliedschaften filtern afair.
Zumindest nicht so, wie ich es beschrieben habe. Das Attribute "memberOf" kann man im Scoping Filter nicht auswählen.
-
Man kann aber afair den Sync anhand einer Gruppe durchführen. Also alle Mitglieder einer Gruppe werden gesynct. WIe gesagt, das war vor einigen Monaten, und da funktionierte das in meinem Fall nicht so wirklich sinnvoll deswegen habe ich das dann in meinem Fall mittels OU Struktur geregelt, weil es hier designtechnisch ganz gut abzubilden war. Deine Lösung ist natürlich deutlich flexibler.
Bye
Norbert -
Kleine technische Erklärung: Das Sync-Tool ist befindet quasi in der MItte zwischen dem AD und AAD. Es synct nicht direkt, sondern führt eine eigene Datenbank über alle Synch-Datensätze aus dem AD. In die Datenbank gibt es "Inbound" Rules, aus der Datenbank gibt es "Outbound" Rules. Das ist für das Verständnis wichtig, den sonst denkt man auf den ersten Blick, dass "Inbound" und "Outbound" für die Synchronisation zwischen AD und AAD steht. In Wirklichkeit gibt es aber Inbound-Regeln für AD -> DB (Standardname "in from AD....") und für AAD -> DB (Standardname "in from AAD....").
Damit ist aber noch keine Snychronisation passiert, es wird nur die Datenbank in der Mitte gefüllt. Für die Synchronisation aus der Datenbank gibt es dann die Outbound-Regeln, auch wieder für beide Richtungen: DB -> AAD und DB -> AD. Die Standardnamen sind dann hier "Out to AAD...." und "Out to AD....".
Falls Du in der Programmierung unterwegs bist, das ist nichts anderes als ein ETL Prozess und AAD Sync technisch nichts anderes als ein Software-Integrations-Werkzeug.
Korrekt.Inbound Rule
Connected System -> Dein AD
Connected System Object Type -> user
Metaverse Object Type -> person
Link Type -> Join
Precedence -> eine Zahl höher als die höchste Regel (bei uns ist die angepassten Regeln im 5xx Bereich)Beim Scripting Filter muss man Microsoft-Typisch in einer "Verneinung" denken, das liegt an der Transformation-Rule. Bei uns steht da drin:
"extensionAttribute14" "NOTEQUAL" "Office365"Join Rules -> leer
Transformations -> "Constant" "cloudFiltered" "True" "Updates"
Durch diese Einstellung werden zwar alle User in die Sync-Datenbank kopiert, aber es wird das Attribute "cloudFiltered" bei allen gesetzt, die kein Office 365 bekommen sollen (bei uns im Extension Attribute 14 markiert). Daher auch die "Verneinung" oben.
Passend dazu gibt eine Standard-Regel "Outbound" mit dem Namen "Out to AAD - User Join". In dieser Regel gibt es einen "Scoping Filter" mit dem Namen "cloudFiltered" "NOTEQUAL" "True". Dieser Filter sorgt dafür, dass nur User ohne das Attribute "cloudFiltered" synchronisiert werden.
Jetzt denke ich wird es mir klar
Danke für die ausführliche beschreibung!
Nun heißt es konfigurieren + testen.