Office 365 - DirSync und Provisioning

O365Check
Bitte prüfen Sie zuerst ihr lokales Active Directory, ehe Sie den Office 365 Dirsync aktivieren!

Diese Seite beschreibt den Office 365 Dirsync. der DirSync für Yammer ist eine eigene Software. Siehe auch Synchronize and authenticate users from your on-premises Active Directory to Yammer and Office 365 ( http://technet.microsoft.com/EN-US/library/dn457819.aspx)

Wer neben den Daten in der Office 365-Welt natürlich noch ein lokales Active Directory betreibt, wird die doppelte Pflege der Cloud-Anwender und lokalen Anwender natürlich nicht gut heißen. Aus dem Grund liefert Microsoft eine "DirSync-Komponente" auf dem Office 365-Portal mit aus, welche nicht anderes als ein vorkonfigurierter FIM ist. Sobald eine Domain aber für "DirSync" aktiviert ist, kann diese nicht mehr im Office 365 Portal verwaltet werden, sondern nur noch lokal über das eigene Active Directory.

Diese Entscheidung ist aktuell (Stand Anfang 2012) nicht umkehrbar. Der DirSync ist also eine Dauereinrichtung"

Der DirSync repliziert ALLE Benutzerkonten, Kontakte und Gruppen in die Cloud. Es gibt aktuell (Jan 2012) keine Möglichkeit diese Datenmenge zu filtern. Wer also intensiv mit Dienstkonten oder Sicherheitsgruppen für Delegierung von Rechten arbeitet, wird in Office 365 viele Konten sehen, die aber nicht "aktiviert" werden müssen und damit keine Lizenz kosten. Dennoch mag der ein oder andere Firmeninhaber hier ein Problem damit haben, da so eine komplette Liste gültiger Anmeldeadressen, Mailadressen, Rufnummern und Gruppenmitgliedschaften extern repliziert wird.

Exchange Virtual Conference: Office 365 Identities and Federation
http://exchangevirtualconference.com/evc-2013-session-5/

Trotzdem rate ich jedem, der auch ein eigenes Active Directory hat und nicht gerade nur eine Handvoll Anwender in Office 365 betreiben möchte, auch den Verzeichnisabgleich samt ADFS umzusetzen. Ansonsten holt sie der doppelte Pflegeaufwand ein. In der Oberfläche sieht das dann z.B.: wie folgt aus.

Manuell angelegte Benutzer und per DirSync am Doppelpfeil verwaltete Benutzer sind einträchtig nebeneinander ist der Liste aufgeführt. Schaue ich mir dann mein "Cloudkonto" an, dann sehen Sie aber einige Felder nur "grau", weil diese von dem lokalen Active Directory über den DirSync verwaltet werden:

Mein Konto in Office 365 ist also ein Nachläufer.

Objekte und Abgleich

Abgeglichen werden durch den DirSync, der durch eine angepasste Version von FIM bereit gestellt wird, immer die komplette Domäne mit allen Benutzern und Gruppen. Das Standardsetup filtert nur ein paar wenige Systemkonten aus. Wundern sie sich bitte nicht, wenn Sie nach dem ersten Abgleich in der Office 365-Umgebung alle Gruppen und Benutzer, d.h. auch Dienstkonten und vielleicht Berechtigungsgruppen, wiederfinden.

Ich finde dieses Standardverhalten höchst rücksichtslos. Ich möchte vielleicht gar nicht meine gesamte Gruppen und Anmeldedaten in der Office 365-Umgebung veröffentlichen. Natürlich ist eine umfangreiche Veröffentlichung z.B.: für die Koexistenz mit Exchange (Stichwort "Globale Addressliste") erforderlich, aber Dienstkonten und administrative Gruppen würde ich gerne ausschließen.

Wenn ein Konto so in der Cloud angelegt wurden, dann kostet dies aber noch keine Lizenz. Sie müssen das jeweilige Konto also per Powershell oder Browser erst noch die entsprechende Funktion verpassen, z.B.: ein Lync Konto, ein Exchange Postfach oder eine Office 2010 Lizenz.

Mein letzter Kenntnisstand war, dass die Zuweisung von Lizenzen ebenso wenig durch den DirSync mit erfolgen kann als eine Filterung der Objekte möglich wäre. Allerdings habe ich für meine Office 365-Projekte und die Net at Work-eigene Cloud natürlich eine Lösung geschafften, um FIM entsprechend zu filtern und die Lizenzen per Powershell und Skript zu verwalten.

Status

Automatisch im Hintergrund regelmäßig ablaufende Prozesse sollten überwacht werden.

Ich frage mich natürlich schon, warum Microsoft dem Kunden eine Dirsync-Instanz mit FIM aufzwingt. Eine Installation von ADWS auf einem DC mit einer passenden Veröffentlichung für die Cloud-Server wäre viel "leichtgewichtiger" und Microsoft könnte sich die Benutzerdaten "holen" und diesen Prozess auch überwachen.

Dem ist aber nicht so, also sollten Sie eine Überwachung planen. Sicher können Sie das Eventlog des Dirsync-Servers überwachen aber auch Office 365 sendet ihnen eine Warnung per Mail, wenn etwas beim Import in Office 365 nicht funktioniert hat.

Dummerweise kommt diese Mail natürlich nur, wenn der lokale DirSync versucht hat, eine Information in die Cloud zu schreiben und diese hatte beim der Verarbeitung einen Fehler. Der Link verweist übrigens auf die generelle Hilfeseite:

In diesem Fall war eine Längenüberschreitung der Fall, das in der Hilfe leider lapidar auf die MSDN ( http://g.microsoftonline.com/0BD00de-de/435 bzw. http://msdn.microsoft.com/en-us/library/ms675090(v=VS.85).aspx) verwiesen hat. In dem Fall hilft dann vielleicht ein einfacher LDIF-Export des Objekts, um ein "überlanges" Feld zu erkennen.

Im Eventlog steht ebenfalls ein Fehler, aber sagt noch nichts detailliertes aus:

In meinem Fall war es ein Verteiler, der SEHR VIELE Proxyadressen hatte. Anscheinend noch eine "Altlast" eines Exchange 2003 RUS, der früher mal Amok gelaufen ist. Über folgenden Powershelll-Befehl auf Exchange können Sie sich schnell einen Überblick verschaffen.

Get-Recipient | ft name,@{label="count"; expression={$_.emailaddresses.count}}

Weitere Links

Tags:Office365 Cloud Hosting Dirsync