Entra Enterprise Apps: MFA, SSO, Conditional Access, and User Management Guide 2026
Why This Is Happening
I've seen this exact scenario play out on dozens of enterprise tenants: someone registers an app in Microsoft Entra ID, wires up SSO, and then gets a flood of support tickets the next Monday morning. Users can't sign in. Some get AADSTS50105 , "The signed in user is not assigned to a role for the application." Others hit AADSTS700016, "Application with identifier was not found in the directory." Your MFA policy fires for users who should be exempt. And the IT admin who set the whole thing up is now staring at the Azure portal wondering where it all went wrong.
Here's the thing, Entra Enterprise Apps configuration is not hard once you understand how the pieces fit together. But Microsoft's error messages are genuinely terrible at telling you which piece is broken. AADSTS50105 looks like a permissions error. It's actually a user assignment problem. AADSTS65001 looks like a consent issue. It might be a missing API permission scope. The error surface and the actual root cause are often two completely different layers.
Entra Enterprise Apps sits at the intersection of identity, access management, and application configuration. When you register an application in your Microsoft Entra tenant, whether it's a preintegrated gallery app like Salesforce or Workday, your own internal business application, or an on-premises system connected through Application Proxy, you're creating what Microsoft calls a service principal in your tenant directory. That service principal is the object that holds all the runtime configuration: SSO settings, user assignments, Conditional Access policy associations, MFA requirements, and provisioning rules.
The most common root causes I see for Entra Enterprise Apps failures fall into four buckets. First: user assignment is disabled when it should be on, or on when it should be off, causing either open access or total lockout. Second: SAML or OpenID Connect SSO is misconfigured, wrong Redirect URI, wrong entity ID, wrong claim mapping. Third: Conditional Access policies apply MFA requirements that conflict with the app's own authentication settings. Fourth: admin consent has not been granted for the permissions the application is requesting, so users get stuck in a consent loop they can't escape.
I know this is frustrating, especially when a misconfigured Entra Enterprise Apps policy blocks an entire department from accessing a tool they need for their job. This guide walks you through every layer, step by step, with exact UI paths and the PowerShell commands that actually work. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If users are getting AADSTS50105, "signed in user is not assigned to a role for the application", the fastest fix is to check user assignment configuration. This single setting blocks more people than any other Entra Enterprise Apps misconfiguration I've seen.
Navigate to Microsoft Entra admin center (entra.microsoft.com) → Applications → Enterprise applications → search for your app → click it → select Properties from the left menu. Look for the toggle labeled "Assignment required?"
If it's set to Yes, only explicitly assigned users and groups can sign in. If it's set to No, all users in the tenant can access the app without assignment. Choose based on your intent. If the app should be open to your whole organization, flip it to No. If it should be restricted, keep it Yes and make sure the right users are actually assigned, which you'll do in Step 3 of this guide.
After toggling, wait about 60 seconds and have the affected user try signing in again. If the error was purely AADSTS50105, this resolves it immediately with no other changes needed.
For AADSTS700016, "application with identifier was not found in the directory", the fix is different. This almost always means the Redirect URI configured in the application registration doesn't match what the app is actually sending in its authentication request. Go to App registrations (not Enterprise applications, these are different views of the same object) → find your app → Authentication → check the Redirect URIs. Compare this exactly, character for character, including trailing slashes, to what your application is configured to send. A mismatched trailing slash is enough to trigger AADSTS700016.
If users are stuck in an MFA loop even though you've set up Conditional Access to exclude them, check whether the exclusion is on a user or a group. Individual user exclusions in Conditional Access can take 5–10 minutes to propagate. Group-based exclusions take longer, sometimes up to 30 minutes after a group membership change.
Before you can configure SSO, MFA, or Conditional Access for any application, it needs to exist in your Entra tenant either as a preintegrated gallery app or as a custom registration. These are two different paths that converge at the same place.
For gallery apps: Go to entra.microsoft.com → Applications → Enterprise applications → click New application. The gallery contains thousands of preintegrated SaaS apps, Salesforce, ServiceNow, Zoom, Slack, Workday, and hundreds more. Search for your app, click it, and hit Create. Microsoft has already done the heavy lifting for these: the SAML metadata, certificate configuration, and claim mappings are pre-populated. You still need to configure tenant-specific values, but the framework is there.
For your own business application: Go to App registrations → New registration. Give it a name, select who can use it (single tenant vs. multitenant), and enter the Redirect URI, this is the URL your app sends users back to after authentication. Use https:// for all production apps; http://localhost is only allowed for development. After registration, the app appears in both App registrations AND Enterprise applications, they're linked but separate views. App registrations is where you manage the application's identity definition. Enterprise applications is where you manage runtime access and behavior.
For on-premises applications: You'll use Application Proxy, which requires you to install an Application Proxy connector on a Windows Server machine inside your network. The connector creates an outbound-only connection to Entra, no inbound firewall rules needed. After that, you publish the internal app URL through the portal and Entra handles external authentication.
When the app is created, you should see it listed in Enterprise applications → All applications. If it's not appearing, wait 30 seconds and refresh, tenant replication occasionally takes a moment. If it still doesn't appear, verify you're looking at the correct tenant in the top-right tenant switcher.
Single sign-on is the feature that lets your users authenticate once with their Entra credentials and then access the application without logging in again. Microsoft Entra ID supports several SSO methods, but in enterprise contexts you'll almost always be choosing between SAML-based SSO and OpenID Connect-based SSO.
Go to your app in Enterprise applications → Single sign-on from the left sidebar. You'll see a method selector. For most modern SaaS apps that support federation natively, choose SAML. For apps built on OAuth 2.0 or apps you've registered yourself using Microsoft identity platform, choose OpenID Connect.
SAML configuration, the four values you must get right:
- Identifier (Entity ID), a unique URI that identifies your app to Entra. The app vendor specifies this. Get it wrong and you'll see AADSTS750054.
- Reply URL (Assertion Consumer Service URL), where Entra sends the SAML response after authentication. Must match exactly what the app expects.
- Sign on URL, the URL users go to when initiating a sign-in (SP-initiated flow).
- Relay State, optional, but some apps require it to land users on a specific page after login.
After filling these in, scroll down to SAML Certificates and download the Federation Metadata XML. Give this file to the app vendor or paste its URL into the app's SAML/SSO configuration screen. This is how the app learns to trust tokens signed by your Entra tenant.
For OpenID Connect SSO, the flow is simpler, Entra auto-populates most values once you enter the Client ID and Client Secret from your app registration. Copy the Application (client) ID from App registrations and paste it into your app's OAuth configuration. The OpenID Connect metadata endpoint for your tenant is always: https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration.
After saving SSO configuration, use the Test single sign-on button at the bottom of the SAML setup page. This runs a simulated authentication and tells you exactly which step failed, if any. Don't skip this, it catches certificate mismatches and claim mapping errors before your users hit them.
By default, when you add an enterprise application to your Entra tenant, all users can access it, even without being explicitly assigned. This is intentional for low-sensitivity apps, but for anything containing business data, you want to control exactly who gets in.
First, if you want restricted access, make sure Assignment required is set to Yes in the app's Properties page. With that set, anyone who isn't assigned will get AADSTS50105 at login, which is the right behavior in this case.
Then go to Enterprise applications → your app → Users and groups → click Add user/group. In the blade that opens, click Users and groups under "Select" to pick who you're assigning. You can assign individual users or entire security groups. I almost always recommend using security groups for anything with more than 5 people, it makes offboarding and role changes much easier to manage at scale.
If your app has multiple roles defined (for example, a "Reader" role and an "Admin" role defined in the app manifest), you'll see a Select a role dropdown during assignment. Pick the appropriate role for each user or group. If you don't see role options, the app manifest hasn't defined any, you may need to add them under App registrations → your app → App roles.
Owners are different from users. Owners of an enterprise application can manage it without needing the Global Administrator or Application Administrator Entra role. To assign an owner: go to Enterprise applications → your app → Owners → Add. This is useful for delegating app management to a team lead or department head without elevating their tenant-wide permissions.
After assigning users, verify by having one of the newly assigned users navigate to myapps.microsoft.com. The app should appear in their My Apps portal within a few minutes. If it doesn't appear after 10 minutes, go back and confirm the assignment saved, there's an occasional UI bug where the save silently fails if you close the blade too quickly.
This is where most enterprise Entra Enterprise Apps configurations get complex. Conditional Access is a policy engine that evaluates signals, who the user is, what device they're on, where they're signing in from, what app they're accessing, and decides whether to allow, block, or challenge with MFA.
Go to Microsoft Entra admin center → Protection → Conditional Access → Policies → New policy.
The key sections to configure:
- Users, who the policy applies to. You can target all users, specific groups, or specific roles. Use the Exclude tab to carve out break-glass admin accounts and service accounts that must never be blocked by MFA.
- Target resources, which apps the policy applies to. Select Select apps, then search for your enterprise app by name. This scopes MFA to just this app, not your whole tenant.
- Conditions, optional filters. Sign-in risk level (requires Entra ID P2), device platform, location (named locations for trusted IP ranges), client apps.
- Grant, what happens when the policy fires. For MFA, select Require multifactor authentication. You can combine this with Require compliant device if you're managing endpoints with Intune.
A pattern that works well in practice: create a base policy requiring MFA for all users on all apps, then create a second policy that excludes trusted IP ranges (like your office network) from MFA. Stack these together so remote access always requires MFA, but in-office users on a known network can sign in with just their password.
To configure trusted named locations: Conditional Access → Named locations → New location → enter your office IP ranges in CIDR notation. Then reference this named location in your policy's Conditions → Locations → Exclude.
After creating the policy, set it to Report-only mode first. This evaluates the policy and logs what would have happened without actually enforcing it. Check the Sign-in logs after a day and look at the "Conditional Access" tab on any sign-in entry to see which policies fired and what their outcome would have been. Only flip to On once you've confirmed the policy behaves as expected.
Two more configuration layers that catch people off guard: consent and provisioning. Getting both right turns a functional app integration into a fully managed one.
Admin consent: Applications request permissions, for example, access to read user profiles, send mail as the user, or read group membership. When a user signs in and the app requests permissions the user isn't allowed to grant themselves, they'll see an error or a consent prompt that says something like "Need admin approval." This is by design.
As an administrator, you can grant tenant-wide admin consent so users never see that prompt. Go to Enterprise applications → your app → Permissions → Grant admin consent for [your tenant name]. Review every permission listed before clicking this button. Granting tenant-wide admin consent means every user in the tenant can use the app with those permissions applied, so make sure you actually want that. For sensitive permissions like Mail.ReadWrite or Directory.ReadWrite.All, always verify with the app vendor that these are genuinely required.
If users keep getting stuck at consent screens despite you having granted admin consent, check whether the app is requesting permissions that weren't included in your consent grant. Apps can be updated by their developers to request additional scopes, and those new scopes require fresh consent. The Permissions page will show you "Granted" vs. "Not granted" for each permission so you can spot the gap.
Automated provisioning: Instead of manually assigning every user, you can configure Entra to automatically create, update, and disable user accounts in supported applications using the SCIM protocol. Go to Enterprise applications → your app → Provisioning → Get started. Set Provisioning Mode to Automatic and enter the Tenant URL and Secret Token provided by the app vendor (usually found in the app's admin settings under API access or integrations). Click Test Connection, if it succeeds, save and start the provisioning cycle.
Provisioning runs on an approximately 40-minute cycle by default. The first sync can take longer depending on how many users are in scope. Monitor progress under Provisioning → Provisioning logs. Any failed provisioning actions show up here with specific error codes that tell you exactly what went wrong at the target application.
Advanced Troubleshooting
When the standard fixes don't resolve the issue, it's time to go deeper. Here's how I approach persistent Entra Enterprise Apps problems in enterprise environments.
Reading Sign-in Logs like a diagnostic tool: Every authentication attempt, successful or failed, is logged in Entra's Sign-in logs with a retention of 30 days (7 days on free tier). Go to Monitoring & health → Sign-in logs. Filter by Application to isolate your app. Click any failed entry and check four tabs: Basic Info (AADSTS error code), Authentication Details (which auth method was used), Conditional Access (which policies were evaluated and the outcome), and Additional Details (the full diagnostic message). The error code in Additional Details is your most specific signal, don't ignore it.
Common AADSTS codes and what they actually mean:
- AADSTS50011, The Redirect URI in the request doesn't match any registered for the app. Compare exactly what's in App registrations → Authentication vs. what the app is sending.
- AADSTS50020, The user account from the identity provider doesn't exist in the tenant. Common in B2B or guest user scenarios, check if the user's account type is "Member" vs. "Guest."
- AADSTS50076, MFA required. The user needs to complete MFA but hasn't registered a method. Send them to
aka.ms/mfasetup. - AADSTS65001, User or admin hasn't consented to the permissions the app needs. Grant admin consent as described in Step 5.
- AADSTS700016, Application not found in the directory. The client ID in the auth request doesn't match any registered app, check for typos or wrong tenant configuration.
Group Policy and domain-joined machines: In hybrid environments where machines are domain-joined and also registered with Entra ID, Conditional Access policies may behave unexpectedly. The "Require compliant device" or "Require Hybrid Entra joined device" conditions depend on the device being properly registered. Run dsregcmd /status in an elevated command prompt on the affected machine. Look for AzureAdJoined : YES and DomainJoined : YES. If AzureAdJoined is NO on a machine that should be hybrid-joined, the Conditional Access policy will deny access even though the machine is on the domain. Fix: run dsregcmd /join or trigger a Group Policy update with gpupdate /force and wait for the next Entra sync cycle.
Using Microsoft Graph API to diagnose programmatically: If you're managing a large number of apps and need to audit configurations at scale, the Microsoft Graph API is your friend. The endpoint GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=displayName eq 'YourAppName' returns the full service principal object including all app role assignments, permissions, and properties. Use GET /servicePrincipals/{id}/appRoleAssignedTo to see exactly which users and groups are assigned and what roles they have. This is dramatically faster than clicking through the portal for tenant-wide audits.
Application Proxy connector issues: If you're using Application Proxy for on-premises apps and users are getting timeout errors or seeing a generic "This site can't be reached" page, the problem is almost always the connector. Open Event Viewer on the connector server and navigate to Applications and Services Logs → Microsoft → AadApplicationProxy → Connector → Admin. Event ID 12003 means the connector can't reach the internal app URL, check that the internal URL is correct and the connector server can access it. Event ID 12004 means authentication failure, verify the service account running the connector has appropriate permissions.
Escalate to Microsoft Support when you're seeing errors that don't match any documented AADSTS code, when sign-in logs show a Conditional Access policy applying incorrectly despite your configuration looking right, or when a preintegrated gallery app suddenly stops working without any configuration change on your end (this sometimes indicates a backend change on Microsoft's side). Before opening a ticket, pull the Correlation ID from the failed sign-in log entry, Microsoft support will ask for this first thing, and having it ready cuts your resolution time significantly.
Prevention & Best Practices
The best Entra Enterprise Apps problems are the ones that never happen. Here's what I tell every IT team after we've resolved a messy Entra configuration incident.
Use Report-only mode before enforcing any Conditional Access policy. I cannot stress this enough. Every new Conditional Access policy should spend at least 24–48 hours in Report-only before you flip it to On. During that time, watch the sign-in logs and look at the Conditional Access tab on representative sign-ins to confirm the policy fires for the right users and not for the wrong ones. Flipping straight to On on a Friday afternoon is how you create a Monday morning crisis.
Document your SSO configuration externally. The Entra portal is the source of truth for runtime configuration, but it's not a documentation system. Keep a spreadsheet or Confluence page that records the Entity ID, Reply URL, certificate expiration date, and SAML claim mappings for every enterprise app. Certificate expiration is the most common cause of sudden SSO breakages, and it's 100% preventable. Entra will send you an email notification 60 days before a SAML signing certificate expires, but those emails often go to whoever's email is on the Global Admin account, which might be a shared mailbox nobody checks.
Set up access reviews for sensitive apps. Go to Identity Governance → Access reviews → New access review. Configure quarterly reviews for any enterprise app that contains sensitive data. This automatically sends reviewers a list of current users with access and asks them to confirm each user still needs it. It's how you prevent privilege creep, the slow accumulation of access rights that nobody audited for two years.
Always exclude break-glass accounts from Conditional Access. Every tenant should have at least two break-glass accounts, Global Admin accounts that exist solely for emergency access and are excluded from all Conditional Access policies, MFA requirements, and sign-in restrictions. Store the credentials in a physical safe, not a password manager. If your MFA system ever goes down or your Conditional Access policy accidentally locks out all admins, these accounts are your way back in.
- Rotate SAML signing certificates before they expire, set a calendar reminder 45 days before the date shown in Enterprise applications → your app → SAML Certificates
- Use security groups for user assignment, never individual user accounts, it makes bulk access changes and offboarding orders of magnitude faster
- Enable the admin consent workflow so users can request access to apps without an IT ticket, configure it under Enterprise applications → Consent and permissions → Admin consent settings
- Monitor the Provisioning logs weekly for any apps with automated SCIM provisioning, failed provisioning events don't generate alerts by default unless you configure a diagnostic setting to route them to Log Analytics or a SIEM
Frequently Asked Questions
What's the difference between App registrations and Enterprise applications in Entra ID?
These two sections of the Entra portal both deal with applications, but they represent different things. App registrations is where you define the application's identity, its client ID, redirect URIs, API permissions it declares, and app roles it exposes. Think of it as the blueprint. Enterprise applications shows the service principal, the actual instance of that app in your tenant, where you manage who can sign in, what SSO settings apply, and how Conditional Access interacts with it. Think of it as the running copy. Every app registration has a corresponding enterprise application entry, but not every enterprise application has a separate app registration in your tenant, gallery apps that are preintegrated exist as service principals without you owning the underlying registration.
What types of apps does Microsoft Entra support for single sign-on?
Microsoft Entra ID supports SSO for a wide range of application types. Preintegrated SaaS apps from the gallery (Salesforce, Workday, ServiceNow, Zoom) support SAML or OpenID Connect federation out of the box. Applications you develop yourself can use OpenID Connect and OAuth 2.0 through the Microsoft identity platform. Legacy applications that don't support modern federation protocols can use password-based SSO, where Entra stores and replays credentials, or header-based SSO through Application Proxy for on-premises apps. The gallery alone has thousands of preintegrated applications, and any app that supports SAML 2.0 or OpenID Connect can be added as a custom non-gallery application if it isn't already listed.
How do I grant admin consent for an enterprise app without breaking other permissions?
Granting tenant-wide admin consent is a targeted action, it consents to the specific permissions that particular app is requesting, and doesn't affect any other app's permissions. Go to Enterprise applications → your app → Permissions and review the list of permissions shown before clicking Grant admin consent for [tenant]. The key thing to check is whether any permissions are classified as "Application" type vs. "Delegated" type. Application permissions (like Directory.Read.All) give the app access regardless of who is signed in, these are higher risk. Delegated permissions act on behalf of the signed-in user. Always flag Application-type permissions to your security team before granting consent, and confirm with the vendor that they're genuinely necessary.
How do I set up MFA for just one specific app, not the whole tenant?
You do this through Conditional Access, not through the app itself. Create a new Conditional Access policy, set Users to the group you want to enforce MFA for, set Target resources to Select apps and choose your specific enterprise application, leave Conditions at defaults for now, and set Grant to Require multifactor authentication. Save the policy in Report-only mode first and verify it only fires for sign-ins to that specific app before enabling enforcement. This approach scopes MFA precisely to the app and user combination you specify, without requiring MFA for every sign-in across the tenant. Users who haven't registered MFA methods yet will need to go through registration at aka.ms/mfasetup before they can satisfy the policy.
Is it helpful to automate provisioning of user accounts to enterprise apps?
For any app with more than about 20–30 users, automated provisioning is absolutely worth setting up, it eliminates manual account creation errors, ensures deprovisioned Entra accounts are also deactivated in the target app (reducing your attack surface), and keeps user attributes like department and job title synchronized automatically. Entra supports SCIM-based provisioning for a large number of gallery applications. The setup is in Enterprise applications → your app → Provisioning. You'll need a Tenant URL and Secret Token from the target app's admin console. Once configured, provisioning runs automatically on roughly a 40-minute cycle, with a full sync every few days. The Provisioning logs give you visibility into every create, update, and delete action taken.
Can I use Entra Enterprise Apps with on-premises applications that don't support cloud authentication?
Yes, this is exactly what Microsoft Entra Application Proxy is built for. You install a lightweight Application Proxy connector agent on a Windows Server machine inside your network (it requires outbound HTTPS access to Microsoft's cloud, no inbound firewall changes). You then publish the internal URL of your on-premises app through the Entra portal, and Entra issues it an external URL under msappproxy.net or a custom domain. Remote users authenticate to Entra ID first, and then the connector proxies the request to the internal app on their behalf. You can layer SSO on top using Kerberos Constrained Delegation for apps that support Windows-Integrated Authentication, or header injection for apps that authenticate via HTTP headers. Conditional Access and MFA apply just like any other enterprise app.