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.

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