RBAC for Applications mit Exchange Online

Application anlegen

Zuerst legen wir unter https://portal.azure.com eine neue Application Registration an. Hier brauche ich nur einen Namen.

Weitere Eingaben sind hier nicht erforderlich.

Entra ID API-Berechtigungen - NEIN!

Vergehen Sie hier keine weiteren Berechtigungen. Diese würden zusätzlich zu den später per RBAC zugewiesenen Rechten wirken.

Mit Graph ApplicationAccessPolicy haben wir früher einer App erst einmal die Berechtigungen für alle Postfächer gewährt um dann mit den ApplicationAccessPolicy diese Rechte wieder auf eine Teilmenge der Empfänger einzuschränken.

Da wir keine Berechtigungen vergeben, benötigen wir hier auch keinen Admin Consent.

App Secret anlegen

Damit sich die Application authentifizieren kann, müssen Sie entweder ein Kennwort von Entra ID generieren lassen. Ich bevorzuge die Anmeldung mittels Zertifikat. Dazu muss die Applikation einfach ein Zertifikat generieren (SelfSigned reicht) und die CER-Datei mit dem Public-Key in Entra ID hochgeladen werden.

Tipp: Zum Testen können sie ein eigenes "SelfSigned-Zertifikat auf ihrem PC anlegen und hochladen.

# Selbst signiertes Zertifikat erstellen
$appcert = New-SelfSignedCertificate `
              -Subject "CN=MSXFAQ_MGGraph" `
              -CertStoreLocation "Cert:\CurrentUser\My"  `
              -KeyExportPolicy Exportable  `
              -KeySpec Signature  `
              -KeyLength 2048  `
              -KeyAlgorithm RSA  `
              -HashAlgorithm SHA256 `
              -notafter (get-date).addyears(5)

#Thumbprint merken
$appcert.Thumbprint

# Als Datei exportieren
Export-Certificate `
   -Cert $appcert `
   -FilePath "MSXFAQ_MGGraph.cer" 

Merken sie sich den Thumbprint für später

• MGGraph PowerShell
• Graph und Kennworte
• New-SelfSignedCertificate
  https://learn.microsoft.com/en-us/powershell/module/pki/new-selfsignedcertificate

App ID einsammeln

Nun müssen wir drei Werte einsammeln. Zuerst brauchen wir die AppID der gerade angelegten Application. Dies ist der Benutzername zum gerade angelegten App Secret, welches die Anwendung zur Anmeldung benötigt.

Achtung:
Die ObjectID der App Registration ist nicht für die nächsten Schritte geeignet. Der Versuch damit ein ServicePrincipal anzulegen, wird mit einem Fehler quittiert:

Die App registration ist ein ggfls. global in allen Tenants sichtbares Objekt aber die Enterprise Registration ist das dazugehörige Tenant-lokale Objekt.

Für die weitere Einrichtung in Exchange zur Beschränkung des Zugriffs auf ausgewählte Postfächer benötigen wir die ObjectID aus der gleichnamigen "Enterprise Application", die ebenfalls angelegt wurde.

Jetzt könnte die App mit der AppID und dem Secret alle Postfächer lesen und Mails im Namen aller Personen senden.

Exchange Online PowerShell

Wir nutzen die Exchange Online PowerShell, um zur AppID und ObjectID einen ServicePrincipal anzulegen und dann über einen ManagementScope eine Rolle zuzuweisen.

Für diese Schritte gibt es keine GUI oder Weboberfläche.

In meinem Beispiel ist dies:

#Exchange Online PowerShell

# Anlegen eines Service Principal. AppID und ObjectID aus der EnterpriseApp übernehmen. 
# Der Name ist frei wählbar
$ServicePrincipal = New-ServicePrincipal `
                       -AppId 39dfb23e-a4cf-4867-bc5c-806edd54b5c7 `
                       -ObjectId 548565fb-49c6-4098-86ee-d70faf51a1d1 `
                       -DisplayName "MSXFAQ RBACApptest"

# Anlegen eines Management Scope, z.B. auf die Abteilung oder anderes Feld oder die ExchangeGUID der Mailbox
# Testen Sie den Scope vorher mit
Get-Mailbox -Filter "ExchangeGUID -eq 'a2b0a507-8180-4bca-a49a-f4b2a8a63dd4'"
New-ManagementScope `
   -Name "Scope MSXFAQ RBACApptest" `
   -RecipientRestrictionFilter "ExchangeGUID -eq 'a2b0a507-8180-4bca-a49a-f4b2a8a63dd4'"

# Beispiel mit der GUID
# Get-Mailbox -Filter "guid -eq '29a6e3a6-dc12-4de3-ad26-7a20a66af084'"
# New-ManagementScope `
#   -Name "Scope MSXFAQ RBACApptest" `
#   -RecipientRestrictionFilter "guid -eq '29a6e3a6-dc12-4de3-ad26-7a20a66af084'"

# Beispiel mit Memberof in einer Exchange Online Distributiongroup
# $groupdn= (Get-Distributiongroup Gruppenname).distinguishedname
# Get-Recipient -Recipient "MemberofGroup -eq '$($groupdn)'"
# New-ManagementScope `
#   -Name "Scope MSXFAQ RBACApptest" `
#   -RecipientRestrictionFilter "MemberofGroup -eq '$($groupdn)'"


# Verknüpfen des Scope mit der Application
New-ManagementRoleAssignment `
   -Role "Application Mail.ReadWrite" `
   -App $ServicePrincipal.ObjectID `
   -CustomResourceScope "Scope MSXFAQ RBACApptest"


# Verknüpfen des Scope mit der Application
New-ManagementRoleAssignment `
   -App $ServicePrincipal.ObjectID `
   -Role "Application Mail.Send" `
   -CustomResourceScope "Scope MSXFAQ RBACApptest"

Achtung:
Mehrfaches Ausführen von New-ManagementRoleAssignment addiert weitere Einträge. Es gibt keinen Fehler, weil es schon einen bestehenden identischen Eintrag gibt.

Eine Liste der Zuweisungen an eine App erhalten Sie über die ID des ServicePrincipal

Get-ManagementRoleAssignment `
   -RoleAssignee $ServicePrincipal.ID

Erst jetzt ist der Zugriff der App auf eine Mailbox beschränkt.

Hinweis:
Wie so oft werden die Beschränkungen nicht sofort aktiv. Insbesondere, wenn Sie vorher schon ohne Beschränkungen gearbeitet haben, nutzt Exchange einen Cache, um nicht bei jedem Zugriff alle Rechte zu ermitteln.

https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac#limitations

Verifikation

Microsoft hat extra ein CMDLet bereitgestellt, um die Beschränkungen der Zugriffe zu verifizieren. Ich muss nur die Application und das Zielpostfach kennen:

Test-ServicePrincipalAuthorization `
   -Identity <AppID> `
   -Resource <Zielobjekt üer DN, Mail Alias etc>

Der eine Benutzer ist Teil des Scope, während der andere Benutzer nicht im Scope enthalten ist. 

• Test-ServicePrincipalAuthorization (ExchangePowerShell)
  https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/test-serviceprincipalauthorization?view=exchange-ps

ServicePrincipal suchen

Auch für die bisherigen Graph ApplicationAccessPolicy benötigten wir ein Service-Principal in der Exchange PowerShell. So können Sie sehr einfach ermittel, welche App-Permissions vielleicht vergeben wurden.

ApplicationAccessPolicy suchen

Mit Get-ApplicationAccessPolicy finden Sie dann genau die Einschränkungen, die wie migrieren müssen

RecipientScope anlegen

Nun kommt die kniffligere Aufgabe. Sie müssen einen RecipientScope anlegen, der ihre aktuellen Filterung der ApplicationAccessPolicy entspricht. Meist haben Sie bei den ApplicationAccessPolicy eine Verteilergruppe als Skript genutzt. Das geht mit RBAC for Exchange Applications auch. Sie können aber auch andere Kriterien nutzen und so vielleicht auf die Gruppe verzichten. Wenn Sie weiter die vorhandene Gruppe nutzen, müssen Sie sich den DistinguishedName der Gruppe besorgen.

# DN einer gruppe holen
# $groupdn= (Get-Distributiongroup <Gruppenname>).distinguishedname
# Get-Recipient -Recipient "MemberofGroup -eq '$($groupdn)'"
# New-ManagementScope `
#   -Name "Scope MSXFAQ RBACApptest" `
#   -RecipientRestrictionFilter "MemberofGroup -eq '$($groupdn)'" 

Management Role Assignment

Dann weisen Sie die gewünschten Rechte mit dem Scope an den bestehenden Service Principal zu. Damit bekommt der ServicePrincipal die Rechte zusätzlich zu den noch vorhandenen globalen Rechten, die mit ApplicationAccessPolicy eingeschränkt sind

EntraID Rechte auf der App entfernen

