ADSync - Gruppen matchen

Normalerweise verwalten Sie in der Cloud ihre "Cloud Gruppen" und mit dem Einsatz von ADSync kommen weitere Gruppen aus dem lokalen Active Directory hinzu. Mich hat interessiert, ob und wann Gruppen "gemachted" werden. Bei Benutzer ist dies ja initial der Fall, wenn das Feld "Mail" vorhanden ist. Dann wird ein "Cloud Only"-User zu einem "DirSync"-User. passiert dies auch mit Gruppen? Ein Szenario ist z.B. die Migration von Gruppen zwischen Domänen und insbesondere zwischen Forests mit ADMT.

Kurzfassung: ADSync matched Gruppen anhand des Felds "Mail". Andere Felder wie der SamAccountname, SIDs o.ä. sind nicht relevant und einen UPN gibt es bei Gruppen nicht.

Vorarbeit in Office 365

Es hat einiges an Vorarbeit und Versuche gekostet, die Funktion von ADSync und Office 365 zu verstehen und einen Grundsatz kann ich schon mal sagen:

Ohne Mailadresse matched erst einmal gar nichts.
Quelle: Frank Carius, MSXFAQ :-)

Nach allen Versuchen beschreibe ich hier erst nur die letzte Testreihe, die alle Erkenntnisse zusammenfasst. Ich habe zuerst in Office 365 vier Gruppen angelegt, die per GUI und Powershell angelegt werden können:

In der Office 365 Powershell sehen Sie noch mehr Eigenschaften. Hier ist insbesondere das "LastDirSyncTime"-Attribut interessant.

PS C:\> Get-MsolGroup -SearchString "Matchtest" | ft Displayname,LastDirSyncTime,CommonName,Object*,*mail* -AutoSize

DisplayName      LastDirSyncTime CommonName ObjectId                             EmailAddress
-----------      --------------- ---------- --------                             ------------
matchtest-MailSG                            5ab39b68-4d68-460e-a37e-9da58a7f0e46 matchtest-mailsg@uclabor.de
matchtest-o365                              b6a41d50-bb06-4da9-b2c5-e1ac44d0b8dd matchtest-o365@uclabor.de
matchtest-SG                                812c7611-16ba-42f7-bfc0-7c5013d42c31
matchtest-VL                                5cc29524-9855-4cb1-8a49-d055e2689b52 matchtest-vl@uclabor.de

Die Office 365 "Security Group" hat keine Mailadresse. Aus Sicht von Exchange Online sind aber nur zwei Gruppen aktiv.

PS C:\> Get-Recipient match* | ft name, recipienttype,emailaddresses

Name                                    RecipientType                           EmailAddresses
----                                    -------------                           --------------
Matchtest-MailSG                        MailUniversalSecurityGroup              {SMTP:matchtest-mailsg@uclabor.de}
Matchtest-VL                            MailUniversalDistributionGroup          {SMTP:matchtest-vl@uclabor.de}

Die Office 365 Gruppe erscheint leider nicht per Default hier. Dafür gibt es ein eigenes Commandlet.

PS C:\> Get-UnifiedGroup | fl name, recipienttype,emailaddresses

Name           : matchtest-o365_3d00699ad7
RecipientType  : MailUniversalDistributionGroup
EmailAddresses : {smtp:matchtest-o365@fcarius.onmicrosoft.com, SMTP:matchtest-o365@uclabor.de}

Es ist aktuell wohl nicht möglich die Gruppen einfach zu konvertieren. Die Commandlets "Enable-Distributiongroup" etc. gibt es in der Cloud nicht und eine einfache Office 365 Sicherheitsgruppe hat zwar das Feld "MailAddress. aber kann nicht gefüllt werden.

Gruppen im lokalen AD

Dann habe ich einfach analog dazu im lokalen Active Directory entsprechende Gruppen angelegt. Ich habe mich auf "Universelle" Gruppen beschränkt, da auch Office 365 quasi "universell" ist und wer mit mehreren Domains hantiert, wird Personen in der Regel in diesen Gruppen zusammenfassen.

