Graph ApplicationAccessPolicy (Legacy)

Diese Seite beschreibt den sicheren Zugriff einer als Hintergrundservice laufenden Applikation auf Postfächern von Benutzern in Exchange Online und Microsoft Graph. Die besondere Funktion einer "ApplicationAccessPolicy" gibt es aktuell (Stand Mail 2025) nur für Exchange Daten.

Achtung: Diese Funktion ist mittlerweile "Legacy" und wird irgendwann abgeschaltet.
Nutzen Sie stattdessen die Konfiguration mittels RBAC for Applications mit Exchange Online.


Quelle: https://learn.microsoft.com/en-us/exchange/permissions-exo/application-access-policies

Servicezugriff mit Exchange

Bei fast allen Firmen gibt es die Herausforderung, dass nicht nur Anwender auf ihre Daten sondern auch Dienste, Hintergrundprozesse oder Automatisierungen mit den Daten der Anwender arbeiten müssen. Das klassische Beispiel ist ein "Terminmanagement", d.h. eine Software möchte für den Anwender den Kalender pflegen. Denken Sie an Servicekräfte, die mit dem Smartphone und vielleicht einer F3-Lizenz unterwegs sind und eine zentrale Disposition möchte Termine in den Postfächern dieser Personen verwalten. Dabei muss natürlich sichergestellt sein, dass dieser Service nicht alle Postfächer einsehen kann und auch nur Termine verwaltet.

Wie müssen daher überlegen, wie ich einer Identität, d.h. einer Application oder einem Service genau die Berechtigungen erteilt, die er benötigt. Dazu gibt es mehrere verschiedene Wege:

Verfahren Beschreibung

Delegate

Die Applikation läuft im Prozessraum und mit den Rechten des Anwender. Diesen Wege kennen wir schon viele Jahre und wird z.B. von Outlook AddOns oder anderen Diensten genutzt, die auf dem Client des Anwenders einfach mit gestartet werden. Der Server im Hintergrund konnte nicht wirklich unterscheiden, welche Applikation nun den Zugriff durchführt. So ein Code, der per MAPI, EWS oder Outlook-API das Postfach bearbeitet hat, konnte "wie der Anwender" agieren.

Erst mit Microsoft Graph erwartet Graph auch eine AppID, welche zusätzlich berechtigt werden kann. So kann eine Software die vom Anwender gestartet werden, nicht gleich alles machen, was der Anwender darf, sondern nur eine Teilmenge.

Dieser Weg bedeutet aber, dass der Anwender aktiv werden muss, um die Software lokal zu starten oder über Webtechniken ein entsprechenden Access Token an einen Service zu übergeben. Da solche Tokens nur eine gewisse Zeit gültig sind, ist dies keine Lösung für einen "Hintergrundbetrieb"

Dienstkonto und Stellvertreter oder Impersonate

Mit Exchange OnPremises konnte der Administrator ein Dienstkonto anlegen, welches dann separat berechtigt wurde. Auch da gab es verschiedene Wege:

  • "Full Access" über die Datenbank auf alle Postfächer (Rechte auf Postfächer)
    Sehr weitreichende Rechte aber viele Jahre lang sehr oft in gebrauch
  • Full Access auf einzelne Postfächer
    Damit konnte man so einem Dienstkonto auf ausgewählte Postfächer limitieren.
  • EWS und Impersonation
    Über EWS konnte so ein Konto ebenfalls "Full Access" bekommt. Eine Beschränkung auf eine Gruppe von Posträchern ist über einen Scope, z.B. OU, Gruppenmitgliedschaften o.ä. möglich.

EWS funktioniert aber nur noch mit OnPremises. In Exchange Online ist EWS für Okt 2026 abgekündigt. Für OnPremises ist es aber auch weiterhin der primäre Zugriff für automatisierte Prozesse auf Postfächer.

Denken Sie aber daran, dass solche Dienstkonten sich meist mit "Username/Kennwort" anmelden und damit Conditional Access oder starke Anmeldeverfahren schwerer umzusetzen sind.

AppPermission

In Exchange Online ist aber die Graph API die Zukunft und hier kann ich eine Applikation anlegen, die mit einem Secret (Kennwort oder Zertifikat) sich gegen EntraID authentifiziert und dann ohne Mithilfe des Anwender oder Administrators an die Informationen kommt, für die er berechtigt ist. Die App-Identity kann sich ohne MFA anmelden aber kann nur die Rechte nutzen, die der Applicatoin zugewiesen wurden.

 

