Examkin

Question

Difficulty: Very hardMulti-tenant Applications Configuration

An engineer is designing a background daemon service that synchronizes directory metadata across several external corporate Microsoft Entra ID tenants using the Microsoft Graph API. The service must operate with application-only permissions (`User.Read.All`), prevent consumer accounts (such as Outlook.com) from registering, and allow external tenant administrators to grant consent and run the sync process without user interaction.

Which configuration combination must be used to meet these requirements?

  1. A
    Manifest signInAudience: AzureADMyOrg; Admin consent endpoint: https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent; Token acquisition endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
  2. Manifest signInAudience: AzureADMultipleOrgs; Admin consent endpoint: https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent; Token acquisition endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/tokenAnswer
  3. C
    Manifest signInAudience: AzureADMultipleOrgs; Admin consent endpoint: https://login.microsoftonline.com/organizations/v2.0/adminconsent; Token acquisition endpoint: https://login.microsoftonline.com/organizations/oauth2/v2.0/token
  4. D
    Manifest signInAudience: AzureADandPersonalMicrosoftAccount; Admin consent endpoint: https://login.microsoftonline.com/common/v2.0/adminconsent; Token acquisition endpoint: https://login.microsoftonline.com/common/oauth2/v2.0/token

Answer

The configuration using 'AzureADMultipleOrgs' for signInAudience, combined with the tenant-specific endpoints for admin consent (https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent) and token acquisition (https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token).
Configuring the application with 'AzureADMultipleOrgs' ensures that only work or school accounts from Microsoft Entra ID can access the application, satisfying the requirement to prevent personal Microsoft accounts. For daemon applications that run in the background using application-only permissions (such as the client credentials flow), token acquisition requires a tenant-specific endpoint (containing the client's tenant ID or verified domain) because the identity provider cannot resolve the tenant context without an active user session. Similarly, administrative consent must be granted within a specific tenant context, requiring a tenant-specific admin consent endpoint.

Step-by-Step Solution

1
Determine the required client directory audience.
The application must support multi-tenant organizations but exclude personal Microsoft accounts, pointing to the 'AzureADMultipleOrgs' audience configuration.
The 'AzureADMultipleOrgs' signInAudience targets corporate directories while preventing consumer Microsoft accounts from authenticating.
2
Identify the endpoint required for tenant-wide administrative consent.
The consent URL must be directed to a tenant-specific endpoint: https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent.
Administrative consent for application permissions requires a specific target tenant ID or domain context to apply the permissions to that directory.
3
Select the appropriate token endpoint for the background synchronization service.
The background service must request tokens using the client credentials grant flow directed to the tenant-specific endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token.
The client credentials flow is a non-interactive flow that lacks a user context, meaning the generic /common or /organizations endpoints cannot resolve the target directory and will fail.

Key Concept

Multi-tenant daemon application configuration and endpoint routing in Microsoft Entra ID.
Rate this question

Topics

Multi-tenant Applications Configuration

More questions from this topic