Data & More
Original

Begränsa e-postutskick till en enda postlåda

6 min läsning19 apr. 2026

Begränsa e-postutskick till en enda postlåda Den här artikeln förklarar hur ni begränsar en appregistrerings behörighet att skicka e-post till en enda postlåda. Det här skriptet

Den här artikeln förklarar hur ni begränsar en appregistrerings behörighet att skicka e-post till en enda postlåda.

Det här skriptet konfigurerar rollbaserad åtkomstkontroll (RBAC) i Exchange Online för program som registrerats i Microsoft Entra ID (tidigare Azure Active Directory). Som standard kan ett Entra ID-program som beviljats e-postbehörigheter komma åt samtliga postlådor i er organisation. Skriptet begränsar varje program till en enda, angiven postlåda med hjälp av den moderna funktionen RBAC för program i Exchange Online — som ersätter den äldre, inaktuellaApplicationAccessPolicy-metoden.

Skriptet är helt idempotent, vilket innebär att det är säkert att köra flera gånger. Vid varje körning identifierar det redan skapade resurser och återanvänder dessa, vilket gör det lämpligt både för initial driftsättning och löpande underhåll när nya program läggs till.

Förutsättningar

Kontrollera följande innan ni kör skriptet:

PowerShell-modul Modulen ExchangeOnlineManagement måste vara installerad. Om ni inte har den kan ni installera den genom att köra följande i en upphöjd PowerShell-session:

Install-Module -Name ExchangeOnlineManagement -Force

Behörigheter Det konto som används för att köra skriptet måste vara global administratör eller ha en delegerad Exchange Online-administratörsroll med rättigheter att skapa och hantera tjänsthuvudnamn (Service Principals), hanteringsomfång (Management Scopes) och rolltilldelningar (Management Role Assignments).

Entra ID-appregistrering Varje program måste redan vara registrerat i Entra ID. Ni behöver två identifierare för varje program — båda finns i Entra ID → Företagsprogram (inte Appregistreringar):

  • Program-ID (klient-ID) — visas som "Program-ID" på översiktssidan för företagsprogrammet.

  • Objekt-ID — visas som "Objekt-ID" på samma sida.

Bevilja inte Graph API-behörigheter i Entra ID Ni får inte bevilja mail.send, Mail.Read eller liknande Microsoft Graph-programbehörigheter till programmet via Entra ID. Den Exchange Online RBAC-metod som används av det här skriptet gör sådana Graph-nivåbehörigheter onödiga, och att bevilja båda kan orsaka konflikter. Behörighetshanteringen sköts uteslutande av det här skriptet.

Målpostlådor Varje program måste mappas till en befintlig postlåda med hjälp av dess primära SMTP-adress. Proxy- och aliasadresser fungerar fortfarande som giltiga avsändaradresser efter konfigurationen, men omfångskonfigurationen måste referera till den primära adressen.

Steg 1 — Ladda ned och öppna skriptet

Ladda ned Invoke-ExoRBACForEntraIDApp.ps1 och öppna det i en textredigerare eller PowerShell ISE/VS Code.

Steg 2 — Konfigurera programlistan

Leta upp matrisen $appConfigs i början av skriptet (med start runt rad 30). Det är det enda avsnittet ni behöver redigera. Det innehåller en post per program. Ersätt platshållarvärdena med era faktiska programuppgifter.

Varje post följer den här strukturen:

@{    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}

Lägg till så många poster ni behöver — ett block per program. Om ni till exempel vill konfigurera två program:

$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"    })

Steg 3 — Ange testpostlådan

Leta också upp följande rad i början av skriptet (runt rad 52):

$testUnauthorizedMailbox = "administrator@company.com"

Ändra detta till valfri befintlig postlåda i er organisation som inte är angiven som AllowedMailbox för något av era konfigurerade program. Skriptet använder den här adressen för ett negativt auktoriseringstest — för att bekräfta att inget av era program kan komma åt postlådor de inte ska ha tillgång till.

Steg 4 — Granska tilldelade Exchange Online-roller

Skriptet tilldelar som standard två Exchange Online-roller till varje program (runt rad 55):

$ExoAppRoles = @(    "Application Mail.Send",    "Application Mail.ReadWrite")

Om ett program endast behöver skicka e-post och inte behöver läsa från eller skriva till postlådan kan ni ta bort "Application Mail.ReadWrite" från listan för att följa principen om minsta möjliga behörighet. Gör den här ändringen innan ni kör skriptet.

