Exchange Hybrid: Shared Mailbox Permissions
Praxis
Da wir nun geklärt haben, wie wir unsere Struktur aufbauen möchten, legen wir jetzt mit der Umsetzung los. Ich zeige euch die notwendigen Schritte zum besseren Verständnis anhand der grafischen Benutzeroberfläche (ECP). Es macht aber durchaus Sinn, die Vorgehensweise in der Exchange Management Shell zu automatisieren.
Vorgehensweise
AD-Gruppen anlegen
Im ersten Schritt müssen wir die drei AD-Gruppen anlegen. Hierfür erstellen wir über das Exchange Control Panel 3 zusätzliche Sicherheitsgruppen mit den entsprechenden Namen. Ich zeige euch das exemplarisch für die Gruppe „EXO_Verrechnung_FullAccess„:
![](https://schweigerstechblog.de/wp-content/uploads/ExchangeHybrid_PermissionGroups_02-1024x598.png)
Name, Alias und Organisationseinheit auswählen. Achtet darauf, dass die ausgewählte Organisationseinheit auch im Azure AD Connect mit der Microsoft Cloud synchronisiert wird.
Berechtigungsstruktur
Nun kommen wir zu einem Teil, der für viele auf den ersten Blick verwirrend sein mag – den Berechtigungen. Wir haben eingangs erwähnt, dass Berechtigungen und Exchange Attribute, die im Azure AD gesetzt werden, nicht in das lokale AD zurück synchronisiert werden. Daher ist es für uns wichtig, alle Änderungen lokal durchzuführen und sie mittels Azure AD Connect in die Cloud zu synchronisieren. Dieser Ansatz stimmt für 90% der Anwendungsgebiete, in diesem Fall ist es aber etwas anders. Ein kleiner Deep-Dive in die Art und Weise, wie ein Active-Directory mit den notwendigen Berechtigungen umgeht:
- Vollzugriff: Sie wird ausschließlich im Postfach gesetzt. Es wird kein Attribut im Active-Directory gesetzt – sie existiert ausschließlich in der Exchange Datenbank.
- SendOnBehalf: Dabei handelt es sich um eine Berechtigung, die im AD-Attribut „publicDelegates“ gespeichert wird. Glücklicherweise wird sie bereits vom Azure AD Connect bidirektional synchronisiert. Das bedeutet, dass sie sowohl am lokalen Exchange, als auch im Exchange Online Portal gesetzt werden kann und sie wird immer in das jeweils andere AD übernommen. Es muss nur sichergestellt werden, dass folgende Voraussetzungen erfüllt werden: Delegate can’t send on behalf of after migration – Exchange | Microsoft Docs
- Send-As: Sie wird als Sicherheitseinstellung am AD-Objekt gesetzt. Besitzt ein Benutzer „Send-As“ Berechtigungen auf einem Postfach, so wird im Security-Tab folgender Eintrag vergeben:
Das bedeutet für uns:
- „SendOnBehalf“ wird immer in beide Richtungen synchronisiert. Aus diesem Grund ist es egal, wo wir sie setzen.
- „Vollzugriff“ hingegen existiert nicht als AD-Attribut sondern eigens in der Exchange Datenbank. Da das Postfach bereits migriert worden ist, kann diese Permission auch ausschließlich im Exchange Online Portal gesetzt werden.
- „Send-As“ wiederum wird am AD-Objekt gespeichert. Wenn wir also die Einstellung in der Cloud setzen würden, würde diese Änderung unser lokales AD nicht mitbekommen. Somit würde sich der On-Premises Datenstand von jenem in der Cloud unterscheiden – das wollen wir verhindern. Damit die Verwirrung aber nun noch weiter zunimmt: Es reicht nicht aus, die „Send As“ Berechtigung ausschließlich im lokalen AD zu setzen – sie wird nicht in die Cloud synchronisiert. Wir müssen sie also sowohl lokal, als auch in der Cloud setzen. Das ist der einzige Weg, den Datenstand synchron zu halten.
Wer sich nun denkt, was das soll, hat nicht ganz unrecht. Und ja, das ist auch der offiziell vorgeschlagene Weg von Microsoft: Permissions in Exchange hybrid deployments | Microsoft Docs
Aktuell gibt es keine perfekte Lösung. Wir als Administratoren müssen mit den Mitteln arbeiten, die uns der Hersteller zur Verfügung stellt und in diesem Fall ist das leider so. Und genau aus diesem Grund empfehle ich die Verwendung von AD-Gruppen. Somit muss man diese Misere für jedes Postfach nur einmal durchleben und nicht jedes Mal, wenn ein neuer Benutzer Zugriff benötigt.
Ich kann auch durchaus nachvollziehen, wenn nun jemand sagt: „Das ist mir zu aufwendig, mir ist es egal, wenn die Datenstände auseinander laufen.“ Es ist technisch durchaus auch möglich, diese Vorgehensweise zu wählen, behaltet aber folgende Gedanken trotzdem im Hinterkopf:
- Vielleicht muss eure Exchange Organisation aus Compliance-Gründen (oder warum auch immer) irgendwann wieder auf einen On-Premises Exchange migriert werden. Bevor ihr das machen könnt, müsst ihr allerdings die Datenstände wieder in Einklang bringen. Je nachdem, wie viele Änderungen in der Zwischenzeit gemacht worden sind und wie groß eure Organisation tatsächlich ist, ist das ein sehr großer Aufwand.
- Es tritt ein Desaster-Recovery Fall ein und ihr müsst euer lokales AD aus einem früheren Backup wiederherstellen. Wie vereint ihr nun die unterschiedlichen Datensätze aus lokalem Backup und Azure AD? Ein Sync vom Azure AD in die On-Premises Umgebung ist aktuell noch nicht möglich.
- Der AD-Verzeichnisdienst bildet den Kern eurer IT-Infrastruktur. Ist es tragbar, dass manche Attribute nur im Azure AD existieren, andere wiederum im lokalen AD?
Auf der nächsten Seite schauen wir uns nun an, wie man die notwendigen Berechtigungen vergibt.
Super Erläuterung! Sowas hab ich schon lange gesucht.
Ich habe aber noch eine kleine Verständisfrage.
Ich habe eine FullAccess Gruppe in der lokalen AD angelegt. Diese wird via AD Connect synchronisiert. Muss ich die Nutzer für die Gruppe nun im EXO oder im OnPrem der Gruppe hinzufügen?
Freut mich zu hören, dass ich dir helfen konnte! 🙂 Also die Gruppe wurde lokal angelegt und die notwendigen Berechtigungen für Full-Access, SendAs und SendOnBehalf wurden gesetzt? Dann musst du die Gruppenmitgliedschaft immer in deinem lokalen AD pflegen und in die Cloud synchronisieren lassen. Es wird zwar zukünftig die Möglichkeit mittels GroupWriteback geben, auch Security Gruppen vom Azure AD zurück ins On-Premise AD zu synchronisieren, aktuell ist es aber noch nicht soweit. Außerdem ist es meiner Meinung nach einfacher, soweit als möglich immer alles lokal zu erledigen. So läuft man dann auch gar nicht in die Gefahr irgendwelche Änderungen nur… Weiterlesen »
Irgendwie klappt das bei mir nicht mehr. Nochmal zur Verständnis zur FullAccess vergabe. ohne Gruppe: Shared Mailbox lokal anlegen und via ADConnect syncen im EXO dem User FullAccess für die gesyncte Shared Mailbox geben mit Gruppe Shared Mailbox lokal anlegen Gruppe lokal anlegen User der Gruppe lokal hinzufügen Sync mit AD Connect Ich bin den zweiten weg gegangen (so wie bei dir beschrieben). Am Anfang war die Shared Mailbox auch bei mir im Outlook zu sehen und mit einmal ist diese wieder verschwunden. Ich stehe aber in der Gruppe als Mitglied drinnen (im ExOn und im OnPrem). Also vom Sync… Weiterlesen »
Hab jetzt mal bei einem 2ten Shared Mailbox, bei dem ich noch keine Security Group eingerichtet hatte, mich direkt als User via ExOn unter FullAccess eingetragen.
Die Shared Mailbox wird dann im Outlook angezeigt.
Deine angelegten Security Groups (bspw. jene für Full-Access) sind aber auch mail-enabled – sprich, sie besitzen eine SMTP Adresse oder?
Kannst du, wenn du die Permissions mittels Gruppen vergeben hast, das Shared Postfach manuell zu deinem User Postfach dazu hängen (also ohne AutoMapping)?