MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

ADSync und CloudFiltered

Diese Seite beschäftigt sich mit dem besonderen Attribut "CloudFiltered" im Entra ID Metaverse, welches steuert, ob ein Objekt aus dem Metaverse ins Entra ID repliziert wird und was hier alles schief gehen kann

Filtern von Objekten

Es ist der Regelfall, dass eine Firma nicht komplett alle lokalen AD-Objekte mittels Verzeichnisabgleich in das Entra ID-Verzeichnis replizieren will. Dazu sieht Microsoft drei Optionen vor, die ich auf ADSync Filterung auch ausführlicher beschrieben habe. In der Kurzfassung:

  • Filtern über Gruppe
    Dieser Filter eignet sich am Anfang, um Pilotobjekte mittels Mitgliedschaft in einer Gruppe zu replizieren. Dieser Filter kann nur bei der Installation von Entra ID Connect konfiguriert werden.
  • Filtern über OUs
    Das machen dann die meisten Firmen, bei denen die AD-Objekte und die OU-Struktur für den Verzeichnisabgleich passend sind.
  • Filtern über ein LDAP-Feld
    Wer etwas flexibler sein will, sucht sich ein LDAP-Feld aus, welches als Filterkriterium über eine Anpassung der SyncRules genutzt wird. 

Zusätzlich hat Microsoft aber auch noch ein paar Ausschlusskriterien in den SynchRules eingebaut, auf die wir noch eingehen.

DirSync Basics

Auf weiteren Seiten wie  ADSync Funktionsweise habe ich schon unter die Motorhaube geschaut und daher belasse ich es hier bei einer Kurzfassung. Ein lokales AD-Objekt wird durch einen Inbound Connector gelesen und in den Connector-Space gepuffert. Beim Sync werden die Änderungen in das "Metaverse" und die ausgehenden Connectorspaces übertragen. Der Outbound-Connector schreibt die Änderungen aus seinem Connectorspace ins Ziel

Eine Filterung kann sowohl beim Import als auch beim Export erfolgen. Wobei das nicht ganz richtig ist, denn Der Import überträgt sehr viele Objekte in den Connectorspace und filtert erst eingehend Richtung Metaverse. Wer schon einmal in den Connectorspace geschaut hat, finden sogar OUs etc., für die es keine Regeln gibt. Eine besondere Funktion kommt hier dem Feld "cloudFiltered" zu.

Eingehend Synchronization Rules

Zuerst habe ich mir die eingehende Synchronisierungsregel mit einem Filter auf das "MV Attribut = cloudFilteres" und "Objecttype=person" genutzt. Ähnliche Regeln gibt es auch für Gruppen und Computer, aber es reicht ein Objekt verstanden zu haben

Die Regel mit der Precedence 100 hat schon einmal einen "Scoping Filter", der ein paar Objekte von vorneherein ausschließt. Alle Objekte, die im Active Directory als "CriticalSystemObjekt" gekennzeichnet sind oder deren AdminDescription mit "User_" beginnt, werden generell schon einmal ausgeschlossen.

Alle anderen Objekte werden, wenn es nicht noch andere Filter auf Gruppenmitgliedschaft, OU oder  LDAP-Feld gibt, importiert. Dabei werden die unter "Transformation" hinterlegten Felder verändert. Hier erscheint auch "cloud Filtered"

Der Wert von "cloudFiltered" im Metaverse wird anhand folgender Regel gebildet. Die Formel ähnelt einer Excel-Funktion mit der IF-Bedingung an erster Stelle und der Rückgabe für True oder False:

IIF(IsPresent([sAMAccountName]) = False 
              || Left([sAMAccountName], 7) = "krbtgt_" 
              || [sAMAccountName] = "SUPPORT_388945a0" 
              || Left([mailNickname], 14) = "SystemMailbox{" 
              || Left([sAMAccountName], 4) = "AAD_" 
              || (Left([mailNickname], 4) = "CAS_" && (InStr([mailNickname], "}") > 0)) 
              || (Left([sAMAccountName], 4) = "CAS_" && (InStr([sAMAccountName], "}") > 0))
              || Left([sAMAccountName], 5) = "MSOL_" 
              || CBool(IIF(IsPresent([msExchRecipientTypeDetails]),BitAnd([msExchRecipientTypeDetails],&H21C07000) > 0,NULL)) 
              || CBool(InStr(DNComponent(CRef([dn]),1),"\\0ACNF:")>0),
       True,
       NULL
)

Hier sehen wir sehr gut, dass  "cloudFiltered" auf True gesetzt wird, wenn es das Kerberos Konto, ein Exchange CAS-Konto, ein ADSync-Konto, eine Exchange Systemmailbox oder der Distinguishedname mit "\\0ACNF:" beginnt. In den meisten Fällen werden wir also Objekte im Metaverse haben, bei denen cloudFiltered auch True ist.

Beispiel: Scoping Filter

Ein gutes Element ist das KRBTGT-Konto, welches ein "criticalObject" ist und daher aufgrund des Scoping-Filters schon ausgeschossen wird. In meiner Testumgebung sehe ich, dass das Konto im Connectorspace aus dem lokalen AD landet.

 

Dabei werden folgende Eigenschaften des Objekts in den Connectorspace übertragen.

Allerdings sehen wir auch, dass auf der Karteikarte "lineage" keine Regel "Matched".

Entsprechend landet das Objekt gar nicht erst im Metaverse und das Feld "Cloud filtered" ist gar nicht erst relevant.

Beispiel CloudFiltered

Um mit "cloudFiltered" zu arbeiten, habe ich mit einen Benutzer angelegt, welcher den SamAccountName "AAD_CloudFiltered" bekommen hat. Beim nächsten Import aus dem lokalen AD wurde das Objekt über den Connectorspace in das MetaVerse übertragen. Die Eigenschaften zeigen hier schön, dass das Feld "cloudFiltered" auf True steht. 

Das war so auch erwartet. Die Transformation-Regel hat wie erwartet funktioniert.

Ausgehende Synchronization Rules

Das Feld "cloudFiltered" wird nicht nur für Benutzer und Kontakte genutzt. Auch hier zeigt der Rule Editor den Filter nur an, wenn man einen MV Object Type auswählt. Ich habe daher das folgende Bild zusammengesetzt:

Nur "Public Folder" werden nicht mit "cloudFiltered" benutzt. Das Feld "cloudFiltered" kommt bei den ausgehenden Regeln nicht in den "Transformations", sondern im "Scoping Filter" vor. HIer eine Regel für "person"-Objekte

 

Die Regel wird nur angewendet, wenn "cloudFiltered NOTEQUAL TRUE" ist. Das bedeutet aber auch, dass das Objekt nicht in Entra ID landet bzw. ein früher dorthin repliziertes Objekt dann natürlich auch gelöscht wird.

Falle Multi Forest

Im Grund ist das ja auch die Logik hinter "cloudFiltered". Aber in einer Diskussion mit Andres-Miguel Sichel (cloudcoop.de) haben wir einen Fall gefunden, der bei Migrationen vielleicht auftreten kann. Er hat sein Szenario hier beschrieben:

Wenn ADSync die Benutzer aus mehreren Forests liest und über ein Feld (msexchMasterAccountsid, msrtcoriginatorSID, Mail o.ä.) merged, dann funktioniert dies eigentlich recht problemlos. Man muss einfach wissen, dass die Reihenfolge der Connector-Einrichtung maßgeblich ist und ADSync die Felder der Objekte nach der "Precedence" zusammenführt. Auf der Seite  ADSync Multi Forest habe ich das ausführlicher beschrieben.

Bei einer Migration passiert es irgendwann dann, dass ein anderes Konto zum "aktiven Anmeldekonto" wird. ADSync unterstützt dies, indem der UPN von "deaktivierten Konten" beim Import ignoriert wird. Gegen Ende einer Migration wird aber meist ein alter Forest abgeschaltet und dann stellt sich schon die Frage, ob so ein "Delete" des Connectors auch zu einem "Delete" der Objekte führt. Kurze Antwort: In der Regel nein, solange das Objekt im Metaverse noch von einem anderen Connector bedient wird.

Ehe Sie aber einen Connector zu einem Forest komplett abbauen, möchten viele Administratoren erst einmal einzelne Objekte von der Replikation ausschließen. Ein legitimer Weg ist, diese AD-Objekte einfach aus dem Scope zu nehmen, z.B. Indem man sie in eine OU verschiebt, die von dem Connector nicht gelesen wird. Für ADSync ist das dann einem "Delete" gleichzusetzen.

Andre wird auf seinem Blog einen weitergehenden Artikel zu der Thematik veröffentlichen. Link folgt

Sie sollten aber nie das Attribute "cloudFiltered" nutzen. Der Name könnte sie ja auf den Gedanken bringen, einfach die "Inbound Synchronization Rule" derart anzupassen, dass das Feld cloudFiltered bei diesen Objekten auf TRUE gesetzt wird. Wenn dann die Reihenfolge der Connectoren ungünstig ist, dann gewinnt dieses Feld und setzt "cloudFiltered=True" im Metaverse. Das bedeutet für ADSync dann aber, dass das Objekt nicht mehr in den Tenant repliziert wird. Da ist es dann auch unwichtig, ob das Objekt noch von einem zweiten lokalen AD-Forest durch ADSync importiert und ins Metaverse geschrieben wird. Das Objekt wird in Entra gelöscht. Wenn Sie ihren Fehler erkennen und beseitigen, dann wird die Undelete-Funktion nur die Benutzer (samt Postfach, OneDrive etc.) wieder zurückholen aber Verteiler und Devices werden neu angelegt und müssen neu berechtigt und gejoined werden. (Stand Feb 2026)

Weitere Links