Steg 5 — Kör skriptet

Öppna en upphöjd PowerShell-session och kör skriptet:

.\Invoke-ExoRBACForEntraIDApp.ps1

Skriptet ansluter omedelbart till Exchange Online — ni uppmanas att logga in med era administratörsuppgifter. När anslutningen är upprättad behandlar det automatiskt varje program i er $appConfigs-lista.

Vad skriptet gör för varje program

Skriptet behandlar varje programpost i fem steg:

Steg 1 — Skapa eller verifiera tjänsthuvudnamnet (Service Principal) Skriptet kontrollerar om ett tjänsthuvudnamn redan finns i Exchange Online för programmets ObjectId. Om det inte finns skapas ett med hjälp av New-ServicePrincipal. Detta kopplar samman Entra ID-programmet med Exchange Online.

Steg 2 — Skapa eller verifiera hanteringsomfånget (Management Scope) Ett hanteringsomfång skapas med ett mottagarfilter som riktar sig mot programmets AllowedMailbox. Omfånget namnges enligt konventionen Scope-Mailbox-{mailboxprefix} (t.ex. Scope-Mailbox-helpdesk för helpdesk@yourdomain.com). Om ett matchande omfång redan finns återanvänds det.

Steg 3 — Tilldela Exchange Online-roller För varje roll i $ExoAppRoles kontrollerar skriptet om en rolltilldelning redan finns för kombinationen program + roll + omfång. Om inte skapas en ny ManagementRoleAssignment begränsad till det postlådeomfång som skapades i steg 2. Det innebär att programmet endast kan utöva dessa roller mot den angivna postlådan.

Steg 4 — Positivt auktoriseringstest Skriptet anropar Test-ServicePrincipalAuthorization för att bekräfta att programmet listas som inom omfånget för dess AllowedMailbox. Ett grönt ✓ PASS-meddelande bekräftar att behörigheten är aktiv. En gul varning innebär att behörigheterna eventuellt inte har propagerats ännu — vänta några minuter och kör om skriptet.

Steg 5 — Negativt auktoriseringstest Skriptet anropar Test-ServicePrincipalAuthorization mot $testUnauthorizedMailbox för att bekräfta att programmet inte har någon åtkomst där. Ett grönt ✓ PASS-meddelande bekräftar att programmet är korrekt blockerat. Ett rött ✗ FAIL innebär att programmet har oväntad åtkomst till den postlådan och att konfigurationen bör ses över.

Tolka utdata

I slutet av körningen skriver skriptet ut en sammanfattning i konsolen med två tabeller:

Hanteringsomfång i användning — listar alla omfångsnamn och deras mottagarfilter och visar vilken postlåda varje omfång riktar sig mot.

Rolltilldelningar för konfigurerade program — listar alla rolltilldelningar för era program, inklusive rollnamn, program-ID och det anpassade resursomfång som tillämpas.

Konsolens utdata är färgkodad genomgående:

  • Cyan — allmänna förloppsrubriker

  • Grön — lyckad skapelse eller ett godkänt test

  • Grå — resursen fanns redan (ingen åtgärd krävs)

  • Gul — varning (t.ex. att behörigheter fortfarande kan hålla på att propageras)

  • Röd — fel eller misslyckat test som kräver åtgärd

Felsökning

Auktoriseringstestet visar FAIL direkt efter körning Rolltilldelningar i Exchange Online kan ta några minuter att propagera. Vänta 2–5 minuter och kör om skriptet. Den idempotenta designen säkerställer att inga dubblerade resurser skapas.

Felet "Failed to create Service Principal" Kontrollera att det ObjectId ni har angett är hämtat från bladet Företagsprogram i Entra ID och inte från Appregistreringar. Det rör sig om olika identifierare.

Programmet har fortfarande åtkomst till postlådor det inte borde ha Kontrollera att inga Graph API-programbehörigheter av typen mail.send eller Mail.ReadWrite har beviljats programmet i Entra ID. Sådana behörigheter gäller för hela organisationen och kringgår Exchange Online RBAC-omfång. Ta bort dem från programmets API-behörigheter i Entra ID.

Felet "Module not found" Kör Install-Module -Name ExchangeOnlineManagement -Force i en upphöjd PowerShell-session och försök sedan igen.

Referens

För ytterligare bakgrundsinformation om programbaserad RBAC i Exchange Online, se Microsofts officiella dokumentation: https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac