This chapter covers Entra ID Enterprise Applications, a core component of Microsoft's identity and access management (IAM) platform. You will learn what enterprise applications are, how they integrate with Entra ID for authentication and authorization, and the key features like single sign-on (SSO), provisioning, and application management. For the SC-900 exam, this topic appears in approximately 10-15% of questions under Domain 2.1, focusing on understanding the purpose and capabilities of enterprise applications in the context of identity management.
Jump to a section
Think of Entra ID Enterprise Applications as a hotel's key card system. The hotel (Entra ID) issues key cards to guests (users). Each card contains a digital token that specifies which rooms (applications) the guest can access. When a guest wants to enter a room, they swipe the card at the door (application). The door's reader checks the token against the hotel's central authorization database (Entra ID). If the token is valid and the guest is authorized, the door unlocks. Importantly, the hotel doesn't give out physical keys to every room; instead, it centrally manages access through the key card system. Similarly, Entra ID Enterprise Applications allow centralized management of authentication and authorization for SaaS apps, on-premises apps, and custom-developed apps. The hotel also supports single sign-on: a guest uses one key card to access multiple rooms (e.g., gym, pool, conference room) without needing separate keys. The hotel's registration desk (Azure AD) provisions and deprovisions access automatically when a guest checks in or out. If a guest loses their card, the hotel can revoke it instantly, preventing unauthorized access to all rooms. This mirrors how Entra ID Enterprise Applications handle identity provisioning, SSO, and access revocation.
What are Entra ID Enterprise Applications?
Entra ID Enterprise Applications (formerly Azure AD Enterprise Applications) is a service within Microsoft Entra ID that provides a centralized identity and access management (IAM) framework for applications used within an organization. It acts as an identity provider (IdP) and supports authentication and authorization for thousands of pre-integrated SaaS applications (e.g., Salesforce, Dropbox, Slack), custom-developed applications, and on-premises applications published via the Azure AD Application Proxy.
Enterprise applications are not the actual applications themselves; they are Entra ID service principals that represent the application in the directory. When you register an application in Entra ID, two objects are created: an application object (the global definition) and a service principal (the local representation in a specific tenant). The enterprise application blade in the Azure portal shows these service principals, allowing administrators to manage permissions, assign users, configure SSO, and set up provisioning.
Why Enterprise Applications Exist
Before cloud IAM, each application had its own user directory and authentication mechanism. Users had to remember multiple passwords, and IT had to manage accounts in silos. Entra ID Enterprise Applications solve this by providing a unified identity layer. Key benefits include: - Single Sign-On (SSO): Users authenticate once with Entra ID and gain access to all integrated applications without re-entering credentials. - Centralized User Provisioning: Automatically create, update, or deactivate user accounts in target applications based on identity lifecycle events in Entra ID. - Conditional Access: Apply policies based on user, device, location, and risk to control access to applications. - Auditing and Reporting: View sign-in logs, provisioning logs, and audit trails for all enterprise applications from a single pane.
How Enterprise Applications Work: The Authentication Flow
Entra ID supports several authentication protocols for enterprise applications. The most common are: - OAuth 2.0 / OpenID Connect (OIDC): Used for modern cloud applications. The flow involves: 1. User attempts to access an application (e.g., Salesforce). 2. Application redirects the user to Entra ID's authorization endpoint (https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize). 3. User authenticates with Entra ID (e.g., password, MFA, FIDO2). 4. Entra ID returns an authorization code to the application. 5. Application exchanges the code for an access token and optionally an ID token. 6. Application uses the access token to access resources on behalf of the user. - SAML 2.0: Used for many enterprise SaaS applications. The flow: 1. User accesses the application (Service Provider, SP). 2. SP generates a SAML authentication request and redirects the user to Entra ID (IdP). 3. User authenticates with Entra ID. 4. Entra ID generates a SAML assertion containing user attributes and signs it. 5. User is redirected back to SP with the assertion. 6. SP validates the assertion and grants access. - WS-Federation: Legacy protocol used with Active Directory Federation Services (AD FS) but also supported by Entra ID. - Password-based SSO: For applications that don't support federation. Entra ID stores the username and password securely and performs a form-fill on behalf of the user. - Linked SSO: Simple redirection to another IdP.
Key Components and Configuration
#### Application Registration vs. Enterprise Application When you register an application in the App Registrations blade, you create an application object that defines the application's global settings (e.g., redirect URIs, API permissions). The corresponding service principal is automatically created in the same tenant and appears in the Enterprise Applications blade. For multi-tenant applications, the service principal is created in each tenant where the application is consented to.
#### Single Sign-On Modes In the Enterprise Application settings, you can configure SSO mode: - SAML-based Sign-On: Requires configuration of SAML URLs, certificates, and attribute mapping. - OpenID Connect-based Sign-On: For apps registered with OIDC. - Password-based Sign-On: Entra ID stores credentials and uses a browser extension to fill forms. - Linked Sign-On: Redirects to another IdP. - Disabled: No SSO; user must sign in directly to the app.
#### User and Group Assignment By default, enterprise applications are set to "User assignment required?" = Yes. This means only users and groups explicitly assigned to the application can access it. You can assign users/groups from the "Users and groups" blade. If set to No, any user in the tenant can access the application (not recommended for security).
#### Provisioning
Entra ID can automate user account provisioning to enterprise applications using the System for Cross-domain Identity Management (SCIM) protocol. Steps:
1. Enable provisioning in the application's Provisioning blade.
2. Configure credentials (e.g., tenant URL, secret token) for the target app.
3. Define attribute mappings (e.g., map Entra ID attribute mail to app attribute email).
4. Set scope (sync all users/groups or only assigned).
5. Start provisioning. Entra ID will create, update, or deactivate user accounts based on changes in the directory.
Provisioning can be manual (on-demand) or automatic (scheduled, typically every 40 minutes by default).
#### Application Proxy For on-premises applications, Azure AD Application Proxy allows secure remote access without a VPN. It works by: 1. Deploying a connector agent on-premises that communicates outbound to Azure. 2. User accesses the app via an external URL (e.g., https://appproxy.contoso.com). 3. Entra ID authenticates the user and then passes the request to the connector. 4. Connector forwards the request to the internal application. 5. Response flows back through the same path.
Interaction with Related Technologies
Conditional Access: Conditional Access policies can target enterprise applications. For example, require MFA for all users accessing the Salesforce enterprise application.
Identity Protection: Risk events (e.g., leaked credentials) can be used to block access to enterprise applications.
Microsoft Defender for Cloud Apps: Can integrate with enterprise applications for session control, monitoring, and policy enforcement.
Azure AD B2B Collaboration: External users can be assigned to enterprise applications, enabling secure collaboration.
Default Values and Timers
Session timeout for SAML apps: Default is 8 hours, configurable via Conditional Access session controls.
Token lifetime: Access tokens default to 1 hour; refresh tokens up to 90 days of inactivity.
Provisioning interval: Automatic provisioning cycles run every 40 minutes by default, but can be adjusted.
Application Proxy connector port: Connectors use outbound TCP 443 (HTTPS) to Azure.
Configuration and Verification Commands
Using Microsoft Graph PowerShell:
# Get all enterprise applications in tenant
Get-MgServicePrincipal -All
# Get specific enterprise application by display name
Get-MgServicePrincipal -Filter "DisplayName eq 'Salesforce'"
# Assign a user to an enterprise application
New-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $sp.Id -PrincipalId $user.Id -AppRoleId $appRole.Id
# Configure SAML SSO for an enterprise application
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -PreferredSingleSignOnMode "saml"Using Azure CLI:
# List enterprise applications
az ad sp list --all
# Assign user to application
az ad app permission grant --id <appId> --api <resourceAppId> --scope <scope>The exam does not require memorizing commands but understanding the concepts is essential.
Register the Application in Entra ID
First, an administrator registers the application in the Azure portal under 'App registrations'. This creates an application object that defines the application's identity, including redirect URIs (where users are sent after authentication), supported account types (single tenant, multi-tenant, or personal Microsoft accounts), and API permissions. For example, a web app might have a redirect URI of https://myapp.contoso.com/signin-oidc. The application is assigned an Application (client) ID, a globally unique identifier. This step is the foundation for all subsequent integration.
Create the Service Principal
When the application is registered in a tenant, Entra ID automatically creates a service principal object in that tenant. The service principal represents the application in the tenant and is what appears in the 'Enterprise Applications' blade. It holds tenant-specific settings such as user assignments, SSO configuration, and provisioning settings. For multi-tenant applications, a service principal is created only when a user from another tenant consents to the application. The service principal has an object ID distinct from the application ID.
Configure Single Sign-On
In the Enterprise Application blade, the administrator selects the SSO mode. For SAML-based SSO, they download the SAML metadata or manually enter the identifier (Entity ID) and reply URL (Assertion Consumer Service URL) from the application. Entra ID generates a signing certificate (valid for 3 years by default) that the application uses to verify SAML assertions. The administrator also configures attribute claims (e.g., user.mail -> email) to be sent in the SAML token. For OIDC, the configuration is typically done in the app registration's 'Authentication' pane.
Assign Users and Groups
By default, user assignment is required. The administrator assigns users or groups to the enterprise application from the 'Users and groups' blade. Each assigned user or group must be mapped to an application role (e.g., 'User' or 'Admin'). If no app roles are defined, a default role is used. Only assigned users can access the application if assignment is required. For large organizations, groups are preferred for easier management. Dynamic groups can be used to automate membership based on user attributes.
Set Up Provisioning (Optional)
For applications that support SCIM, the administrator can enable automatic provisioning. This involves entering the tenant URL (e.g., https://salesforce.com/scim/endpoint) and a secret token. Entra ID then synchronizes user accounts from the directory to the application. The administrator can map attributes (e.g., mail -> email) and set the provisioning scope (e.g., only assigned users). Provisioning can be tested with a manual provisioning cycle before enabling automatic scheduling.
Test and Monitor Access
After configuration, the administrator tests access by signing in as an assigned user. They verify that SSO works, that attributes are correctly passed, and that provisioning created the user account in the target app. Monitoring is done via Entra ID sign-in logs, which show successful and failed authentication attempts. Provisioning logs show the status of user account synchronization. Conditional Access policies can be applied to the enterprise application for additional security (e.g., require compliant device).
Scenario 1: SaaS Application Integration (Salesforce)
A large enterprise with 10,000 employees uses Salesforce as its CRM. Previously, IT had to manually create and delete user accounts in Salesforce, and users had separate passwords. They deploy Entra ID Enterprise Applications to integrate Salesforce. The tenant admin registers the Salesforce gallery application (pre-integrated) from the Azure AD gallery. They configure SAML-based SSO using the metadata exchange, mapping Entra ID attributes (e.g., user.mail -> email, user.jobtitle -> title). They enable automatic provisioning using SCIM; the Salesforce tenant URL and an API token are entered. Provisioning is scoped to assigned users. They assign all sales users to a group called 'Salesforce Users' and assign that group to the app. Now, when a new salesperson is hired and added to the group, Entra ID automatically creates their Salesforce account within 40 minutes. When they leave, the account is deactivated. SSO eliminates password fatigue. Performance: provisioning cycles handle up to 100,000 users per cycle; for this 10,000-user org, it completes in minutes. Common pitfalls: misconfigured attribute mappings cause errors (e.g., missing required fields in Salesforce). The admin must carefully map all required attributes. Also, if the SCIM token expires, provisioning stops silently; monitoring alerts are essential.
Scenario 2: On-Premises Application via Application Proxy
A company has an internal HR application (e.g., SAP SuccessFactors on-premises) that remote employees need to access without VPN. They install the Application Proxy connector on a Windows server in the internal network. The connector registers with Azure AD and receives a certificate for mutual authentication. The admin publishes the internal app URL (e.g., http://hr.internal.contoso.com) as an enterprise application with external URL https://hr-proxy.contoso.com. They configure pre-authentication with Entra ID so that users must sign in with their corporate credentials and satisfy Conditional Access policies (e.g., MFA). Users access the external URL, authenticate, and the connector forwards traffic to the internal server. The connector maintains persistent outbound connections to Azure, so no inbound firewall changes are needed. Performance: each connector handles up to 2,000 concurrent connections; for high availability, multiple connectors are deployed. Common issues: connector certificates expire (renew automatically if possible), or the internal application uses Kerberos delegation, requiring proper configuration of Kerberos constrained delegation (KCD) on the connector server.
Scenario 3: Custom Line-of-Business Application with OIDC
A development team builds a custom .NET Core web app that needs to authenticate users via Entra ID. They register the app in App Registrations, set the redirect URI to https://app.contoso.com/signin-oidc, and grant permissions to Microsoft Graph (e.g., User.Read). They configure the app to use OIDC middleware. The enterprise application (service principal) automatically appears. The admin assigns users to the app. When users access the app, they are redirected to Entra ID, authenticate, and receive an ID token and access token. The app uses the access token to call Microsoft Graph on behalf of the user. The admin can apply Conditional Access policies to this enterprise application. Common pitfalls: misconfigured redirect URIs cause authentication errors; tokens expire, requiring refresh logic in the app; and API permissions must be consented by an admin for the app to work for all users.
SC-900 Exam Focus on Entra ID Enterprise Applications
Objective Code: Domain 2.1 (Describe the capabilities of Microsoft Entra ID) – specifically, the sub-topic 'Enterprise Applications'. The exam expects you to understand the purpose of enterprise applications, the difference between app registrations and enterprise applications, and the key features: SSO, provisioning, and application proxy.
Common Wrong Answers and Why Candidates Choose Them: 1. Confusing App Registrations with Enterprise Applications: Many candidates think they are the same. The exam tests that app registrations create the application object (global definition), while enterprise applications show the service principal (tenant-specific instance). Wrong answer: 'You configure SSO in App Registrations.' Reality: SSO is configured in the Enterprise Application blade (for SAML) or in App Registrations for OIDC. The exam may ask where to assign users – answer is Enterprise Applications. 2. Thinking Password-based SSO is the default: Candidates assume all apps use password SSO. The exam tests that SAML and OIDC are modern standards, while password SSO is only for legacy apps that don't support federation. Wrong answer: 'Password SSO is more secure.' Reality: It's less secure because Entra ID stores credentials. 3. Believing that provisioning is automatic for all apps: Provisioning requires the target app to support SCIM. The exam may list a scenario where provisioning fails, and the candidate must know that SCIM is needed. Wrong answer: 'Provisioning works for any app.' Reality: Only gallery apps with SCIM support or custom SCIM endpoints. 4. Misunderstanding Application Proxy: Candidates think it requires inbound firewall rules. The exam tests that the connector initiates outbound connections only. Wrong answer: 'You need to open inbound ports for Application Proxy.' Reality: Only outbound HTTPS from the connector.
Specific Numbers and Terms That Appear on the Exam: - The difference between Application ID (client ID) and Object ID (service principal). - Default provisioning interval: 40 minutes. - SAML signing certificate validity: 3 years (default). - Application Proxy uses outbound TCP 443. - User assignment required: Yes by default. - SCIM protocol for provisioning.
Edge Cases and Exceptions: - Multi-tenant applications: Service principal only appears after admin consent. - B2B users: Can be assigned to enterprise applications but must have an Entra ID account. - Custom roles: Not all enterprise applications support custom app roles; the default role is used. - Linked SSO: Just redirects; no token exchange.
How to Eliminate Wrong Answers Using the Underlying Mechanism: - If a question asks about 'managing user access to an application', think about assignment (Enterprise Applications -> Users and groups). - If it asks about 'automating user account creation', think provisioning and SCIM. - If it asks about 'publishing an internal app without VPN', think Application Proxy. - If it asks about 'setting up SSO for a gallery app', think SAML configuration in Enterprise Applications. - Remember that enterprise applications are about the representation of the app in your tenant, not the app's code.
Enterprise Applications represent the service principal of an application in your Entra ID tenant.
SSO modes: SAML, OIDC, password-based, linked, and disabled.
User assignment is required by default; only assigned users can access the app.
Provisioning uses SCIM protocol and runs every 40 minutes by default.
Application Proxy allows secure remote access to on-premises apps without VPN.
The difference between app registrations (global) and enterprise applications (tenant-specific) is a common exam topic.
SAML signing certificates have a default validity of 3 years.
These come up on the exam all the time. Here's how to tell them apart.
App Registrations
Creates the application object (global definition).
Contains redirect URIs, API permissions, and authentication settings.
Used for development and app registration.
Application ID (client ID) is assigned here.
Supports OIDC and OAuth 2.0 protocol configuration.
Enterprise Applications
Shows the service principal (tenant-specific instance).
Used for managing user assignments, SSO configuration, and provisioning.
Admin interface for operational management.
Object ID is the service principal's ID.
Supports SAML, password, and linked SSO configuration.
Mistake
App Registrations and Enterprise Applications are the same thing.
Correct
App Registrations creates the application object (global definition), while Enterprise Applications shows the service principal (tenant-specific instance). You configure SSO and user assignments in Enterprise Applications, not in App Registrations.
Mistake
Password-based SSO is the most secure SSO method.
Correct
Password SSO stores user credentials in Entra ID and is less secure than SAML or OIDC, which use token-based authentication. Password SSO is only for apps that don't support modern protocols.
Mistake
Automatic provisioning works for all enterprise applications.
Correct
Provisioning requires the target application to support the SCIM protocol. Only gallery applications with SCIM endpoints or custom apps implementing SCIM can be provisioned automatically.
Mistake
Application Proxy requires inbound firewall rules to the connector.
Correct
The connector only makes outbound connections to Azure over TCP 443. No inbound ports are needed; this is a key security feature.
Mistake
All users in the tenant can access an enterprise application by default.
Correct
By default, 'User assignment required' is set to Yes, meaning only explicitly assigned users or groups can access the application. You must change this setting to allow all users.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
App Registrations is where you register an application, creating an application object that defines its identity, redirect URIs, and API permissions globally. Enterprise Applications displays the corresponding service principal, which is the tenant-local representation of that app. You use Enterprise Applications to configure SSO, assign users, and set up provisioning. Think of App Registrations as the 'blueprint' and Enterprise Applications as the 'instance' in your tenant.
For a pre-integrated gallery app, go to Enterprise Applications, add the Salesforce gallery app, then configure SAML-based SSO. You'll need to download the SAML metadata or manually enter the Identifier and Reply URL from Salesforce. Upload the metadata to Salesforce. Then assign users/groups to the app. Optionally, enable automatic provisioning using SCIM. Test by signing in as an assigned user.
Azure AD Application Proxy publishes on-premises web applications externally without a VPN. It uses a connector installed on-premises that makes outbound connections to Azure. Users access the app via an external URL, authenticate with Entra ID, and the connector forwards traffic to the internal app. Use it for legacy apps that can't move to the cloud or for secure remote access.
Automatic provisioning uses the SCIM protocol to synchronize user identities from Entra ID to the target application. You configure the tenant URL and secret token for the app, define attribute mappings, and set scope (e.g., only assigned users). Entra ID then periodically (every 40 minutes by default) checks for changes and creates, updates, or deletes user accounts accordingly.
Yes, B2B guest users can be assigned to enterprise applications just like internal users. They must have an Entra ID account (guest user) in your tenant. You can assign them directly or via groups. However, they may need to consent to the application's permissions on first access.
If set to No, any user in your tenant (including guests) can access the application without being explicitly assigned. This is less secure and is typically used for public-facing apps. It also means you cannot apply Conditional Access policies that target only assigned users. The default is Yes for security.
You can remove the user from the assigned list in the Enterprise Application's 'Users and groups' blade. Alternatively, you can disable the user's account in Entra ID or remove them from the group that is assigned. If provisioning is enabled, the user account in the target app will be deactivated in the next provisioning cycle.
You've just covered Entra ID Enterprise Applications — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?