Table of Contents
Use App Properties to Restrict Sign-In Audiences for Applications
Entra applications come in two forms: single- and multi-tenant. Most applications created within a tenant, such as those created to allow the use of Graph application permissions, are single-tenant, meaning that Entra allows the application only to run in its home tenant. To facilitate their use by the widest possible audience, applications created by Microsoft and ISVs are usually multi-tenant. In this case, the application (aka a registered app) is controlled by the home tenant, and a service principal represents the application in host tenants.
Lack of knowledge about what application settings do is one of the reasons why it’s a terrible idea to let users create applications. It’s all too easy for someone to create an application that could end up being the entry point for hackers into a tenant. The number of attacks on Microsoft 365 tenants through apps means that keeping an eye on the apps in a tenant and the permissions assigned to those apps has become a critical management task.
Restricting Access to Multi-Tenant Applications
Until recently, multi-tenant applications were open to use by any tenant. If you know the application identifier, you can create a service principal in your tenant, assign whatever permissions are necessary to the service principal, and run the application. Sometimes a multi-tenant application should be restricted to a set of host tenants, and that’s what a new feature called sign-in audience restrictions does by allowing application owners to define the set of tenants permitted to run the application. The feature is in beta and is currently managed through Graph APIs rather than the Entra admin center.
An Example Application
Let’s take the example of the application I created to find large items in Exchange Online mailboxes. I purposely created the application to be multi-tenant (Figure 1).
If you have a single-tenant application that you want to be multi-tenant, you can amend the setting in the Authentication section of the application properties or in PowerShell. Running the Update-MgApplication cmdlet like this amends an application’s sign-in audience to be multi-organization:
Update-MgApplication -ApplicationId '2493c2e6-e0ac-4c5b-9d46-a191914fa54b' -SignInAudience "AzureADMultipleOrgs"
Updating Applications to Restrict Sign-In Audiences
You need to know several pieces of information before you can restrict the sign-in audience for an application:
- The application identifier (to create a service principal in the host tenants).
- The application object identifier (to update the application settings).
- The tenant identifier for each tenant permitted to run the application.
First, update the application settings to create the list of permitted tenants. In this example I define an array containing a single tenant identifier and then create a hash table to hold the request body required to update the settings with the tenant list. When everything is ready, run the Update-MgBetaApplication cmdlet to update the application:
# Array of Entra ID tenants allowed to access the app
[array]$AllowedTenantIds = "22e90715-3da6-4a78-9ec6-b3282389492b", "72f988bf-86f1-41af-91ab-2d7cd011db47","91c369b5-1c9e-439c-989c-1867ec606603","fe3af2c1-e762-4b62-ad3b-e3f1ed5dd0a0", "68583590-5a71-4642-a292-9ce7980bcdd3"
$SignInAudienceRestrictions = @{}
$SignInAudienceRestrictions.Add("@odata.type","#microsoft.graph.allowedTenantsAudience")
$SignInAudienceRestrictions.Add("isHomeTenantAllowed", "true")
$SignInAudienceRestrictions.Add("allowedTenantIds", $AllowedTenantIds)
$Body = @{}
$Body.Add("signInAudience", "AzureADMultipleOrgs")
$Body.Add("signInAudienceRestrictions", $SignInAudienceRestrictions)
# Use ObjectId not clientId to update the app
$ObjectId = '8868296e-81d1-4ca4-b63a-635c8d42998d'
Update-MgBetaApplication -ApplicationId $ObjectId -BodyParameter $Body
I can’t find a documented limit for the number of tenant identifiers supported by the allowedTenantAudience resource type. Given the usual Graph limitations, I suspect that the value is relatively low. As shown above, we know that at least five tenants work! For large-scale ISV applications, protection against unauthorized access is likely delivered by other means.
To check that the SignInAudienceRestrictions property holds the correct value, retrieve it using the Invoke-MgGraphRequest cmdlet.
$Uri = ("https://graph.microsoft.com/beta/applications/{0}?`$Select=SignInAudienceRestrictions,SignInAudience,displayName" -f $AppId)
$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get
$Data.SignInAudienceRestrictions
Name Value
---- -----
allowedTenantIds {22e90715-3da6-4a78-9ec6-b3282389492b, 72f988bf-86f1-41af-91ab-2d7cd011db47, 91c369b5-1c9e-439c-989c-1867ec606603, fe3af2c1-e762-4b62-ad3b-e3f1ed…
@odata.type #microsoft.graph.allowedTenantsAudience
kind allowedTenants
isHomeTenantAllowed True
Creating a Service Principal in a Host Tenant
Next, go to each of the host tenants permitted to run the application and create a service principal using the application identifier:
New-MgServicePrincipal -AppId 'd224fa41-4c2a-4380-b688-31625f90207a' DisplayName Id AppId SignInAudience ----------- -- ----- -------------- --- FindLargeMailboxItems 2f5aed8b-e121-4d94-9876-d41c300db3da d224fa41-4c2a-4380-b688-31625f90207a AzureADMultipleOrgs
If you make a mistake, remove the service principal as follows and rerun the command to create the service principal:
Remove-MgServicePrincipal -ServicePrincipalId 2f5aed8b-e121-4d94-9876-d41c300db3da
Resetting Sign-In Audience Restriction
To reset the allowed tenants to just the home tenant, populate the array of permitted tenants with the identifier for the home tenant and create the hash table for the request body, and rerun the Update-MgBetaApplication cmdlet shown above. You cannot use an empty array as the update fails if at least one tenant identifier is not present.
$TenantId = (Get-MgOrganization).Id [array]$AllowedTenantIds = $TenantId
Attempts to create or use the service principal for the app in a host tenant fail after the update because the tenant identifier is not in the allowed tenants list, In effect, the application now behaves like a single-tenant application because the home tenant is the only entry in the permitted list.
New-MgServicePrincipal -AppId $AppId New-MgServicePrincipal_CreateExpanded: Application d224fa41-4c2a-4380-b688-31625f90207a settings does not allow ServicePrincipal creation in 22e90715-3da6-4a78-9ec6-b3282389492b tenant due to SignInAudienceRestrictions configuration.
To revert to unrestricted access, change the @odata.type setting in the request body to “#microsoft.graph.unrestrictedAudience” and update the application settings as shown below:
$SignInAudienceRestrictions = @{}
$SignInAudienceRestrictions.Add("@odata.type","#microsoft.graph.unrestrictedAudience")
$Body = @{}
$Body.Add("signInAudience", "AzureADMultipleOrgs")
$Body.Add("signInAudienceRestrictions", $SignInAudienceRestrictions)
Update-MgBetaApplication -ApplicationId $ObjectId -BodyParameter $Body
Any of the operations to update application properties require the Application.ReadWrite.All permission.
Sign-in Audience Restriction for Applications is a Good Thing
Given the current state of threat, any additional control over Entra applications is a good thing. The application property lock feature is another example. Being able to restrict the sign-in audience for an application to specific tenants makes a heap of sense.
Need help to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.