ADSync Filterung

Per Default versucht der Office 365 DirSync alle Objekte des lokalen Active Directory auch in die Cloud zu synchronisieren. Ob das kritisch ist, müssen Sie selbst entscheiden aber ich möchte z.B. nur, dass Benutzer in der Cloud erscheinen, die dort erforderlich sind aber z.B. rein lokal genutzte Gruppen und Benutzer nicht extern sichtbar werden. So möchte ich vermeiden, dass die Anmeldenamen von lokalen Dienstkonten oder Administratoren in der Cloud bekannt werden und vielleicht doch einmal zu viele Rückschlüsse auf die interne Umgebung zulassen. Daher möchte ich filtern. Der erste DirSync war hier noch stark beschränkt. Mittlerweile stehen mit AADConnect mehr Möglichkeiten offen.

  • Domain
  • OU
  • LDAP-Feld
  • Windows Gruppe

Beachten Sie aber, dass Sie nicht nur die Benutzer in die Cloud synchronisieren sollten, die dort auch Dienste nutzen. So sehen Exchange Online-Anwender nur die Benutzer in ihrem Adressbuch, die in der Cloud angelegt sind, Diese müssen dazu nicht in der Cloud auch ein Postfach habe, aber die Identität mit den Exchange Informationen muss vorhanden sind. Das gilt auch für Gruppen, die z.B. als Mailverteiler genutzt werden. Für Exchange lässt sich sagen, dass eigentlich jedes Objekt mit einer Mailadresse auch in der Cloud erscheinen sollte und die GAL auf beiden Seiten gleich sein muss. Daher beschränken sich Filter oft wirklich eher auf Ausschlüsse von sensiblen Objekten oder Bereichen. Wobei genau solche vorsichtigen Firmen eher zu einer Allowlist tendieren, z.B. die zur Synchronisation freigegebenen Objekte explizit entsprechend konfiguriert werden.

Domain

Die Filterung nach Domain ist am einfachsten Einzustellen. Bei der Konfiguration des ADSync muss eine Verbindung zur Quelldomäne aufgebaut werden.

Wenn diese Konfiguration nicht erfolgt, dann kann der DirSync die Objekte gar nicht sehen und gar nicht anlegen.

Domain-based: You can use this filtering type to manage the properties of the SourceAD Management Agent in the directory synchronization tool. This type enables you to select which domains are allowed to synchronize to the cloud
Quelle: http://technet.microsoft.com/en-us/library/jj710171.aspx

Auch wenn diese Filterung sehr effektiv ist, finde ich sie meist ungeeignet, da dann wirklich in dieser Domäne nie ein Office 365-relevantes Objekt erscheinen darf und die Objekte in anderen Domänen alle synchronisiert werden dürfen.

OU

Daher sind Filter auf OU-Ebene schon flexibler. Als Administrator richten Sie im ersten Schritt alle möglichen Quelldomänen ein, aber konfigurieren ADSync dann so dass er ausgewählte OUs inkludiert oder eben ausschließt.

Wer ein geeignetes OU-Modell hat, findet so einen sehr bequemen Weg zur Steuerung der Replikation.

Bei der Filterung von OUs wird nur hinterlegt, welche OU-Pfade nicht repliziert werden. Neue OUs unter bereits replizierten OUs werden automatisch neu aufgenommen aber OUs unter nicht replizierten OUs werden auch nicht aufgenommen.

Organizational-unit (OU)–based: You can use this filtering type to manage the properties of the SourceAD Management Agent in the Directory Synchronization tool. This filtering type enables you to select which OUs are allowed to synchronize to the cloud.
Quelle: http://technet.microsoft.com/en-us/library/jj710171.aspx

Die Filterung nach OU ist natürlich nicht nutzbar, wenn in einer OU sowohl relevante als auch auszuschließende Objekte vorhanden sind. In den seltensten Fällen wird eine Firma hier dann ihr OU-Konzept umstellen. Beachten Sie dabei:

  •  Wenn sie eine OU umbenennen der verschieben, dann "lernt" das ADSync nicht!
    ADSync merkt sich den DN, und ist im schlimmsten Fall dann nicht mehr eingeschlossen. ADSync löscht dann die Objekte in der Cloud.
  • Denken Sie daran, immer alle OUs einschließen, in denen Exchange Empfänger sind
    Manchmal sind die Empfänger aber auch in anderen OUs, die sie nicht aktiv nutzen.