Und dann habe ich den nächsten Lauf von ADSync abgewartet. Der lief auch erfolgreich und hat vier Gruppe aus dem lokalen AD importiert, abgeglichen und dann exportiert.

Beim "Delta Sync" war auch noch alles OK aber beim Schreiben in den Office 365 Tenant ist dann was schief gegangen:

Warum auch immer wollte der ADSync die Gruppe anlegen, aber Office 365 hat sich dagegen gesträubt, da es ja schon ein "gleichnamiges Objekt" gegeben hat. Das Feld "Mail" ist zurecht "doppelt". wenn ADSync denn eine neue Gruppe anlegen will. ADSync oder Office 365 schaffen es also nicht, eine "Office 365 Group" zu matchen. Alles andere scheint aber zu passen:

PS C:\> Get-MsolGroup -SearchString "Matchtest" | ft Displayname,LastDirSyncTime,CommonName,Object*,*mail* -AutoSize

DisplayName      LastDirSyncTime     CommonName       ObjectId                             EmailAddress
-----------      ---------------     ----------       --------                             ------------
matchtest-MailSG 05.12.2016 20:41:19 matchtest-MailSG 5ab39b68-4d68-460e-a37e-9da58a7f0e46 matchtest-MailSG@uclabor.de
matchtest-o365                                        b6a41d50-bb06-4da9-b2c5-e1ac44d0b8dd matchtest-o365@uclabor.de
matchtest-SG                                          812c7611-16ba-42f7-bfc0-7c5013d42c31
matchtest-SG     05.12.2016 20:41:19 matchtest-SG     37e27e1f-5680-4e43-a843-fdec5eaad2c7
matchtest-VL     05.12.2016 20:41:19 matchtest-VL     5cc29524-9855-4cb1-8a49-d055e2689b52 matchtest-VL@uclabor.de

Die drei anderen Gruppen, die mit einer SMTP-Adresse ausgestattet waren, wurden von ADSync im Ziel gefunden und in den Verzeichnisabgleich einbezogen. Da ich den "Konflikt" nicht gleich lösen konnte, hat mir Office 365 natürlich immer wieder die Warnungen zugesendet.

Diese Meldungen werden Sie aber ja schon kennen. Sie kommen übrigens im 30 Minuten Takt: So oft eben ADSync einen Abgleich startet. Wir können auf jeden Fall sehen, dass die beiden Gruppen nicht aufeinander Matchen und die Lösung aktuell darin besteht, die Mailadresse einer Gruppe zu ändern.

ADSync kennt eine Funktion "Group Writeback". In Verbindung mit Azure AD Premium wird dann für jede Office 365 Gruppe eine Verteilerliste im lokalen AD angelegt.

Ich habe daher als Test aus der Sicherheitsgruppe einen Verteiler gemacht. Es hat aber nichts geholfen. Es blieb beim "InvalidSoftMatch". Ich habe daher die lokale Gruppe "Matchtest-o365" entfernt um die Warnungen zu vermeiden und arbeite mit den anderen Gruppen erst einmal weiter.

Property: Beschreibung

Ab jetzt sind die Gruppen interessant, die durch den Verzeichnisabgleich "gematched" wurden. Hier gibt es wenige Felder in der Cloud die aber zum Teil durch Felder im lokalen Active Directory aktualisiert werden. Hier muss ich dann doch einmal schauen, was z.B. aus der Beschreibung wurde. Hier bietet sich die PowerShell natürlich an:

PS C:\> Get-MsolGroup -SearchString "Matchtest" | ft Displayname,LastDirSyncTime,CommonName,description -AutoSize

DisplayName      LastDirSyncTime     CommonName       Description
-----------      ---------------     ----------       -----------
matchtest-MailSG 05.12.2016 21:41:31 matchtest-MailSG matchtest-MailSG AD
matchtest-o365                                        Matchtest O365 Group
matchtest-SG                                          matchtest-SG
matchtest-SG     05.12.2016 20:41:19 matchtest-SG     matchtest-SG AD
matchtest-VL     05.12.2016 21:41:31 matchtest-VL     matchtest-VL AD

