Office 365 - DirSync und Provisioning

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

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

Doppelte Mailadressen

Es ist nicht ungewöhnlich, dass ihnen Office 365 eine Mail sendet, dass ein Objekte aufgrund von Problemen der Mailadresse nicht importiert werden kann. In der letzten Spalte steht die MailboxGuid der "onpremise"-Mailbox. Allerdings BASE64 codiert, so dass Sie diese erst wieder ein ein lesbares Format überführt werden muss. Ein bischen Powershell hilft hierbei

# Hier muss der TEXT aus der Mail addiert werden
$Base64="Z4KTdsddaay1JJU/Q=="

# Konvertieren der BASE64 Information in eine GUID
$MailboxGUID=[System.Guid]([System.Convert]::FromBase64String($Base64))

# Mit der GUID kann dann die Mailbox gefunden werden
$Mailbox = Get-Mailbox $MailboxGUID.Guid

Ich habe es durchaus schon erlebt, dass das AzureAD hier auch Dubletten gemeldet hat, die gar keine waren. Es bleibt aber ihre Aufgabe als Admin die Probleme einzukreisen, denn erwarten Sie nicht, dass der Office 365 Helpdesk ihnen bei "on Premise" Problemen helfen kann. Das ist im Preis nicht machbar.

UPN mit Office 365

Ein Schlüsselelement des Dirsync ist der UserPrincipalName, der natürlich "onPremise" und "in der Cloud" identisch sein sollte. Er ist der "Matchcode" um bei ADFS und anderen Anmeldungen das Objekt korrekt zu identifizieren. Idealerweise ist das auch die Mailadresse, weil damit die Anwender sich das einfacher merken können aber vor allem auch weil damit der Eintrag weltweit eindeutig ist.

Nun ist es aber so, dass der UPN on Premise oft nicht gesetzt ist oder der DNS-Name der AD-Domäne als Suffix verwendet wird. Der ist aber in vielen Fällen eben nicht identisch mit der Mailadresse. Entsprechend müssen Sie dies gerade ziehen:

# Liste der Benutzer ermittlen, für die der UPN umgestellt werden muss
$userlist = Get-ADUser `
   -Filter {userprincipalname -like ‘*msxfaq.local’} `
   -Properties userPrincipalName,mail | `
$userlist | foreach { `

# UPN aus dem Feld NAME zusammenbauen
   Set-ADUser $_ -UserPrincipalName ("{0}@{1}" -f $_.name,"msxfaq.net")

# UPN aus der Mailadresse nehmen
   Set-ADUser $_ -UserPrincipalName ("{0}@{1}" -f $_.mail)
}

Get-MsolUser | `
   Set-MsolUserPrincipalName `
      -NewUserPrincipalName $_.mail

Nur beim ersten Abgleich wird der UPN der eigenen Umgebung an ein neues Objekt on der Cloud übertragen. Änderungen am UPN müssen Sie also anders abfangen. Spätestens wenn der Benutzer bei Anmeldeproblemen sich meldet, wäre das ein Prüfpunkt.

Weitere Links

Tags:Office365 Cloud Hosting Dirsync