In welchen OUs ihre Exchange Objekte sind, können Sie z.B.: wie folgt in einer Exchange PowerShell ermitteln

Get-Recipient -ResultSize unlimited `
| group OrganizationalUnit -NoElement `
| select name

Beachten Sie weiterhin, dass eine Änderung der OU-Strukturen nun auch auf den DirSync abgestimmt werden muss. Insbesondere, wenn neue OUs angelegt werden.

Diese Einstellung filtert den Import in den Connectorspace. Wenn Sie hier nur die OUs einbinden, in denen relevante Objekte sind, können Sie den Import in den Connectorspace effektiver gestalten.

Windows Gruppe

Seit AADConnect ist es auch möglich, über eine Windows Gruppe die Objekte zu bestimmen, die durch AADConnect in die Cloud synchronisiert werden. Das macht den Einstieg sehr viel einfacher, da nun einfach eine Windows Gruppe angelegt und die Objekte dort addiert werden können. Microsoft benennt diese Option auch explizit als Möglichkeit bei einem Piloten die Gruppe der Anwender einzuschränken.

Eine Filterung der Objekte über eine Gruppe erscheint eine gute Idee, aber ist maximal für Piloten und POCs empfohlen. Wenn AADConnect bei jedem Lauf erst die Mitglieder einer Gruppe aufzählen und dann synchronisieren muss, ist das wohl aufwändiger als ein LDAP-Filter auf ein Attribute, welches im GB ist. (z.B. Extension Attribute). Zudem können Sie diesen Filter nur bei der Erstinstallation einrichten und nicht mehr nachträglich über den Assistenten.

Wenn Sie die Extension Attribute nutzen wollen, dann lesen Sie vorher die Seite Exchange Extension Attribute und die Besonderheiten beim "Disable-*"-Commandlet mit den Feldern.

Die Option ist für Pilotbereitstellungen gedacht, bei denen nur ein kleiner Satz von Objekten synchronisiert werden soll. Wenn Sie die gruppenbasierte Filterung deaktiviert haben, können Sie sie nicht mehr aktivieren. Die Verwendung der gruppenbasierten Filterung in einer benutzerdefinierten Konfiguration wird nicht unterstützt. Die Konfiguration dieses Features wird nur mit dem Installations-Assistenten unterstützt. Wenn Sie Ihr Pilotprojekt abgeschlossen haben, sollten Sie eine der anderen Filteroptionen in diesem Thema verwenden.
Quelle: https://docs.microsoft.com/de-de/azure/active-directory/connect/active-directory-aadconnectsync-configure-filtering#group-based-filtering 

Das bedeutet aber nun auch beim Provisioning, dass neue Anwender natürlich mit in diese Gruppe aufgenommen werden müssen. Ich gehe mal einfach davon aus, dass Anwender auch ein Postfach On-Prem oder der Cloud erhalten sollen. Damit sind sie zwingend "ADSync"-relevant. Gruppen lassen sich auch rekursiv nutzen und können neben Benutzern eben auch andere Gruppen und Computer enthalten.

Besonders interessant sind Gruppen dahingehend, dass Sie anders als OUs eben nicht auf Domänen oder LDAP-Zweige beschränkt sind. Mir ist das selbst schon passiert, dass mit ADSync zuerst nur die OU repliziert wurde, in der sich die "normalen Konten" befanden und damit Admin-Accounts und Dienstkonten ausgenommen wurden. Aber dann ist das erste Dienstkonto dabei gewesen, welches auch in Exchange Online per "Impersonate" auf Postfächer in der Cloud zugreifen musste. Damit braucht auch das Dienstkonto einen Zwilling in Office 365 und wenn dieses Konto nicht mit eigenständigen Anmeldedaten und UPN angelegt werden soll, muss ADSync auch dieses Konto replizieren. ich möchte aber nicht dieses Dienstkonto dann in die OU mit den normalen Anwendern verlagern. So was also auch hier ein Wechsel der Filterung erforderlich.

LDAP-Feld