Schon hier ist auf den ersten Blick zu sehen, dass das Feld "Description" bei den drei Gruppen, die auch einen "LastDirSyncTime"-Wert tragen, durch das lokale Active Directory beschrieben wurden. Hier wurden also die Einstellungen, die ich vorher in der Cloud vorgenommen habe ohne Warnung überschrieben.

Property: EmailAddress

Das zweite Feld, welches ich genauer untersuchen will ist die Mailadresse. Hier erwartet mich eine Überraschung:

Der Inhalt des Felds "EMailAddress" hat sich bei der mailaktivierten Sicherheitsgruppe und der mailaktivierten Verteilergruppe geändert !

PS C:\> Get-MsolGroup -SearchString "Matchtest" | ft Displayname,LastDirSyncTime,CommonName,*mail* -AutoSize

DisplayName      LastDirSyncTime     CommonName       EmailAddress
-----------      ---------------     ----------       ------------
matchtest-MailSG 05.12.2016 21:41:31 matchtest-MailSG Matchtest-MailSG@fcarius.onmicrosoft.com
matchtest-o365                                        matchtest-o365@uclabor.de
matchtest-SG
matchtest-SG     05.12.2016 20:41:19 matchtest-SG
matchtest-VL     05.12.2016 21:41:31 matchtest-VL     Matchtest-VL@fcarius.onmicrosoft.com

Und das obwohl im lokalen On-Prem-AD weiterhin die richtige Adresse steht:

PS C:\> Get-ADGroup -LDAPFilter "(cn=match*)" -Properties mail | ft name,mail -autosize

name               mail
----               ----
matchtest-MailSG   matchtest-MailSG@uclabor.de
matchtest-SG
matchtest-VL       matchtest-VL@uclabor.de

Warum auch immer wird der Inhalt von "mail" aus dem lokalen AD nicht mit der Cloud synchronisiert. Ich habe dann die Mailadresse On-Premises noch einmal geändert und geschaut, ob dies nach dem nächsten Update etwas korrigiert. Ich habe im ADSync zwar gesehen, dass die geänderte Adresse aus dem lokalen AD per "Delta Export" exportiert und per "Delta Synchronisation" in das Metaverse repliziert wurde aber beim "Delta Export" in die Cloud wurde das Feld nicht gesetzt.

Mein Verdacht war, dass die Objekte in der Quelle eben noch keine "Exchange Objekte" waren und daher im Ziel nichts zu ändern war. Ein Kriterium für die Behandlung mit den Exchange Regeln ist der "Mailnickname", wie man in den SyncRules einfach erkennen kann.

Aber selbst nachdem ich den Wert gesetzt habe, wurden die lokalen Einstellungen noch nicht überschrieben.

Eine genauere Analyse mit einem lokalen Exchange und den entsprechenden Feldern steht noch aus.

Property: Member und Manager

Ein letztes wichtiges Feld steht noch aus. Ich habe bei den Office 365 Gruppen natürlich "vor" dem Match ein paar Mitglieder und auch Manager addiert und wollte sehen, was zumindest mit den Gruppen passiert, die beim Abgleich gematched wurden. Ich habe daher in der Cloud einen Benutzer zum "Mitglied" gemacht und auch den Besitzer gesetzt:

Gruppe vor dem Match Mitglieder O365 Mitglieder AD Besitzer O365 Besitzer  AD

Mailaktivierte Sicherheitsgruppe

CloudUser1

ADUser1

CloudUser2

ADUser2

Verteilergruppe

CloudUser1

ADUser1

CloudUser2

ADUser2

Damit sollte ich auch erkennen, was bei einem Match mit diesen Eigenschaften bei den Gruppen passiert, die synchronisiert werden. Nach dem Match ergab sich folgendes Bild:

Gruppe nach dem Match Mitglieder O365 Mitglieder AD Besitzer O365 Besitzer AD

Mailaktivierte Sicherheitsgruppe

ADUser1

ADUser1

CloudUser2
ADUser2

ADUser2

Verteilergruppe

ADUser1

ADUser1

ADUser2

ADUser2

Die Änderungen sind ein Stück weit irritierend, da z.B. die Mitglieder in den Office 365 Gruppen durch die Mitglieder aus der AD-Gruppe ersetzt werden. Das macht ja soweit noch Sinn, damit z.B. ein Mailverteiler auch in beiden Welten synchron ist. Das bedeutet aber wieder einmal, dass "Cloud Only"-User nicht wirklich für den Betrieb ratsam sind und nur für Administratoren und Dienste genutzt werden sollten, die nicht von einer Gruppe abhängig sind.

Anders sieht es bei dem Manager aus, hier werden die Einträge "gemerged", d.h. die vorher in der Cloud zugewiesenen Manager bleiben erhalten. Selbst ein "Full Sync" bereinigt hier nichts. Die Manager aus dem lokalen AD werden einfach an die Cloud-Gruppen zusätzlich eingetragen. Das kann zu einem Problem werden, wenn Sie sich die Details einer solchen Gruppe einmal anschauen:

Durch den Abgleich mit ADSync werden die Gruppen in der Cloud nicht mehr editierbar. Alle Änderungen müssen On-Premises erfolgen. Wie löschen Sie aber einen Eintrag beim "Besitzer", wenn Sie diesen Eintrag On-Prem gar nicht haben? Sie können nur den "Cloud Only" User auch On-Prem anlegen und mit dem DirSync ebenfalls "matchen" lassen und dann versuchen den als Manager im AD zu addieren und nach dem Sync zu löschen.

Bei mir hat ein "FullSync" die Situation bereinigt bzw. eine Änderung des Managers nach aktiviertem Sync. Es scheint, dass nur beim ersten "Match" ein Merge der Besitzer erfolgt.

Oder sie löschen einfach die Gruppe in der Cloud indem Sie diese in der Quelle löschen oder aus dem Verzeichnisabgleich ausfiltern und legen Sie danach wieder korrekt an. Das Problem dabei dürfte dann aber sein, dass die Gruppe in der Cloud eine neue ObjectID hat und vielleicht die in SharePoint und anderswo vergebenen Berechtigungen nicht mehr greifen. Das habe ich noch nicht weiter untersucht.

Löschen

Als letzte Aktion habe ich natürlich eine Gruppe On-Premises gelöscht. Wie nicht anders zu erwarten, wurde die Gruppe dann auch in der Cloud umgehend und ohne weitere Rückfrage entfernt. Soweit hat mich das dann nicht mehr überrascht.

Match-Table

Hier mal mal als Tabelle der Gruppen, die ich zuerst in Office 365 und danach im AD angelegt und repliziert habe:

Office365 On-Prem AD Match Ergebnis

Typ: Sicherheitsgruppe
Name: Matchtest

Typ: Universelle Security Group
SamAccountName: MatchTest

Kein Match

Es werden zwei Gruppen mit gleichem Gruppennamen angelegt.

Get-MsolGroup -SearchString "Matchtest" `
   | ft Displayname,LastDirSyncTime,CommonName,Object*,*mail* -AutoSize

DisplayName LastDirSyncTime     CommonName ObjectId                             EmailAddress
----------- ---------------     ---------- --------                             ------------
Matchtest                                  97185385-ac7a-4f3b-b245-9a542c47f04a
Matchtest   04.12.2016 17:02:45 Matchtest  fd0d120d-4f98-4ade-8d55-2d675cacb427

Typ: Mailaktivierte Sicherheitsgruppe
Name: Matchtest
Mail: matchtest@uclabor.de

Typ: Universelle Sicherheritsgruppe
SamAccountName: MatchTest
Mail: matchtest@uclabor.de

Match

Die Mailadresse ist in dem Fall der Schlüssel. Die AD-Quelle muss keinen Alias/MailNickName haben.

Get-MsolGroup -SearchString "Matchtest" `
   | ft Displayname,LastDirSyncTime,CommonName,Object*,*mail* -AutoSize