Diese globalen und zu umfangreichen API-Permissions der Application entfernen wir z.B.: mit dem Entra ID Portal (https://entra.microsoft.com)

ApplicationAccessPolicy entfernen

Zuletzt entfernen wir noch die ApplicationAccessPolicy, die noch auf den Service Principal gebunden ist. Sie hat keine Funktion mehr, nachdem wir die ansonsten globalen Rechte im vorherigen Schritt entfernt haben.

Zugriff testen

Zuletzt sollten Sie die Application einmal Durchstarten, damit diese mit einem neuen Ticket und weniger Rechten unterwegs ist 

EntraID: AppRegistration mit Enterprise App löschen

Das geht einfach per Browser auf https://portal.azure.com. Wenn ich die App Registration zuerst lösche, dann ist auch die Enterprise Application gelöscht worden. Wenn ich die Enterprise App lösche, wurde die App Registration nicht gelöscht. Da muss ich dann manuell nachholen.

Mit dem Löschen der App Registration kann auch eine bereits angemeldete Application nicht mehr auf das Postfach zugreifen. 

Exchange Service Principal

Durch das Löschen in EntraID wird auch der Service Principal gelöscht.

ManagementRoleAssignment

Auch die Rollenzuweisung wird direkt mit beseitigt. Zumindest habe ich die Einträge nicht mehr finden können

ManagementScope

Der Scope wurde nicht gelöscht. Hier musste ich noch manuell tätig werden.

Remove-ManagementScope `
   -Name "Scope MSXFAQ RBACApptest"

Connect-MgGraph: ClientCertificateCredential authentication failed: 

Ich versuchte mich mit einer AppID anzumelden, die nicht vorhanden war. Bei der Menge an GUIDs kann man ja schon mal durcheinander kommen.

Get-MgUserMessage_List: Current authenticated context is not valid for this request. This occurs when a request is made to an endpoint that requires user sign-in. For example, /me requires a signed-in user. Acquire a token on behalf of a user to make requests to these endpoints. Use the OAuth 2.0 authorization code flow for mobile and native apps and the OAuth 2.0 implicit flow for single-page web apps.  

Meine Anmeldung als Application war erfolgreich aber ich hatte keine Berechtigungen auf das Postfach, weil das Role Assignment nicht vorhanden war

Meine App war angemeldet und danach habe ich die App Registration gelöscht. Der

Den Fehler sollten Sie normal nicht haben. Ich habe die App Registration in EntraID gelöscht und aus dem Papierkorb zurückgeholt. Dort sah dann alles gut aus, aber die Graph-Session hatte ein SAML-Token, welches vor dem Datum der Wiederherstellung gelegen hat. Meine App muss sich daher erst neu anmelden.

MAPI/RPC

Damit haben die ersten Outlook Versionen gearbeitet. Automatisierung war über eine lokale COM-API möglich.

RPC/HTTP - Outlook Anywhere

Zur Erreichbarkeit per HTTPS hat Microsoft "MAPI/RPC in HTTPS als Zwischenlösung eingepackt. Automatisierung war über eine lokale COM-API möglich.

MAPI/HTTP

Das ist das heute von "Classic Outlook" genutzte Protokoll. DAs "New Outlook" nutzt ein anderes Protokoll. Automatisierung war über eine lokale COM-API möglich.

ActiveSync/HTTP

Protokoll für mobiler Clients. Nicht als API für Entwicklungen nutzbar

EWS/HTTP

Die WebServices über HTTP ist für Exchange OnPremises das beste Protokoll aber wird in Exchange Online abgeschaltet. OnPremises können Sie Rechte pro Postfach geben oder mit EWS Impersonation arbeiten

Microsoft Graph API/HTTP

Mit Exchange Online ist die Rest-API das bevorzugte Protokoll

IMAP4/POP3/SMTPAuth

Exchange unterstützt natürlich auch die Internet-Standards, aber hier sind einige Funktionen nicht möglich. Sie sind daher Protokolle "zweiter Klasse"

SMTP Anonym

Sie können natürlich Mails per SMTP an ihrem Tenant einwerfen. Über entsprechende Inbound-Connectoren (Online) oder Einstellungen im Receive Connector (OnPremises) können Sie sogar anonym einige Berechtigungen zulassen. In der Regel geht es hier aber nur um die Zustellung um Mails an ihre eigenen Benutzer, die Sie aufgrund der SourceIP-Adressen beim Spamfilter besser behandeln.

MAPI/RPC

RPC/HTTP - Outlook Anywhere

MAPI/HTTP

ActiveSync/HTTP

EWS/HTTP

Microsoft Graph API/HTTP

IMAP4/POP3/SMTPAuth

SMTP Anonym