Als am flexibelsten hat sich daher die Filterung nach einem LDAP-Feld bewährt. Leider gibt es von Microsoft kein entsprechend vordefiniertes Feld, d.h. weder ADSync noch DirSync haben in der Konfiguration eine direkte Unterstützung und Sie erweitern auch nicht das lokale Active Directory um ein eigenes Feld. Als Administrator bleibt ihnen daher nur der Weg sich ein geeignetes Feld selbst heraus zu suchen und die Pflege der Inhalte zu organisieren.

User-attribute–based: You can use this filtering method to specify attribute-based filters für User objects. This enables you to control which objects should not be synchronized to the cloud.
Quelle: http://technet.microsoft.com/en-us/library/jj710171.aspx

Auf der Seite Exchange Felder habe ich die Details um die Exchange Schema-Erweiterung beschrieben. Interessant sind hier die beiden folgenden Abschnitte: 

Microsoft Exchange Server 2013 includes 15 extension attributes. You can use these attributes to add information about a recipient, such as an employee ID, organizational unit (OU), or some other custom value für which there isn't an existing attribute. These custom attributes are labeled in Active Directory as ms-Exch-Extension-Attribute1 through ms-Exch-Extension-Attribute15. In the Exchange Management Shell, the corresponding parameters are CustomAttribute1 through CustomAttribute15. These attributes aren't used by any Exchange components.
Quelle: Custom Attributes http://technet.microsoft.com/en-us/library/ee423541.aspx

Finally, we have also added ms-Exch-Extension-Attribute-16 to 45. Those are not exposed to various CMDlets and Exchange management uI, because they were added für future use. As such, we cannot recommend that you use non-Exchange tools to edit their values because we might use those attributes in the future für various Exchange features. If and when we add management tools access to them, we will definitely let you know!
Quelle: http://blogs.technet.com/b/exchange/archive/2012/01/17/custom-aka-extension-attributes-in-exchange-2010-sp2-and-their-use.aspx

In Exchange 2010 SP2, we have added five new multi-value custom attributes that you can use to store information für mail recipient objects. They are the ExtensionCustomAttribute1 to 5 (also can be referred to as ms-exch-extension-custom-attribute-1 to 5).
http://blogs.technet.com/b/exchange/archive/2012/01/17/custom-aka-extension-attributes-in-exchange-2010-sp2-and-their-use.aspx

Wenn Sie die Extension Attribute nutzen wollen, dann lesen Sie vorher die Seite Exchange Extension Attribute und die Besonderheiten beim "Disable-*"-Commandlet mit den Feldern.

Die von Microsoft neu addierten Attribute 16-45 dürfen Sie also nicht nutzen. Im Gegenzug gibt Microsoft aber offiziell die Felder 1-15 für eigene Anwendungen frei. Seit Exchange 2010SP2 gibt es noch 5 weitere "Custom Attribute", die genutzt werden können. All diesen Feldern ist natürlich gemein, dass Sie nur vorhanden sind wenn Sie On-Prem auch die Exchange Schema-Erweiterung aktiviert haben. Dies ist aber sowieso quasi erforderlich, wenn Sie Exchange Online mit DirSync verwenden. Für die Einrichtung gibt es Microsoft ein sehr ausführliches Dokument

Die Einrichtung erfolgt über den Azure AD Rule Editor, den Sie im Startmenü finden. Wenn Sie sich etwas mit der Funktionsweise des AADConnect auseinander gesetzt haben, dann wissen Sie ja um den "Export aus der Quelle" in den jeweiligen Connectorspace und die dann folgende "Synchronisation" in das Metaverse gefolgt von dem Export des ConnectorSpace in die Ziele. Filtern können Sie nur beim "Synchronisieren". Hier aber sowohl "inbound", d.h. vom Connectorspace in das Metaverse oder auch "Outbound" vom Metaverse in einen Connectorspace.

Ich bevorzuge die "Inbound" Filterung, weil dann die unerwünschten Objekte gar nicht erst im Metaverse erscheinen. Relevant sind dabei nur die Regeln, die einen "Join" im Namen beinhalten. Diese sind maßgeblich für die Verbindung zu Objekten im Metaverse. Wenn das Objekt gefiltert ist, dann gibt es auch für die nachfolgenden Regeln nichts mehr zu tun.

"We recommend that you apply inbound filtering because that is the easiest to maintain. You should only use outbound filtering if it's required to join objects from more than one forest before the evaluation can take place."
Quelle: https://docs.microsoft.com/de-de/azure/active-directory/hybrid/how-to-connect-sync-configure-filtering 

