ADSync und Gruppen
Für den Zugriff auf Postfächer, Meetings, SharePoint-Sites etc. sind natürlich Benutzer am wichtigsten. Für die Vergabe von Berechtigungen oder als Verteiler bei Mails sind Gruppen bei Office 365 nicht weniger wichtig. Gruppen können natürlich in der Cloud "losgelöst" verwaltet werden. Interessanter ist aber natürlich der Abgleich mit den Gruppen im Active Directory.
Typen von Gruppen
Ich habe dazu einige Gruppen in meinem lokalen Active Directory eingerichtet und den ADSync in der Standardeinstellung belassen. Nach einigen Minuten konnte ich folgende Gruppen sehen.
Anhand der Namen können Sie schon erkennen, dass ich lokal die unterschiedlichen Gruppen ausgenutzt habe. Alle manuell angelegten im AD angelegten Gruppen haben ein "AD-" Präfix. Die Gruppen mit dem "O365-"Präfix sind in der Cloud angelegt worden. Im Admin Center ist im Gegensatz zu den Benutzern nicht direkt erkennbar, ob eine Gruppen durch den ADSync verwaltet wird oder nicht. Auch in der Powershell gibt es nur diese drei Gruppen.
PS C:\> Get-MsolGroup ObjectId DisplayName GroupType Description -------- ----------- --------- ----------- <guid> WinRMRemote Security <guid> O365Gruppe1 DistributionList Office 365 Groups 1 <guid> o365-SG MailEnabledSecurity <guid> o365-DL DistributionList <guid> AD-LSG MailEnabledSecurity <guid> AD-GDG DistributionList <guid> AD-USG2 MailEnabledSecurity <guid> AD-GSG MailEnabledSecurity <guid> AD-LDG DistributionList <guid> AD-UDG DistributionList <guid> AD-USG MailEnabledSecurity
Sie sehen hier auch die verschiedenen Typen.
Deutsch | Powershell | Beschreibung |
---|---|---|
Verteilerliste |
Distribution List |
Dies sind "Gruppen", die als Mailverteiler genutzt werden können aber keine "SID" haben. |
Verteilergruppe mit Security |
MailEnabledSecurity |
Dies ist die klassische Sicherheitsgruppe mit einer Mailadresse, die auch in Exchange als Verteiler genutzt werden kann. |
Office 365 Gruppe |
Distribution List |
Technisch ist eine "Office 365 Gruppe" in den Gruppen "nur" eine Distribution List |
Sicherheitsgruppe |
Security |
Wenn eine Gruppe On-Prem eine AD-Sicherheitsgruppe ist aber keine Mailadresse hat, dann wird in der Cloud eine einfache Sicherheitsgruppe darauf |
Andere Gruppen scheint es aktuell nicht zu geben, wenn man sich die möglichen Werte des Parameters "-GroupType" bie Get-MSOLGroup anschaut:
Tipp:
Beim Einsatz von ADSync würde ich immer nur die AD-Gruppen
nutzen und manuell in Office 365 gepflegten Gruppen
diese über ein Namenspräfix oder -suffix kennzeichnen. Dies
wird insbesondere dann interessant, wenn z.B. die Gruppen,
die durch
Office 365 Groups angelegt werden, auch wieder zum AD
zurück repliziert werden können.
Feldinhalte bei Gruppen
Interessant ist hier, dass die Office 365 Gruppe per PowerShell sich nicht von einer normalen Verteilerliste unterscheidet und es auch kein direktes Feld gibt, die eine durch ADSync verwaltete Gruppe anzeigt. Einzig der Eintrag "LastDirSyncTime" ist ein Hinweise darauf.
Property | In Office 365 manuell angelegte Gruppe | Synchronisierte Active Directory Globale Security Gruppe mit Mailadresse | Synchronisierte Active Directory Security Gruppe ohneMailadresse | Office 365 Gruppe |
---|---|---|---|---|
CommonName |
$null |
AD-GSG |
AD-LSG |
$null |
Description |
$null |
$null |
$null |
Office 365 Groups 1 |
DirSyncProvisioningErrors |
$null |
$null |
$null |
|
DisplayName |
o365-DL |
AD-GSG |
AD-LSG |
O365Gruppe1 |
EmailAddress |
o365-DL@carius.mail.onmicrosoft.com |
AD-GSG@msxfaq.net |
$null |
o365gruppe1@msxfaq.net |
Errors |
$null |
{} |
$null |
{} |
GroupType |
Distributionlist |
MailEnabledSecurity |
Security |
DistributionList |
IsSystem |
False |
False |
False |
False |
LastDirSyncTime |
$null |
09.06.2015 08:36:53 |
25.04.2015 22:06:15 |
$null |
Licenses |
{} |
{} |
{} |
{} |
ManagedBy |
$null |
$null |
$null |
$null |
ObjectId |
<guid> |
<guid> |
<guid> |
<guid> |
ProxyAddresses |
{SMTP:o365-DL@carius.mail.onmicrosoft.com} |
{smtp:AD-GSG@carius.onmicrosoft.com, SMTP:AD-GSG@msxfaq.net} |
<guid> |
{smtp:o365gruppe1@carius.onmicrosoft.com, SMTP:o365gruppe1@msxfaq.net} |
ValidationStatus |
Healthy |
Healthy |
Healthy |
Healthy |
Es gibt anscheinend auch kein ImmutableID als Property am Objekt in Office 365. Im ADSync wird der SourceAnchor aber gebildet:
Ich nehme an, dass beim Zugriff auf den AzureAD-Webservice die Informationen vom Source-Anchor in ein anderes Feld geschrieben wird.
Welche Gruppen werden repliziert ?
Bei der Replikation der Gruppen gibt es aber ein paar Überraschungen. Zuerst habe ich die sechs Gruppenarten lokal angelegt. Folgende drei Gruppen wurden ohne Mailadressen angelegt:
Die "Verteiler" aus dem lokalen Active Directory erscheinen nicht in Office 365
Name | Typ | Mailadresse | Office 365 |
---|---|---|---|
AD-GDG |
Global |
$null |
Wird nicht angelegt |
AD-GSG |
Global |
$null |
Sicherheitsgruppe |
AD-LDG |
Local |
$null |
Wird nicht angelegt |
AD-LSG |
Local |
$null |
Sicherheitsgruppe |
AD-DDG |
Domain Local |
$null |
Wird nicht angelegt |
AD-DSG |
Domain Local |
$null |
Sicherheitsgruppe |
Hier ist gut zu sehen, dass nur Sicherheitsgruppen angelegt werden. Im zweiten Schritt habe ich dann jeder Gruppe eine Mailadresse gegeben. Ich habe also "NUR" das Feld "mail" gefüllt. In der lokalen AD Installation gibt es keine Exchange Schemaerweiterung oder Exchange Installation.
Auch hier noch mal als Tabelle:
Name | Typ | Mailadresse | Office 365 |
---|---|---|---|
AD-GDG |
Global |
AD-GDG@msxfaq.net |
Verteilerliste |
AD-GSG |
Global |
AD-GSG@msxfaq.net |
Verteilerliste mit Security |
AD-LDG |
Local |
AD-LDG@msxfaq.net |
Verteilerliste |
AD-LSG |
Local |
AD-LSG@msxfaq.net |
Verteilerliste mit Security |
AD-DDG |
Domain Local |
AD-DDG@msxfaq.net |
Verteilerliste |
AD-DSG |
Domain Local |
AD-DSG@msxfaq.net |
Verteilerliste mit Security |
Als Ergebnis wurden alle Gruppen nun zu "Verteilerliste" konvertiert und die Sicherheitsgruppen im lokalen AD wurden zu "Verteilerliste mit Security"
Wenn eine Gruppe eine Mailadresse hat, die sie nicht in Office 365 konfiguriert haben, dann wird eine @%tenantname%.onmicrosoft.com-Adresse generiert. Wird die Mailadresse danach auf eine gültige in Office 365 registrierte Domain geändert, dann wird dies natürlich auch übernommen
Etwas inkonsistent wird es nun aber, wenn Sie einer Gruppen On-Premises die Mailadresse wieder entfernen. Der Typ der Gruppe ändert sich aber nicht zurück auf "Sicherheitsgruppe":
Auf der anderen Seite werden die einfachen Verteilergruppen in Office 365 durch die Wegnahme der Mailadresse wieder gelöscht. Insofern gibt es ein paar grundlegende Fakten:
- Sicherheitsgruppen werden immer synchronisiert
- Verteilergruppen werden nur synchronisiert, wenn sie eine Mailadresse haben
- Wird die Mailadresse einer Gruppe entfernt, dann passiert unterschiedliches:
- Verteilergruppe: Die
Gruppe wird komplett in
Office 365 entfernt.
Eigentlich ein guter Indikator, dass so eine Gruppe nur für Exchange relevant ist - Sicherheitsgruppe:
"nichts" passiert
Wird von einer "Sicherheitsgruppe mit Mailadresse" die Mailadresse On-Prem entfernt, dann wird die interessanterweise durch ADSync als "deleted" bzw. Update in der Cloud angezeigt
Aber zumindest in meinem Tenant sind die Mailadressen an den Gruppen sowohl im Admin Center als auch per Powershell erhalten geblieben.
- Verteilergruppe: Die
Gruppe wird komplett in
Office 365 entfernt.
Insofern kann es durchaus sein, dass im Bezug auf die Mail-Adresse die Gruppen in der Cloud nicht den On-Prem-Gruppen nachfolgen.
Mitgliedschaften
Gruppen hätten keine Daseinsberechtigung, wenn es keine Mitglieder gäbe. Die Mitgliedschaft von Gruppen wird bei ADSync anhand des lokalen Active Directory abgeglichen. In Office 365 manuell angelegte Gruppen können auch dort verwaltet werden. Mich interessiert, wie ADSync die Mitglieder synchronisiert, ob eine Änderung in der Cloud blockiert ist und wie er mit partiellen Mitgliedern umgeht, z.B. wenn Benutzer und Gruppen On-Prem Mitglied sind aber nicht von ADSync nach Office 365 repliziert werden.
Die Mitglieder einer Gruppe in der Cloud ist einfach per Admin Center oder über das PowerShell Commandlet "Get-MSOLGroupMember" zu erhalten. Zuerst habe ich mal wieder On-Prem alle Gruppen in alle Gruppen aufgenommen, in die Sie aufgenommen werden könnten. Es gibt hier durchaus auch On-Prem Einschränkungen. Das Ergebnis hätte ich so aber nicht erwartet. Im Admin Center kommen die Mitgliedschaften bei einigen Gruppen nicht an !
Falsche Anzeige von ADSync Gruppen im Admin Center (Stand
28. März 2016)s
Wenn ich aber per PowerShell nachschaue, dann sind die Mitglieder sehr wohl in der Gruppe enthalten
Wenn ich die Mitglieder über alle Gruppen prüfe, dann ist gut zu sehen, dass es die "Security Groups" aus dem On-Prem Active Directory sind, die in der Webverwaltung nicht korrekt ankommen:
Gruppe | Mitglieder im Active Directory | Get-MSOLGroupMember | Admin Center per Browser (28.03.2016) |
---|---|---|---|
AD-GDG |
AD-GSG; AD-USG |
AD-GSG; AD-USG |
AD-GSG; AD-USG |
AD-GSG |
AD-GDG; AD-USG |
AD-GDG; AD-USG |
$null |
AD-LDG |
AD-GDG, AD-GSG, AD-LDG, AD-UDG, AD-USG |
AD-GDG, AD-GSG, AD-LDG, AD-UDG, AD-USG |
AD-GDG, AD-GSG, AD-LDG, AD-UDG, AD-USG |
AD-LSG |
AD-GDG, AD-GSG, AD-LDG, AD-UDG, AD-USG |
AD-GDG, AD-GSG, AD-LDG, AD-UDG, AD-USG |
$null |
AD-UDG |
AD-GDG, AD-GSG, AD-USG |
AD-GDG, AD-GSG, AD-USG |
AD-GDG, AD-GSG, AD-USG |
AD-USG |
AD-GDG, AD-GSG |
AD-GDG, AD-GSG |
$null |
Ich gehe mal davon aus, dass dies nur ein temporäres Problem des "neuen" Admin Centers ist. Im "alten" Admin Center funktioniert es noch alles
Insofern sind sie gut beraten, die PowerShell als Referenz zu nutzen.
Achtung:
Öffentliche Ordner können "Mailaktiviert" sein und die
AD-Objekte können auch in einer mailaktivierten Gruppe
Mitglied sein. Leider repliziert ADSync diese Mitglieder
nicht!. Siehe dazu auch
ADSync
und Public Folder
Gruppen matchen
Siehe dazu die gesonderte Seite ADSync - Group Matching
Mitgliedschaften mit Ressouce Forest Szenarien
Auf der Seite Hybrid Ressource Forest habe ich verschiedene Modelle in Verbindung mit zwei lokalen Forests beschrieben. Hier stellt sich dann die Frage, welche Domäne nun die relevanten Gruppenmitgliedschaften enthält. Sind es die Verteilergruppen im Exchange Forest oder doch die Sicherheitsgruppen im Account Forest. Der Verzeichnisabgleich möchte ja die Gruppen des Exchange Forest in die Cloud synchronisieren, damit die Erreichbarkeit gegeben bleibt.
Allerdings haben es bei meinen Tests diese Mitglieder nicht in den Office 365 Forest geschafft. Stattdessen wurden die Mitglieder der Gruppe im Account-Forest übertragen.
Gruppen in der Cloud löschen?
Gruppen, die aus dem lokalen Active Directory per ADSync verwalten werden, sollten in der Cloud "Read-Only" sein. In den meisten Fällen ist ADSync nämlich unidirektional. Um so erschreckender fand ich, dass ich eine per ADSync angelegt Gruppe in der Cloud einfach per Web Browser löschen konnte. ich habe dazu die Gruppe AD USG in dem alten Admin Center angeklickt und "löschen" gesagt. Sowohl in der GUI als auch in der PowerShell war die Gruppe einfach weg.
Entsprechend gespannt war ich auf das Ergebnis des dann einmal angestoßenen DirSync. Zuerst findet ein Import statt und da ist beim Delta Import aus der Cloud schon mal zu sehen, dass es hier "Deletes" gibt. Interessanterweise wird dies nicht als "Fehler" gemeldet.
Als Folge davon verschwindet das Objekt im Metaverse, so dass man leider keine Details mehr sehen kann.
Über den Namen des CN (hier "53aa00a9-3a50-403d-9aaf-161c80491aa0") können Sie immer noch zuordnen, dass es die Gruppe AD-USG war. Die Fehlermeldung im ADSync ist ein nichtssagendes "sync-generic-failure"
Allerdings war diese Inkonsistenz nur bis zum nächsten Delta-Sync vorhanden. Beim nächsten ADSync-Lauf wurde die "fehlende Gruppe" wieder angelegt.
Allerdings würde ich mir schon wünschen, dass die Gruppe nicht einfach im AD zu löschen ist, solange "DirSync" noch konfiguriert ist. Per Powershell kann die Gruppe übrigens auch einfach gelöscht werden.
Mitgliedschaften ändern
Wenn schon ein Löschen möglich ist, dann bin ich neugierig, ob ich in der Cloud auch Mitglieder löschen kann. den entsprechenden Button habe ich im Admin Center schon gesehen. da über das Admin Center im Browser aber eh nur drei Verteilergruppen (AD-GDG, AD-LDG, AD-UDG) der sechs Gruppen ihre Mitglieder angezeigt haben, habe ich die Gruppe "AD-GDG" editiert:
Ein Druck auf "Entfernen" aktiviert den "Speichern"-Button und wenn ich den Drücke, kommt einfach ein:
Hier kommt schon mal kein Fehler. Also mal schnell in der PowerShell den "richtigen Status" angezeigt:
Interessant, denn hier sind die Mitglieder noch enthalten. Ich habe auch ADSync kontrolliert, der in der Zeit aber nicht gelaufen ist. Zurück im Admin Center wurden an der Gruppe erst keine Mitglieder angezeigt aber in der Detailansicht auch wieder beide Gruppen. Es hat den Anschein, dass das "Admin Center" nicht darauf Rücksicht nimmt, dass die Gruppe eigentlich" ReadOnly" ist aber das Entfernen eines Mitglieds im Hintergrund nicht ausgeführt wird. In der alten Verwaltungsoberfläche konnte ich die Mitglieder dieser Gruppe nur anzeigen aber nicht bearbeiten. Hier hat Microsoft korrekt darauf verwiesen, dass die Gruppe synchronisiert wird.
Natürlich habe ich den gleichen Schritt per Powershell versucht, indem ich die Gruppe "AD-GSG" als Mitglied aus der "AD-GDG" entfernen wollte. Die Meldung habe ich so aber nicht erwartet:
PS C:\> Remove-MsolGroupMember : There was no endpoint listening at https://provisioningapi.microsoftonline.com/provisioningwebservice.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. At line:1 char:1 + remove-MsolGroupMember -GroupObjectId d96a4b32-173c-4a4f-8b60-376f2cc1d60b -Grou ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ + CategoryInfo : OperationStopped: (:) [Remove-MsolGroupMember], EndpointNotFoundException + FullyQualifiedErrorId : System.ServiceModel.EndpointNotFoundException,Mi crosoft.Online.Administration.Automation.RemoveGroupMember
Der Fehler scheint auch nicht temporär aufgrund einer Netzwerkverbindung aufzutreten. Alle andere Befehle funktionieren nämlich. Hier scheint die Remote Powershell einfach keinen passenden Fehler zu liefern. In diesem Fall muss es also nicht mehr ADSync richten, weil das Office 365 Admin Center es gar nicht kaputt macht, auch wenn es zuerst den Anschein hat.
Beachten Sie bitte: In AzureAD können Gruppen bis zu 100.000 Mitglieder haben. Allerdings kann ADSync nur maximal 50.000 Mitglieder replizieren.
"Office 365 Groups" - Gruppen
Der Name für eine neue Möglichkeit der Zusammenarbeit, "Office 365 Groups", kann schon zu Verwechslungen mit den normalen "Gruppen" führen. Im alten Admin Center war die Gruppe ebenfalls nicht von anderen "Cloud-Gruppen" zu unterscheiden:
Im neuen Admin Center sind diese Gruppen über einen anderen Typ erkennbar:
Auch die Eigenschaften sind schon etwas umfangreicher im neuen Admin Center:
Sie können hier auch editiert werden, auch wenn Sie im Rahmen der Einrichtung einer "Office 365 Group" angelegt wurden. Aktuell (Mrz. 2016) sind diese Gruppen aber nur in der Cloud vorhanden. Es gibt aber Hinweise, dass ADSync diese Gruppen samt Mitgliedern auch in ein On-Prem Active Directory replizieren kann. Allerdings ist dies nicht mit dem normalen Office 365 Azure AD zu erwarten
A subscription to Azure AD Premium is required for group
writeback
Quelle: More details about features in preview
https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-feature-preview/#group-writeback
Es geht also eher eine Zusatzfunktion der mit "Azure AD Premium" eh schon vorhandenen bidirektionalen Replikation.
Weitere Links
- ADSync - Group Matching
- Windows Gruppen
- ADSync und Public Folder
- Office 365 Groups
https://support.office.com/en-US/article/Office-365-Groups-3f780e8e-61aa-4287-830d-ff6209cbc192 - More details about features in preview
https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-feature-preview/#group-writeback - 2797931 How to Update contact information in Exchange Online in Office 365