Data & More
Original

Begræns mailudsendelse til én postkasse

6 min læsning19. apr. 2026

Begræns mailudsendelse til én postkasse Denne artikel forklarer, hvordan man begrænser en applikationsregistrerings tilladelser til at sende mail til én enkelt postkasse. Dette script

Denne artikel forklarer, hvordan man begrænser en applikationsregistrerings tilladelser til at sende mail til én enkelt postkasse.

Dette script konfigurerer rollebaseret adgangskontrol (RBAC) i Exchange Online for applikationer, der er registreret i Microsoft Entra ID (tidligere Azure Active Directory). Som standard kan en Entra ID-applikation, der er tildelt mailtilladelser, tilgå alle postkasser i organisationen. Dette script begrænser hver enkelt applikation til én bestemt postkasse ved hjælp af den moderne RBAC for Applications-funktion i Exchange Online — som erstatter den ældre, forældedeApplicationAccessPolicy-tilgang.

Scriptet er fuldt idempotent, hvilket betyder, at det er sikkert at køre flere gange. Ved hvert kørsel vil det registrere og genbruge ressourcer, der allerede er oprettet, hvilket gør det velegnet til både den indledende udrulning og løbende vedligeholdelse, når nye applikationer tilføjes.

Forudsætninger

Bekræft følgende, inden scriptet køres:

PowerShell-modul ModuletExchangeOnlineManagement skal være installeret. Hvis det ikke er installeret, kan det installeres ved at køre følgende i en udvidet PowerShell-session:

Install-Module -Name ExchangeOnlineManagement -Force

Tilladelser Den konto, der anvendes til at køre scriptet, skal enten være global administrator eller have en delegeret Exchange Online-administratorrolle med rettigheder til at oprette og administrere tjenesteprincipper, administrationsscopees og administrationstildelinger.

Entra ID-applikationsregistrering Hver applikation skal allerede være registreret i Entra ID. Der er behov for to identifikatorer for hver app — begge findes underEntra ID → Enterprise Applications (ikke App Registrations):

  • Applikations-id (klient-id) — vises som "Application ID" på oversigtssiden for Enterprise Application.

  • Objekt-id — vises som "Object ID" på samme side.

Tildel ikke Graph API-tilladelser i Entra ID Der måikke tildelesmail.send,Mail.Read eller lignende Microsoft Graph-applikationstilladelser til applikationen via Entra ID. Den Exchange Online RBAC-tilgang, som dette script anvender, gør disse Graph-niveau-tildelinger overflødige, og tildeling af begge kan medføre konflikter. Tilladelser håndteres udelukkende af dette script.

Målpostkasser Hver applikation skal knyttes til en eksisterende postkasse ved hjælp af densprimære SMTP-adresse. Proxy-/aliasadresser vil fortsat fungere som gyldige afsenderadresser efter opsætningen, men scopekonfigurationen skal referere til den primære adresse.

Trin 1 — Download og åbn scriptet

DownloadInvoke-ExoRBACForEntraIDApp.ps1 og åbn det i et tekstredigeringsprogram eller PowerShell ISE/VS Code.

Trin 2 — Konfigurer applikationslisten

Find arrayet$appConfigs nær toppen af scriptet (starter omkring linje 30). Dette er det eneste afsnit, der skal redigeres. Det indeholder én post pr. applikation. Erstat pladsholdernes værdier med de faktiske applikationsoplysninger.

Hver post følger denne 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}

Tilføj så mange poster, der er behov for — én blok pr. applikation. For eksempel, for at konfigurere to applikationer:

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

Trin 3 — Angiv testpostkassen

Ligeledes nær toppen af scriptet, find følgende linje (omkring linje 52):

$testUnauthorizedMailbox = "administrator@company.com"

Skift denne til en hvilken som helst eksisterende postkasse i organisationen, derikke er angivet somAllowedMailbox for nogen af de konfigurerede apps. Scriptet anvender denne adresse til at udføre en negativ autorisationstest — for at bekræfte, at ingen af applikationerne kan tilgå postkasser, de ikke har adgang til.

Trin 4 — Gennemse de tildelte Exchange Online-roller

Scriptet tildeler som standard to Exchange Online-roller til hver applikation (omkring linje 55):

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

Hvis en applikation kun har behov for at sende mail og ikke har behov for at læse eller skrive til postkassen, kan"Application Mail.ReadWrite" fjernes fra denne liste for at følge princippet om mindste privilegium. Foretag denne ændring inden scriptet køres.

