AADSTS50105 error message is unreadable for end users — UX improvement suggestion
1. What’s wrong with the current error message a. It’s written for administrators, not users The message exposes: Internal system names (AADSTS50105) GUIDs (aaaabbbb-cccc-dddd-eeee-ffff01234567) Identity provider jargon (“direct member of a group with access”) None of this helps the person who sees the error decide what to do next. b. The actual problem is buried in a wall of text The real issue is simply: You don’t have permission to access this app. Instead, the message forces users to: Read a long paragraph Decode domain-specific language Guess which part matters Cognitively, this is high effort for low payoff. c. “Contact your administrator” is vague and unhelpful Users ask: Which administrator? IT? Security? App owner? Their manager? What should they say? Without context, users either: Ignore the error Forward screenshots randomly Open the wrong support ticket d. Error codes without guidance increase support load AADSTS50105 may be meaningful internally, but: Users don’t know whether to Google it Support teams receive unclear tickets (“it doesn’t work”) This paradoxically raises support cost instead of lowering it. 2. What a better error message should do A good error message answers four questions in order: What happened? Why did it happen (in plain language)? What can the user do next? Who specifically can help? And it does so in under 30 seconds of reading time. 3. Example of a much better error message You don’t have access to [APPLICATION] Your account (email address removed for privacy reasons) isn’t currently authorized to use [APPLICATION]. This usually means: You haven’t been added to the required security group, or Access hasn’t been requested or approved yet. What to do next If you believe you should have access, contact IT Service Desk or your [APPLICATION] owner and request access. Helpful details to include in your request Application name: [APPLICATION] Your email: email address removed for privacy reasons Error reference: Access not assigned (Error ID: AADSTS50105 — for IT use) 4. Optional but high-impact improvement: Add a “Request Access” button or link One-click takes users to: ServiceNow / Jira / internal form Auto-populates app name and user email Administrators configure support link when configuring the applicationRequest to enable preview feature - Face Check with CAP
Dear Microsoft, I am on a business premium plan for my home test tenant. I cannot raise ticket nor do I have an account manager. I know this is in private preview. I would like my tenant to be enabled to test this new Verified ID feature to have "Face Check" in CAP as one of the Grant conditions. tenant id: bc85b508-0107-4472-a49c-fc8cefd4f0d7 Thank you.
Made a self-hosted Entra ID governance portal for app/identity sprawl (open source)
Our tenant ended up with hundreds of app registrations and enterprise apps, and the native portal makes you dig through a separate blade for every basic question. Who owns this app? Which secrets die next month? What hasn't been signed into in a year? Which ones have scary Graph permissions? There's no single view for any of it, and half the ownership info was missing anyway. Entra ID Governance, access reviews, PIM all exist, but they felt heavy (and licensed) for what I actually wanted, which was just a fast list I could scan for routine cleanup. So I built one. Lightweight portal that runs entirely in your own subscription: One grid for App Registrations, Enterprise Apps, Managed Identities and Privileged Users Risk flags per identity: expiring/expired creds, high-risk permissions, no owner, stale sign-in, no CA coverage Ownership tracking, review and owner-change workflow, CSV export Tenant health score and a consent posture dashboard Optional expiry email notifications (needs a SendGrid key) Reads Graph through a managed identity, so no app secrets for data access and nothing leaves your tenant Runs about $26-30/month (one B2 App Service plan). B1 is also supported, but it's noticeably slower. It's not a replacement for Entra ID Governance or PIM, more of a cheap everyday hygiene thing. Full disclosure, I used AI building this and writing this up. I designed the architecture and functionality, tested it and ran it against my own tenant. It's open source and deployable with Azure DevOps or an Azure CLI script. Data never leaves your own tenant. Repo (screenshots + setup): https://github.com/nicolaibaralmueller/entra-identity-governance-portal Would love feedback, especially what you'd want it to flag that it doesn't, or where the risk scoring feels off. Been building it on and off for a few months with a lot of iteration. Hopefully this could be useful for others as well.
Entra Enterprise apps and App registrations - Global Secure Access - Conditional Access Block
I am working on a rollout for Global Secure Access and ran into an issue with Entra Enterprise apps setup in the tenant. With Global Secure Access I have a Conditional Access Policy set to Block access to All Resources excluding some resources like Intune and Defender tap required for mobile setup. When I added an administrator account which had done some Enterprise application setup and authorization for various third-party applications, those third-party applications stopped working with failed logins indicating token access issues. Upon review I found the majority of applications to be using client secret authentication with this administrator account as the authorizer. My limited knowledge of Enterprise apps leads me to believe this client secret is an application password that the third-party uses to keep generating tokens based on the authorizing account. My questions surrounding this setup and further understanding are mainly in relation to how Enterprise apps and app registrations authenticate, as well as user authentication directly. 1. How does the token authorization work? Does the application just use the client secret to authenticate as the user who authorized it to generate an access token? Why does MFA requirements and changing passwords not affect this but specific Block policy does? 2. What are best practices in relation to authorizing third-party applications? My thoughts are a dedicated account to authorize applications when needed. 3. How will this work with applications regular users use? Say a user has a digital notebook that syncs with their OneNote or a calendar app that syncs calendars between Outlook and their website. Do these applications also use client secrets with the user's token and will break when added to the GSA setup I have? Is the only way around this to authorize with an admin account for token issuance? Thank you for your time reading this and any insight you may have for any of the questions or ideas mentioned.
External (guest) users can't access my registered application
We have a FileMaker application registered with Entra ID, using OAuth, for internal and external (guests) users in my organization. Since January 19th, external users have been encountering a different authentication process, which results in a 404 error (see images below). No changes were made to the Entra ID or the application configurations before this change in behaviour. It seems that logging in to a personal account results in an incorrect token for the redirect URL, which does not happen when logging in with organizational accounts.
Entra App Gallery required for Excel AddIn
Hi, We have an Excel Addin published to Microsoft AppSource: https://appsource.microsoft.com/en-us/product/office/WA200009029?tab=Overview The Excel Addin uses Entra ID to obtain an OIDC token to securely / seamlessly access MS 365 SharePoint on behalf of the user. In order to achive this the Entra ID subscription needs the TR4E application registered as an Enterprise Application / App Registration. My question is whether I need to submit the TR4E application separately to the Entra App Gallery, so it can be installed by the Entra ID admin - or will the registration in Entra ID happen automatically when a new user first tries using TR4E? I note that MS has suspended new application submissions for Entra App Gallery, which means our customers would need to manually create the Entra ID Enterprise Application (which is not a great experience). Cheers, Andrew
Disable MFA for User with certain admin roles
Hello all, we have a user with sharepoint administrator role and a self build application support manager role (the suer is allowed to create apps in Azure). We are now at a point where this user has to register an app for our helpdesk tool, but we have to remove the MFA for the registration. We excluded the user from the "MFA is mandatory for all users"-policy, the "MFA is mandatory for admins"-policy and set his MFA in the MFA-per-user setting on disabled. We have no other policy that enforces MFA for this user. Wenn we try to log in with the user (under http://www.office.com), we still get the request to register MFA Authenticator. I am aware that MS enforced MFA for admins, when they try to log in into the admin portals. Does this also apply for sharepoint admins? Does anyone have an idea, where the MFA request for this user could come from. Any help is appreciated. Cheers, Erik
