Dieser Artikel erläutert, wie Sie die E-Mail-Versandberechtigungen einer Anwendungsregistrierung auf ein einzelnes Postfach einschränken.
Dieses Skript konfiguriert rollenbasierte Zugriffskontrolle (RBAC) in Exchange Online für Anwendungen, die in Microsoft Entra ID (ehemals Azure Active Directory) registriert sind. Standardmäßig kann eine Entra ID-Anwendung, der E-Mail-Berechtigungen erteilt wurden, auf jedes Postfach in Ihrer Organisation zugreifen. Dieses Skript beschränkt jede Anwendung mithilfe der modernen RBAC-Funktion für Anwendungen in Exchange Online auf ein einzelnes, festgelegtes Postfach – als Ersatz für den älteren, veraltetenApplicationAccessPolicy-Ansatz.
Das Skript ist vollständig idempotent, das heißt, es kann mehrfach ausgeführt werden, ohne unerwünschte Nebeneffekte zu verursachen. Bei jedem Durchlauf erkennt es bereits erstellte Ressourcen und verwendet diese erneut. Es eignet sich daher sowohl für die erstmalige Bereitstellung als auch für die laufende Wartung, wenn neue Anwendungen hinzugefügt werden.
Voraussetzungen
Überprüfen Sie vor der Ausführung des Skripts folgende Punkte:
PowerShell-Modul Das ModulExchangeOnlineManagement muss installiert sein. Falls es nicht vorhanden ist, installieren Sie es, indem Sie folgenden Befehl in einer erhöhten PowerShell-Sitzung ausführen:
Install-Module -Name ExchangeOnlineManagement -ForceBerechtigungen Das Konto, mit dem das Skript ausgeführt wird, muss über globale Administratorrechte verfügen oder eine delegierte Exchange Online-Administratorrolle besitzen, die das Erstellen und Verwalten von Dienstprinzipalen, Verwaltungsbereichen und Verwaltungsrollenzuweisungen erlaubt.
Entra ID-Anwendungsregistrierung Jede Anwendung muss bereits in Entra ID registriert sein. Sie benötigen zwei Bezeichner für jede Anwendung – beide sind zu finden unterEntra ID → Unternehmensanwendungen (nicht unter App-Registrierungen):
Anwendungs-ID (Client-ID) – auf der Übersichtsseite der Unternehmensanwendung als „Anwendungs-ID" aufgeführt.
Objekt-ID – auf derselben Seite als „Objekt-ID" aufgeführt.
Keine Graph-API-Berechtigungen in Entra ID erteilen Sie dürfen der Anwendung über Entra IDkeine Berechtigungen wiemail.send,Mail.Read oder ähnliche Microsoft Graph-Anwendungsberechtigungen erteilen. Der in diesem Skript verwendete Exchange Online RBAC-Ansatz macht solche Graph-Berechtigungen überflüssig, und die gleichzeitige Vergabe beider Berechtigungsarten kann zu Konflikten führen. Die Berechtigungsverwaltung erfolgt ausschließlich über dieses Skript.
Zielpostfächer Jede Anwendung muss über ihreprimäre SMTP-Adresse einem vorhandenen Postfach zugeordnet werden. Proxy- oder Aliadressen funktionieren nach der Einrichtung weiterhin als gültige Absenderadressen, die Bereichskonfiguration muss jedoch die primäre Adresse referenzieren.
Schritt 1 — Skript herunterladen und öffnen
Laden SieInvoke-ExoRBACForEntraIDApp.ps1 herunter und öffnen Sie es in einem Text-Editor oder in PowerShell ISE/VS Code.
Schritt 2 — Anwendungsliste konfigurieren
Suchen Sie das Array$appConfigs im oberen Bereich des Skripts (ab etwa Zeile 30). Dies ist der einzige Abschnitt, den Sie bearbeiten müssen. Es enthält einen Eintrag pro Anwendung. Ersetzen Sie die Platzhalterwerte durch Ihre tatsächlichen Anwendungsdetails.
Jeder Eintrag hat folgende Struktur:
@{ DisplayName = "Your App Name" AppId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # Application ID from Enterprise Applications ObjectId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # Object ID from Enterprise Applications AllowedMailbox = "mailbox@yourdomain.com" # Primary SMTP address of the target mailbox}Fügen Sie so viele Einträge hinzu, wie Sie benötigen – einen Block pro Anwendung. Um beispielsweise zwei Anwendungen zu konfigurieren:
$appConfigs = @( @{ DisplayName = "CRM Mail Sender" AppId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" ObjectId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" AllowedMailbox = "crm-sender@yourdomain.com" }, @{ DisplayName = "Helpdesk Notifications" AppId = "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy" ObjectId = "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy" AllowedMailbox = "helpdesk@yourdomain.com" })Schritt 3 — Testpostfach festlegen
Suchen Sie ebenfalls im oberen Bereich des Skripts folgende Zeile (etwa Zeile 52):
$testUnauthorizedMailbox = "administrator@company.com"Ändern Sie diese Angabe in ein beliebiges vorhandenes Postfach Ihrer Organisation, dasnicht alsAllowedMailbox für eine Ihrer konfigurierten Anwendungen eingetragen ist. Das Skript verwendet diese Adresse für einen negativen Autorisierungstest – um zu bestätigen, dass keine Ihrer Anwendungen auf Postfächer zugreifen kann, auf die sie keinen Zugriff haben sollte.
Schritt 4 — Zugewiesene Exchange Online-Rollen prüfen
Das Skript weist jeder Anwendung standardmäßig zwei Exchange Online-Rollen zu (etwa ab Zeile 55):
$ExoAppRoles = @( "Application Mail.Send", "Application Mail.ReadWrite")Wenn eine Anwendung lediglich E-Mails versenden und nicht auf das Postfach lesen oder schreiben muss, können Sie"Application Mail.ReadWrite" aus dieser Liste entfernen, um dem Prinzip der minimalen Rechtevergabe zu entsprechen. Nehmen Sie diese Änderung vor der Ausführung des Skripts vor.
Schritt 5 — Skript ausführen
Öffnen Sie eine erhöhte PowerShell-Sitzung und führen Sie das Skript aus:
.\Invoke-ExoRBACForEntraIDApp.ps1Das Skript stellt sofort eine Verbindung zu Exchange Online her – Sie werden aufgefordert, sich mit Ihren Administratoranmeldeinformationen anzumelden. Nach erfolgreicher Verbindung verarbeitet es automatisch jede Anwendung in Ihrer$appConfigs-Liste.
Was das Skript für jede Anwendung ausführt
Das Skript verarbeitet jeden Anwendungseintrag in fünf Schritten:
Schritt 1 — Dienstprinzipal erstellen oder überprüfen Das Skript prüft, ob in Exchange Online bereits ein Dienstprinzipal für dieObjectId der Anwendung vorhanden ist. Falls nicht, wird mithilfe vonNew-ServicePrincipal ein neuer erstellt. Dadurch wird die Entra ID-Anwendung mit Exchange Online verknüpft.
Schritt 2 — Verwaltungsbereich erstellen oder überprüfen Es wird ein Verwaltungsbereich mit einem Empfängerfilter erstellt, der auf dasAllowedMailbox der Anwendung verweist. Der Bereich wird nach der KonventionScope-Mailbox-{mailboxprefix} benannt (z. B.Scope-Mailbox-helpdesk fürhelpdesk@yourdomain.com). Falls ein passender Bereich bereits vorhanden ist, wird er wiederverwendet.
Schritt 3 — Exchange Online-Rollen zuweisen Für jede Rolle in$ExoAppRoles prüft das Skript, ob bereits eine Rollenzuweisung für die Kombination aus dieser Anwendung, Rolle und diesem Bereich besteht. Falls nicht, wird eine neueManagementRoleAssignment erstellt, die auf den in Schritt 2 erstellten Postfachbereich beschränkt ist. Die Anwendung kann diese Rollen somit nur gegenüber dem festgelegten Postfach ausüben.
Schritt 4 — Positiver Autorisierungstest Das Skript ruftTest-ServicePrincipalAuthorization auf, um zu bestätigen, dass die Anwendung für ihrAllowedMailbox als autorisiert aufgeführt ist. Eine grüne✓ PASS-Meldung bestätigt, dass die Berechtigung aktiv ist. Eine gelbe Warnung bedeutet, dass die Berechtigungen möglicherweise noch nicht vollständig übertragen wurden – warten Sie einige Minuten und führen Sie das Skript erneut aus.
Schritt 5 — Negativer Autorisierungstest Das Skript ruftTest-ServicePrincipalAuthorization für das$testUnauthorizedMailbox auf, um zu bestätigen, dass die Anwendung dort keinen Zugriff hat. Eine grüne✓ PASS-Meldung bestätigt, dass die Anwendung korrekt gesperrt ist. Ein rotes✗ FAIL bedeutet, dass die Anwendung unerwarteten Zugriff auf dieses Postfach hat und die Konfiguration überprüft werden sollte.
Ausgabe interpretieren
Am Ende des Durchlaufs gibt das Skript eine Zusammenfassung in der Konsole mit zwei Tabellen aus:
Verwendete Verwaltungsbereiche – listet alle Bereichsnamen und deren Empfängerfilter auf und zeigt, auf welches Postfach jeder Bereich verweist.
Rollenzuweisungen für konfigurierte Anwendungen – listet alle Rollenzuweisungen für Ihre Anwendungen auf, einschließlich Rollenname, Anwendungs-ID und angewendetem benutzerdefiniertem Ressourcenbereich.
Die Konsolenausgabe ist durchgehend farblich kodiert:
Cyan – allgemeine Fortschrittsüberschriften
Grün – erfolgreiche Erstellung oder bestandener Test
Grau – Ressource war bereits vorhanden (keine Aktion erforderlich)
Gelb – Warnung (z. B. Berechtigungen werden möglicherweise noch übertragen)
Rot – Fehler oder fehlgeschlagener Test, der Aufmerksamkeit erfordert
Fehlerbehebung
Autorisierungstest zeigt unmittelbar nach der Ausführung FAIL an Exchange Online-Rollenzuweisungen können einige Minuten benötigen, bis sie vollständig übertragen sind. Warten Sie 2–5 Minuten und führen Sie das Skript erneut aus. Das idempotente Design stellt sicher, dass dabei keine doppelten Ressourcen erstellt werden.
Fehler „Dienstprinzipal konnte nicht erstellt werden" Vergewissern Sie sich, dass die eingegebeneObjectId aus dem BereichUnternehmensanwendungen in Entra ID stammt und nicht aus App-Registrierungen. Es handelt sich dabei um unterschiedliche Bezeichner.
Anwendung hat weiterhin Zugriff auf nicht autorisierte Postfächer Stellen Sie sicher, dass der Anwendung in Entra ID keine Graph-API-Anwendungsberechtigungen wiemail.send oderMail.ReadWrite erteilt wurden. Solche Berechtigungen gelten organisationsweit und umgehen die RBAC-Bereichssteuerung von Exchange Online. Entfernen Sie diese Berechtigungen aus den API-Berechtigungen der Anwendung in Entra ID.
Fehler „Modul nicht gefunden" Führen SieInstall-Module -Name ExchangeOnlineManagement -Force in einer erhöhten PowerShell-Sitzung aus und wiederholen Sie den Vorgang.
Referenz
Weitere Hintergrundinformationen zur anwendungsbezogenen RBAC in Exchange Online finden Sie in der offiziellen Microsoft-Dokumentation:https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac