AADSync - lokale Gruppen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • 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.

    Maier schrieb:

    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.
    Grüße aus Berlin schickt Robert
  • 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
  • RobertW schrieb:

    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.

    Maier schrieb:

    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.



    Jetzt denke ich wird es mir klar :)
    Danke für die ausführliche beschreibung!
    Nun heißt es konfigurieren + testen.