Eine andere Option ist das Setzen des MetaVerse Attribute "CloudFiltered", da auf Basis dieses Felds dann ausgehend Objekte ausgeschlossen werden können.

Wenn Sie eine Regel bearbeiten, dann sehen Sie bei den Default-Regeln immer den folgenden Dialog:

Das Ändern der Default Regeln ist eine schlechte Idee, da ein Update des AADConnect diese Einstellung eventuell wieder überschreibt. Daher ist es besser die Regel durch den Editor kopieren zu lassen und die Kopie mit einer niedrigeren Nummer bei der Precedence zu versehen. (Microsoft empfiehlt hier Werte von 50-99). Die eigene Regel wird dann zuerst ausgeführt und die originale Regel wird deaktiviert. So ist ein Rückbau wieder schnell möglich.

bei der Einstellung der Filter haben Sie nun wieder die Wahl, ob sie mit einer Positivliste nur bestimmte Objekte einschließen oder nur besondere Objekte ausschließen. Microsoft selbst arbeitet beim Objekt "User" mit folgenden Regeln:

Es werden also nur die Objekte addiert, die KEIN Systemobjekt und NICHT mit "User_" in der adminDescription anfangen. Sie könne hier also einfach eine "Add Clause" machen und z.B. einen Ausdruck "ExternsionAttribute1=Sync" addieren. Dann werden nur diese Objekte synchronisiert. Genau genommen könnten Sie die beiden vorhandenen Ausdrücke dann sogar noch entfernen, wenn Sie an anderer Stelle dafür sorgen, dass nur relevante Objekte ein "ExternsionAttribute1=Sync" bekommen.

Denken Sie dran, dass Sie vielleicht auch Gruppen, Kontakte etc. filtern wollen.

Tipp:
Vielleicht nehmen Sie ein Feld und hinterlegen in dem Feld auch gleich die dem Benutzer zuzuweisende Office 365 Lizenz. Allerdings ist das doch wieder keine gute Idee, wenn nicht jedes Objekt, welches per ADSync repliziert wird muss auch eine Lizenz bekommen. Zudem werden ja nicht nur Benutzer sondern auch Gruppen etc. repliziert. Das "Filter"-Feld sollte als schon bei allen Objekten auch vorhanden sind. Gruppen und Benutzer haben aber durchaus unterschiedliche LDAP-Felder.

Inhalte von Felder filtern

Sie könnten nun natürlich einfach auf die Filterung nach Objekten verzichten und stattdessen einfach den kompletten Forest mit dem Tenant abgleichen. Da gibt es aber auch wieder mehrere Dinge, die Sie dabei stören könnten.

  • Die Menge an Objekten
    Vielleicht wollten Sie schon anhand der Übersichtlichkeit nicht alle Objekte in der Cloud haben
  • UPN-Regelung
    Ein Konto in der Cloud muss einen UPN einer zugewiesenen Domäne oder des tenantname.onmicrosoft.com-Namensraum haben. Sie müssten also erst alle Konten im lokalen AD entsprechend umstellen oder damit leben, dass ADSync bei der Replikation in die Cloud einen anderen UPN hinterlegt. Das macht eine spätere Fehlersuche und Analyse nicht einfacher und im schlimmsten Fall belegt so ein Konto dann einen UPN-Namen, der später von einem echten Konto genutzt werden soll.
  • Feldinhalte
    Das größte Problem wird aber das Thema Datenschutz sein. Vielleicht wollten oder dürfen Sie einfach nicht alle Metadaten in die Cloud übertragen, weil man damit zu viele Informationen erhalten kann oder Risiken entstehen

Es gibt die Möglichkeit, in ADSync auch "pro Feld" zu filtern, d.h. wenn Sie z.B. im Feld "Mobile" die Mobilfunknummer des Anwenders hinterlegt haben und verhindern möchten, dass diese Daten in Office 365 erscheinen, dann können Sie dieses Feld auch filtern. Allerdings bauen Sie dann eine "Zwei Klassen Gesellschaft" auf, bei der Benutzer On-Premises mehr und umfangreichere Daten sehen als die Anwender in der Cloud. Gerade das Feld "Mobile" ist natürlich besonders interessant für eine Zwei-Faktor-Authentifizierung etc. Aber letztlich können Sie diese Überlegungen auf jedes Feld anwenden.