Trin 5 — Kør scriptet

Åbn en udvidet PowerShell-session og kør scriptet:

.\Invoke-ExoRBACForEntraIDApp.ps1

Scriptet opretter straks forbindelse til Exchange Online — De vil blive bedt om at logge ind med Deres administratoroplysninger. Når forbindelsen er etableret, behandles hver applikation i$appConfigs-listen automatisk.

Hvad scriptet gør for hver applikation

Scriptet behandler hver applikationspost i fem trin:

Trin 1 — Opret eller bekræft tjenesteprincippen Scriptet kontrollerer, om der allerede findes en tjenesteprincip i Exchange Online for applikationensObjectId. Hvis den ikke eksisterer, oprettes den ved hjælp afNew-ServicePrincipal. Dette knytter Entra ID-appen til Exchange Online.

Trin 2 — Opret eller bekræft administrationsscopet Der oprettes et administrationsscoppe med et modtagerfilter, der peger på applikationensAllowedMailbox. Scopet navngives efter konventionenScope-Mailbox-{mailboxprefix} (f.eks.Scope-Mailbox-helpdesk forhelpdesk@yourdomain.com). Hvis der allerede findes et matchende scope, genbruges dette.

Trin 3 — Tildel Exchange Online-roller For hver rolle i$ExoAppRoles kontrollerer scriptet, om der allerede findes en rolletildeling for denne kombination af app, rolle og scope. Hvis ikke, oprettes en nyManagementRoleAssignment afgrænset til det postkassescope, der blev oprettet i trin 2. Det betyder, at applikationen kun kan udøve disse roller over for den angivne postkasse.

Trin 4 — Positiv autorisationstest Scriptet kalderTest-ServicePrincipalAuthorization for at bekræfte, at applikationen er angivet som inden for scope for densAllowedMailbox. En grøn✓ PASS-meddelelse bekræfter, at tilladelsen er aktiv. En gul advarsel betyder, at tilladelserne muligvis endnu ikke er propageret — vent et par minutter og kør scriptet igen.

Trin 5 — Negativ autorisationstest Scriptet kalderTest-ServicePrincipalAuthorization mod$testUnauthorizedMailbox for at bekræfte, at applikationen ikke har adgang hertil. En grøn✓ PASS-meddelelse bekræfter, at applikationen er korrekt blokeret. En rød✗ FAIL betyder, at applikationen har uventet adgang til den pågældende postkasse, og at konfigurationen bør gennemgås.

Forståelse af outputtet

Ved afslutningen af kørslen udskriver scriptet en oversigt i konsollen med to tabeller:

Administrationsscopees i brug — viser alle scopenavne og deres modtagerfiltre, samt hvilken postkasse hvert scope peger på.

Rolletildelinger for konfigurerede apps — viser alle rolletildelinger for applikationerne, herunder rollenavn, app-id og det anvendte brugerdefinerede ressourcescope.

Konsoloutputtet er farvekodet gennem hele kørslen:

  • Cyan — generelle statusoverskrifter

  • Grøn — vellykket oprettelse eller bestået test

  • Grå — ressourcen eksisterede allerede (ingen handling nødvendig)

  • Gul — advarsel (f.eks. at tilladelser muligvis stadig propageres)

  • Rød — fejl eller mislykket test, der kræver opmærksomhed

Fejlfinding

Autorisationstesten viser FAIL umiddelbart efter kørsel Rolletildelinger i Exchange Online kan tage nogle minutter at propagere. Vent 2–5 minutter og kør scriptet igen. Det idempotente design sikrer, at der ikke oprettes duplikerede ressourcer.

Fejlen "Failed to create Service Principal" Bekræft, at det angivneObjectId stammer fraEnterprise Applications-bladet i Entra ID og ikke fra App Registrations. Disse er forskellige identifikatorer.

Appen har stadig adgang til postkasser, den ikke burde have Sørg for, at der ikke er tildeltmail.send- ellerMail.ReadWrite-Graph API-applikationstilladelser til applikationen i Entra ID. Sådanne tildelinger gælder for hele organisationen og omgår Exchange Online RBAC-afgrænsning. Fjern dem fra applikationens API-tilladelser i Entra ID.

Fejlen "Module not found" KørInstall-Module -Name ExchangeOnlineManagement -Force i en udvidet PowerShell-session, og prøv derefter igen.

Reference

For yderligere baggrundsinformation om Exchange Online-applikations-RBAC henvises til den officielle Microsoft-dokumentation:https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac