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„:

Neue Sicherheitsgruppe im ECP anlegen

Name, Alias und Organisationseinheit auswählen. Achtet darauf, dass die ausgewählte Organisationseinheit auch im Azure AD Connect mit der Microsoft Cloud synchronisiert wird.

Am Ende müssen 3 Sicherheitsgruppen pro Postfach existieren.

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.