DisplayName LastDirSyncTime     CommonName EmailAddress
----------- ---------------     ---------- ------------
Matchtest   04.12.2016 17:29:29 Matchtest  Matchtest@uclabor.de

Typ: Mailaktivierte Verteilerliste
Name: Matchtest
Mail: matchtest@uclabor.de

Typ: Universelle Verteilerliste
SamAccountName: entfällt
Mail: Keine

Kein Match

Wird von ADSync zwar in das Metaverse repliziert aber nicht Richtung Office 365 exportiert.

Typ: Mailaktivierte Verteilerliste
Name: Matchtest
Mail: matchtest@uclabor.de

Typ: Universelle Verteilerliste
SamAccountName: entfällt
Mail: matchtest@uclabor.de

Match

AADConnect verbindet den Verteiler mit der vorhandenen Gruppe.

PS C:\> Get-MsolGroup -SearchString "Matchtest" `
   | ft Displayname,LastDirSyncTime,CommonName,*mail* -AutoSize

DisplayName LastDirSyncTime     CommonName EmailAddress
----------- ---------------     ---------- ------------
matchtest   04.12.2016 18:06:14 matchtest  matchtest@uclabor.de

Aber einige Minuten später hatte sich alleine die SMTP-Adresse geändert, obwohl im On-Prem AD immer noch matchtest@uclabor.de stand und keine Exchange Commandlets in der Cloud angewendet wurde. Es gibt in der Cloud wohl doch wieder ein "Provisioning".

PS C:\> Get-MsolGroup -SearchString "Matchtest" `
   | ft Displayname,LastDirSyncTime,CommonName,Object*,*mail* -AutoSize

DisplayName LastDirSyncTime     CommonName EmailAddress
----------- ---------------     ---------- ------------
matchtest   04.12.2016 19:06:23 matchtest  matchtest@fcarius.onmicrosoft.com

Selbst eine Erweiterung On-Prem mit dem passenden Alias/MailNickname hat nichts gebessert.

Typ: Office 365 Gruppe
Name: Matchtest-o365

Typ: Universelle Verteilerliste
SamAccountName: entfällt
Mail: matchtest-o365@uclabor.de

Kein Match

Identische SMTP-Adressen generieren einen DirSync-Fehler. Die AD-Gruppe wird in Office 365 als eigene Gruppe anlegt.

Sonderfall Replikationskonflikt

Einmal ist es mir bei der Testserie gelungen, dass zwei Gruppen mit gleicher Mailadresse angelegt wurden. Ich erkläre mir das derart, dass es auch in Office 365 entsprechende Replikationsverzögerungen gibt und der ADSync in dem Moment einen Service angesprochen hat, der von der anderen manuell angelegten Cloud-Onliy-Gruppe noch nichts wusste

PS C:\> get-msolgroup -SearchString matchtest | fl *

ExtensionData             : System.Runtime.Serialization.ExtensionDataObject
CommonName                : Matchtest
Description               : AD Description
DirSyncProvisioningErrors :
DisplayName               : Matchtest
EmailAddress              : Matchtest@uclabor.de
Errors                    :
GroupType                 : MailEnabledSecurity
IsSystem                  : False
LastDirSyncTime           : 02.12.2016 22:22:09
Licenses                  : {}
ManagedBy                 :
ObjectId                  : 8fc213f5-a669-403d-8fba-c796a6af818b
ProxyAddresses            : {smtp:Matchtest@fcarius.onmicrosoft.com, SMTP:Matchtest@uclabor.de}
ValidationStatus          : Error

