We have an existing enterprise application configured for SAML authentication in Entra ID. A newly added user cannot sign in, even though the sign-in logs show that the user passes the applicable Conditional Access policies. The failure indicates that the user is not permitted to use the application.
The user appears directly under the application's Users and groups assignment, rather than through a group. The application's SAML settings appear consistent with those of working users, and the claims are based on the user principal name. The affected account's UPN follows the same format as the accounts that work.
What should we check next to determine why this one user is being denied?
3 Answers
Start by verifying the exact account identity being assigned to the application. Compare the user’s UPN, sign-in name, email-related attributes, and any claims being sent in the SAML assertion with a known-good user. The assignment may look correct while the application is receiving a different identifier than expected.
Remove the user’s application assignment, delete any corresponding account or assignment record inside the application if applicable, and then add the user again. Afterward, test with a fresh browser session and review the Entra sign-in details along with the application’s SAML or access logs.
Clear the possibility of a stale or incorrect sign-in session. The user may have multiple Entra accounts cached in the browser, so signing out completely, using an InPrivate window, or creating a separate browser profile can help confirm which account is being used. Also perform the application’s own logout if it maintains a SAML session.
A separate browser profile is especially useful if the user has several work accounts signed in at once, since the browser can silently submit the wrong identity.