Die einfache Konfiguration ist über den Assistenten möglich:

Durch die Checkbox in "Azure AD App and attribute filtering" erscheinen links zwei neue Menüs. Über die "Azure AD Apps" können sie vordefinierte Property-Gruppen abschalten.

Unter "Azure Ad Attributes" können dann noch weitere Attribute ausgeschlossen werden:

Wenn das aber noch nicht reicht oder vielleicht eine Veränderung der Inhalte gewünscht werden, dann gibt es immer noch die Transformation-Rules im Nachgang.

Wo erfolgt die Filterung?

Die Funktionsweise von ADSync besteht aus folgenden Schritten:

  1. Import der Daten aus allen Quellen in den entsprechenden Connector Space
    Damit lädt ADSync die Updates der Quelle in seine SQL-Tabellen und erkennt z.B. Änderungen und Löschungen
  2. Synchronisation der Daten
    Damit werden die Änderungen anhand der Synchronisierungsregeln in das Metaverse und die anderen Connectorspace-Tabellen übernommen
  3. Export
    Damit schreibt ADSync dann die Änderungen in die entsprechenden Zielsysteme

Die Filterung in ADSync finden bei der Synchronisation statt. Das bedeutet aber im Umkehrschluss, dass z.B. bei Import aus der Quelle in den ConnectorSpace des Connectors keine Filterung erfolgt. Es werden immer alle Elemente aus der Quelle erst einmal in den Connectorspace übertragen. Wenn Sie eine Suche im Connectorspace machen, dann sehen Sie hier auch sehr viele Einträge zu Domain, OUs etc., die gar nicht relevant sind.

Sie können am ADSync Assistenten vorbei natürlich im Synchronisation Manager den Connector weiter anpassen, wobei ich davon abrate, denn die Möglichkeiten sind beschränkt. Erst der "große FIM" (Forefront Identity Manager 2010 (FIM 2010) build 4.0.3594.2 und neuer) erlaubt hier weitere Einstellungen:

Diesen zusätzlichen Eintrag "Configure Connection Filter" finden Sie nicht im ADSync-Manager.

Feature 3 Adds the ability to filter objects before they are imported into the AD MA connector space.
Quelle: KB2520954 A hotfix rollup package (build 4.0.3594.2) is available for Forefront Identity Manager 2010
https://support.microsoft.com/en-us/topic/a-hotfix-rollup-package-build-4-0-3594-2-is-available-for-forefront-identity-manager-2010-1834bca2-d310-5baa-03d7-011e6ad68f56

Wenn Sie im ADSync Assistenten aber auf OUs filtern, dann erfolgt dies auch schon beim Import in den Connectorspace.

Einschätzung

Am Anfang war ich noch sehr kritisch was Office 365 betrifft aber ich habe gelernt, dass die Services von Microsoft vermutlich viel besser und sicherer betrieben werden, als viele lokale Server von kleinen und mittleren Firmen. Die Information, welche Benutzer es in ihrem lokalen Active Directory gibt und welche Strukturen und Abhängigkeiten definiert sind, kann jeder Azubi per LDIFDE und CSVDE auslesen. Das kann auch jeder Trojaner oder jedes Makro. Es wird immer einen Weg geben diese Daten zu ermitteln. Dann sollte ich mir und meiner Firma das Leben nicht unnötig erschweren und durch sehr eng gefasster Filter die Funktionalität künstlich beschneiden.

Als Office 365 Kunde haben Sie einen Vertrag mit Microsoft abgeschlossen, aus dem Rechte und Pflichten für beide Seiten entstehen. Die Ängste vor Datenzugriffen, Geheimdiensten etc. lassen sich nicht 100% wegdiskutieren aber bei einem On-Prem-Server wissen Einbrecher zumindest, wo er steht und ob sie hier alle Spuren und Versuche erkennen, will ich nicht beschwören.

Allerdings kann ich es schon aus Sicherheitsgründen natürlich verstehen, wenn bestimmte besonders sensible AdminAccounts und Dienstkonten vielleicht nicht in der Cloud erscheinen sollen. Dann können Sie hier mit Filtern arbeiten.

Weitere Links