App Rechte in Entra ID

Bei der Definition der Application in Entra ID können Sie sehr genau Berechtigungen delegieren. Ich habe hier eine BeispielApp, der ich verschiedene Berechtigungen gegeben habe. So sollte es bei ihnen natürlich NICHT aussehen

 

Die App könnte sich, rot umrandet, per IMAP mit allen Postfächern meines Tenants verbinden und, solange es noch geht, wäre auch ein Zugriff per EWS möglich. Aber auch die grün umrandeten Berechtigungen gewähren der Applikation sehr umfangreiche Berechtigungen.

Ohne weitere Vorkehrungen könnte meine App nun dank "Mail.ReadWrite" auf alle Postfächer alle Elemente lesen und verändern

Das ist ist so natürlich nicht erwünscht. Es ist nur zu verständlich, das eine Firma eine Beschränkung des Zugriffs auf eine Gruppe von Postfächern für die jeweilige Application einrichten möchte.

ApplicationAccessPolicy

Eine Applikation kann durchaus die Rechte zur Pflege der Termine bei den Mitarbeitern im Service bekommen, um damit eine Einsatzplanung zu steuern. Auch der Versand von Mails "als Anwender" kann ein gültiger Anwendungsfall sein. Aber die App sollte dann auch nur mit einer Teilmenge der Adressen senden können. Wem das zu viel ist, sollte sich die Funktion "ApplicationAccessPolicy" einmal genauer anschauen. Damit kann ein Administrator eine App anhand der GUID auf eine Gruppen von Anwendern beschränken:

# Anlegen einer Policy und Zuweisung an eine Gruppe
# Hinweis: Es kann durchaus eine Stunde oder länger dauern, bis dies aktiv wird.
New-ApplicationAccessPolicy `
   -AppId <guid der app> `
   -PolicyScopeGroupId <Mailadresse oder Identity einer Gruppe> `
   -AccessRight RestrictAccess `
   -Description "Restrict this app to members of distribution group."

Achten Sie aber darauf, dass dies eine Filterfunktion von Exchange ist, die den Zugriff über Graph zusätzlich kontrolliert.

Bei Exchange werden nur folgende Rechte geprüft:

Mail.Read
Mail.ReadBasic
Mail.ReadBasic.All
Mail.ReadWrite
Mail.Send
MailboxSettings.Read
MailboxSettings.ReadWrite
Calendars.Read
Calendars.ReadWrite
Contacts.Read
Contacts.ReadWrite

Sie können damit also nur die vier Bereiche an sich unterscheiden und auch nur beim Zugriff per Microsoft Graph

Achtung:
Wenn Sie, wie im Beispiel, auch das Recht "IMAP.AccessAsApp" gewährt haben, dann kann eine Applikation über dieses Protokoll alle Inhalte auf allen Postfächern ihres Tenants lesen!

Rechte auf Elemente oder Ordner?

Sie haben aber auch gesehen, dass ich nun eine App auf eine gewisse Gruppen von Postfächern auch unterschiedliche Rechte nach Elementen, d.h. Mail, Kontakte, Termine, geben kann. ich kann aber keine Unterscheidung auf einzelne Ordner oder sogar Elemente in Ordnern machen. Auch Exchange selbst schon mit ACLs auf Ordner und theoretisch auch auf Elementen arbeiten kann, gibt es keine Möglichkeit eine App dahingehend noch einzugrenzen.

Eine App-Permission beinhaltet also schon ein Vertrauen des Administrators in die App, dass Sie keinen Unfug betreibt. Sie kann zwar zumindest über Graph und in Bezug auf Exchange Postfächer hinsichtlich der drei Hauptelemente (Mail, Termin, Kontakt) beschränkt werden aber nicht auf einzelne Ordner oder gar Elemente im Postfach.

Andere Apps

Wenn sie nun erwarten, dass es ähnliche Möglichkeiten auch z.B. bei SharePoint, Teams und all den anderen per Graph erreichbaren Datentöpfen gibt, dann muss ich Sie enttäuschen. Eine solche Filterung von Zugriffen habe ich für andere Dienste noch nicht gesehen.

Diese Information kann sich täglich ändern. Wenn Sie irgendwo eine neue Information gefunden haben, dann senden Sie mir doch einen Link

Weitere Links