ExtensionData             : System.Runtime.Serialization.ExtensionDataObject
CommonName                :
Description               :
DirSyncProvisioningErrors :
DisplayName               : Matchtest
EmailAddress              : Matchtest@uclabor.de
Errors                    :
GroupType                 : MailEnabledSecurity
IsSystem                  : False
LastDirSyncTime           :
Licenses                  : {}
ManagedBy                 :
ObjectId                  : ab5281c2-5bbd-4b94-80ab-904e4914ffee
ProxyAddresses            : {SMTP:Matchtest@uclabor.de}
ValidationStatus          : Healthy

Die aus dem AD übertragene Gruppe, erkennbar an der Beschreibung, hat den Validation Status "Error". Schaue ich in das Metaverse von ADSync, sehe ich genau die eine AD-Gruppe. aber keinen Hinweis auf ein Matching:

Wenn ich dann im lokalen AD nachträglich noch einen MailNickName eintrage, dann aktiviert ADSync diese Gruppe für Exchange, was aufgrund doppelten Adresse zu noch mehr Verwirrungen führt. Die defekte AD-Gruppe erscheint sogar kryptisch in Exchange. Diese Fehlersituation habe ich nicht weiter analysiert und durch Löschen der AD-Gruppe und einem Abgleich die Spuren entfernt.

Wir sollten festhalten, dass ADSync und AzureAD im Dezember 2016 noch keine Lösung für den Abgleich von lokalen AD-Gruppen mit bestehenden Gruppen im AzureAD hat und Konflikte sogar schwerwiegende Probleme bewirken können.

Immerhin wird bei so einer Gruppen dann auch das Feld ProxyAddresses bidirektional übertragen.

Hier sind die Vorboten von "Group Sync" schon zu sehen.

Zwischenstand

Microsoft entwickelt ADSync und Office 365 natürlich kontinuierlich weiter. Insofern können diese Ergebnisse nur als Momentaufnahme im Dezember 2016 angesehen werden.

  • AzureAD Gruppe kann noch nicht nachträglich zu einem Exchange Verteiler hochgestuft werden.
    Ich habe zumindest keinen Weg gefunden, wie ich einer AzureAD-Gruppe nachträglich für Exchange aktivieren kann. Das kann nur ADSync
  • "Matching" passiert nur, wenn die Exchange-Logik von ADSync durch einen Alias/Mailnickname und eine Mailadresse aktiviert wird
    Ansonsten legt ADSync stumpf eine neue Gruppe nebendran an, die sogar die gleiche Mailadresse haben kann, was in Exchange zu unschönen Effekten führt
  • Schlecht Karten für ADMT Migrationen
    Mit dem aktuellen Verhalten wird es schwer eine per ADSync von einem Forest synchronisierte Gruppe mit ADMT in einen anderen Forest zu verschieben. Wird dei Gruppe in der Quelle gelöscht, verschwindet auch die Gruppen in Office 365 und kann nicht zurück geholt werden. Bei Benutzern geht das mit "Get-MSOLUser -ReturnDeletedUsers". So einen Dumpster gibt es bei Gruppen aktuell nicht.
  • Replikation nur "outbound"
    Wenn ein Match stattfindet, dann gewinnen die Einstellungen der On-Prem-Gruppe bezüglich Displayname und Member aber nicht bezüglich Manager. Änderungen in der Cloud sind nach dem Match nur noch lokal möglich. Aber es kann sein, dass in der Cloud noch Einstellungen vorliegen (z.B. Manager), die vor dem Match erfolgt sind und die nie zurückrepliziert werden.
  • Berechtigungen
    Ich stelle mir zudem die Frage, woran Office 365 nun die Berechtigungen von Gruppen fest macht. Gerade das ist ja bei einer Konsolidierung von Gruppen über Forests hinweg ein wichtiges Thema. Ich kann eine Gruppe mit ADMT samt Mitglieder On-Prem migrieren, aber wen ADSync die Gruppe in der Cloud dann einfach löscht und neu anlegt, dann sind in der Cloud die Rechte weg.

Wer immer Gruppen in der Cloud verwendet, sollte daher genau protokollieren, wo welche Gruppen eingesetzt werden.

Weitere Links