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 Addressbuch, 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 Whitelist 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 AD-Sync 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.

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 weiterhin, dass eine Änderung der OU-Strukturen nun auch auf den DirSync abgestimmt werden muss. Insbesondere, wenn neue OUs angelegt werden.

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

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-Premise auch die Exchange Schema-Erweiterung aktiviert haben. Dies ist aber sowieso quasi erforderlich, wenn Sie Exchange Online mit DirSync verwenden.

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.

Windows Gruppe

Seit AADConnect ist es auch möglich, über eine Windows Gruppe die Objekte zu bestimmen, die durch ADConnect 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. 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 OnPremise 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 Annmeldedaten 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.

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 "OnPremise" 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 et. Aber letztlich können Sie diese Überlegungen auf jedes Feld anwenden.

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 OnPremise-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