Tags: Exchange, Rechteverwaltung, PowerShell
In vielen Organisationen kommt Software zum Einsatz, welche Zugriff auf die Postfächer von Benutzern haben muss. In diesem Fall ist es vorteilhaft, die dafür nötigen Berechtigungen zentral zu vergeben. Exchange sieht dafür die Impersonation-Rolle (Identitätswechselrolle) vor, die im Namen der jeweiligen Benutzer agieren kann.
Ein Beispiel für Anwendungen, die Berechtigungen auf Exchange-Ressourcen benötigen, ist das klassische Dispatching, mit welchem der Einsatz und die Verfügbarkeit von Personal geplant werden. Die betreffende Software soll dann in der Lage sein, für die Terminverwaltung direkt in den Kalender des Users zu schreiben. Auch Lösungen für die Mail-Archivierung stellen ähnliche Anforderungen.
Optionen für die Vergabe von Berechtigungen
Grundsätzlich sieht Exchange drei Möglichkeiten vor, um Benutzer auf die Postfächer anderer User zu berechtigen:
- Ordnerberechtigungen, wenn man einem Benutzer Zugriff auf einen Ordner gewähren möchte, aber dieser nicht die Möglichkeit zu "Senden im Auftrag von" haben soll.
- Delegation, wenn ein Benutzer Arbeiten im Namen eines anderen Users ausführen soll (zum Beispiel eine Sekretärin, die den Kalender des Geschäftsführers verwaltet). Dies lässt sich mittels PowerShell auch zentral erledigen.
- Impersonation bei einer Dienstanwendung, die auf mehrere Postfächer zugreifen und als Besitzer des Postfachs agieren muss.
Für unsere Anforderung kann man eine Impersonation Role (Identitätswechselrolle) zentral auf dem Exchange-Server konfigurieren. Dies funktioniert sowohl unter Exchange on-prem als auch auf Exchange Online.
Aus Sicherheitsgründen wird man den Service-User nicht auf die komplette Organisation berechtigen. Davon wären dann nämlich automatisch auch kritische Positionen wie die des Geschäftsführers oder Betriebsrats betroffen. Stattdessen kann man die Identitätsrollen mit Filtern entsprechend justieren.
Identitätswechselrollen verwenden
Konfigurieren lässt die sich die Impersonation via Exchange PowerShell. Mit dem Cmdlet
Get-ManagementRoleAssignment -Role:ApplicationImpersonation
kann man zuerst prüfen, ob es bereits Identitätswechselrollen gibt.
Eine neue Identitätswechselrolle legt man mit folgendem Cmdlet an:
New-ManagementRoleAssignment -Role:ApplicationImpersonation `
-User: ServiceUser@rolandeich.onmicrosoft.com
Jetzt kann man die Berechtigungen des Service-Users mit dem Parameter RecipientTypeDetails weiter einschränken, in diesem Beispiel auf Räume:
New-ManagementScope -Name "ApplicationImpersonation-ServiceUser" `
-RecipientRestrictionFilter {RecipientTypeDetails -eq "RoomMailbox"}
Eine weitere Filterung wäre etwa auch auf alle User-Postfächer möglich:
RecipientRestrictionFilter "RecipientType -eq 'UserMailbox'"
Folgendes Beispiel zeigt die Einschränkung der Berechtigungen auf die Mitglieder einer Gruppe
New-ManagementScope "ApplicationImpersonation-ServiceUser" `
-RecipientRestrictionFilter `
"MemberOfGroup -eq '$($GroupDistinguishedName)'"
Weiterführende Informationen zu den Filtermöglichkeiten sind auf Microsoft Docs zu finden.
Wenn Sie allerdings planen, auf zu Exchange Online zu migrieren und on-prem Filter auf Organisationsebene oder direkt für Server erstellt haben, dann funktionieren diese in Exchange Online nicht, weil es dort keine OUs gibt.
Damit wäre die Konfiguration grundsätzlich abgeschlossen. In der Praxis kommt es aber oft vor, dass verschiedene Service-User auf Kalender zugreifen müssen. In diesem Fall ist es effizienter, die Berechtigungen an eine Gruppe zu erteilen, welche dann die Service-Benutzer enthält:
New-ManagementRoleAssignment -Name GroupImpersonation `
-Role ApplicationImpersonation -User SrvUsr@rolandeich.onmicrosoft.com `
-CustomRecipientWriteScope "ApplicationImpersonation-ServiceUser"
Alle Benutzer, welche Mitglied der Gruppe GroupImpersonation sind, dürfen damit auf die im ManagementScope enthaltenen User zugreifen.
Wer zum Abschluss die oben gesetzten Filter überprüfen möchte, kann dies mit
Get-ManagementScope
und
Get-ManagementRoleAssignment
tun.
Täglich Know-how für IT-Pros mit unserem Newsletter
Roland Eich ist gelernter Fachinformatiker für Systemintegration und in der IT seit über 14 Jahren zu Hause. Roland deckt aufgrund seiner Erfahrungen ein breites Spektrum der Microsoft-Produktpalette ab.Zudem besitzt er verschiedene Zertifizierungen (MCITP, MCSA und MCSE, ITIL, PRINCE2).
// Kontakt: E-Mail //
Verwandte Beiträge
- Namen und Größe der Ordner im Exchange-Postfach anzeigen mit PowerShell
- Neue Kalenderfunktionen in Exchange 2019: Besprechungen entfernen, Integration mit Abwesenheitsassistent
- Exchange 2016: Berechtigungen für öffentliche Ordner setzen mit PowerShell
- Adressbücher in Exchange Online anlegen und pflegen
- Ordner freigeben mit PowerShell
Weitere Links
1 Kommentar
Danke an Roland Eich für diesen Artikel. Kurz und knapp, gut erklärt.
An alle mitlesenden hier. Sofern jemand damit liebäugeln sollte ->
1. Stimmt dieses Vorgehen auf jeden Fall vorher mit Betriebsrat / Personalrat / Personalleitung / Datenschutzbeauftragen / Informationssicherheitsbeauftragten und natürlich Eurer IT-Leitung ab. Die müssen wissen was das konkret heißt, wenn so etwas zum Einsatz kommen soll.
2. Scope einschränken so weit es geht
3. Logging prüfen. Nicht nur der Einsatz ist wichtig. Auch das Logging dazu. Ihr wollt ja wissen, ob das eingesetzte funktioniert bzw. ob etwas gegen die Wand fährt.
Und zu guter Letzt, wobei man es eigentlich ganz oben platzieren könnte -> immer prüfen, ob man das gewollte Ziel, nicht auch ohne Impersonation hinbekommt.