PHS staged rollout works for existing users but not new synced users
We are troubleshooting an Entra ID PHS staged rollout issue with a federated domain using a third-party WS-Fed IdP. The intended behavior is that normal federated users redirect to the IdP, while users in the PHS staged rollout group receive the Microsoft/Entra password prompt instead. Existing users in the staged rollout group continue to work correctly. They enter their UPN and receive the Microsoft password prompt. One known-good test user is not provisioned in the third-party IdP and still signs in successfully through the Entra password prompt, so the working path does not require the user to exist in the IdP. The issue is only with newly created AD-synced users. Newly synced users in the same staged rollout group are still being routed to the federated IdP at HRD instead of receiving the Entra password prompt. We’ve verified the staged rollout policy and group membership from Graph, confirmed the affected users are properly AD-synced with clean immutableID/sourceAnchor, and confirmed PHS is working. Federation metadata and HRD policies also look clean. Seamless SSO/AZUREADSSOACC was checked and remediated, but the behavior did not change. For failed attempts, there is no Entra sign-in log entry, including tenant-wide interactive and non-interactive logs. However, the federated IdP logs show a WS-Fed inbound request from login.microsoftonline.com for the affected user. That makes it look like Entra HRD is routing the user to federation before sign-in logging or token issuance. The issue started around an Entra Connect AD connector/DC-path change. We have since reverted the connector to the previous known-good configuration. After reverting, we created a clean-room test user with the correct UPN set before first sync, confirmed sync/PHS/sourceAnchor, added the user directly to the staged rollout group, and waited 60+ minutes. The clean-room user still redirected to the federated IdP instead of getting the Entra password prompt. So the current behavior is that established staged-rollout users still get the Entra password prompt, but newly created synced staged-rollout users are sent to the federated IdP by HRD. Has anyone seen staged rollout get into this state, where existing users work but new synced users remain on the federated HRD path despite valid rollout policy, group membership, synced password hash, and clean immutableID/sourceAnchor? Is there any known backend cache/state reset or escalation path for HRD/staged rollout routing?
Can External ID (CIAM) federate to an Azure AD/Entra ID tenant using SAML?
What I'm trying to achieve I'm setting up SAML federation FROM my External ID tenant (CIAM) TO a partner's Entra ID tenant (regular organizational tenant) for a hybrid CIAM/B2B setup where: Business users authenticate via their corporate accounts (OIDC or SAML) Individual customers use username/password or social providers (OIDC) Tenant details / Terminology: CIAM tenant: External ID tenant for customer-facing applications IdP tenant: Example Partner's organizational Entra ID tenant with business accounts Custom domain: mycustomdomain.com (example domain for the IdP tenant) Configuration steps taken Step 1: IdP Tenant (Entra ID) - Created SAML App Set up Enterprise App with SAML SSO Entity ID: https://login.microsoftonline.com/<CIAM_TENANT_ID>/ Reply URL: https://<CIAM_TENANT_ID>.ciamlogin.com/login.srf NameID: Persistent format Claim mapping: emailaddress → user.mail Step 2: CIAM Tenant (External ID) - Added SAML IdP (Initially imported from the SAML metadata URL from the above setup) Federating domain: mycustomdomain.com Issuer URI: https://sts.windows.net/<IDP_TENANT_ID>/ Passive endpoint: https://login.microsoftonline.com/mycustomdomain.com/saml2 DNS TXT record added: DirectFedAuthUrl=https://login.microsoftonline.com/mycustomdomain.com/saml2 Step 3: Attached to User Flow Added SAML IdP to user flow under "Other identity providers" Saved configuration and waited for propagation The problem It doesn't work. When testing via "Run user flow": No SAML button appears (should display "Sign in with mycustomdomain") Entering email address removed for privacy reasons doesn't trigger federation The SAML provider appears configured but never shows up in the actual flow Also tried using the tenant GUID in the passive endpoint instead of the domain - same result My question Is SAML federation from External ID to regular Entra ID tenants actually possible? I know OIDC federation to Microsoft tenants is (currently, august 2025) explicitly blocked (microsoftonline.com domains are rejected). Is SAML similarly restricted? The portal lets me configure everything without throwing any errors, but it never actually works. Am I missing something in my configuration? The documentation for this use case is limited and I've had to piece together the setup from various sources. Or is this a fundamental limitation where External ID simply can't federate to ANY Microsoft tenant regardless of the protocol used?Does Rights Management Service currently support MFA claims from EAM?
We've been testing EAM (external authentication methods) for a few months now as we try to move our Duo configuration away from CA custom controls. I noticed today that when my Outlook (classic) client would not correctly authenticate to Rights Management Service to decrypt OME-protected emails from another org. It tries to open the message, fails to connect to RMS, and opens a copy of the email with the "click here to read the message" spiel. It then throws a "something is wrong with your account" warning in the Outlook client's top right corner. If I try to manually authenticate & let it redirect to Duo's EAM endpoint, it simply fails with an HTTP 400 error. When you close that error, it then presents another error of "No Network Connection. Please check your network settings and try again. [2603]". I can close/reopen Outlook and that warning message in the top right stays suppresses unless I attempt signing into RMS all over again. However.. If I do the same thing and instead use an alternate MFA method (MS Authenticator, for example), it signs in perfectly fine and will decrypt those OME-protected emails on the fly in the Outlook client, as expected. I verified that we excluded "aadrm.com" from SSL inspection and that we're not breaking certificate pinning. So all I can assume at the moment is that Rights Management Service isn't honoring MFA claims from EAM. Any experience/thoughts on this? Thanks in advance!Looking for an on-prem MFA solution for Active Directory and RDP
Hi everyone, We're reviewing options for adding MFA to our on-premises Active Directory environment. Most of our users authenticate with Active Directory, while administrators also use RDP for managing Windows servers. Because part of our infrastructure is isolated from the Internet, we'd prefer an on-premises MFA solution instead of relying on a cloud-only service. Has anyone implemented something similar recently? I'm interested in hearing: Which solution did you choose? How difficult was the deployment? Did you run into any compatibility or performance issues? Is there anything you'd do differently if you were deploying it again? Any real-world experience or recommendations would be greatly appreciated. Thanks!Can the built-in "No account? Create one" link redirect to a custom sign-up page?
I'm using Microsoft Entra External ID with a built-in sign-in/sign-up user flow. On the Microsoft-hosted sign-in page, the "No account? Create one" link always redirects users to the default Entra sign-up page. I already have a custom registration page and would like this built-in link to redirect to my custom URL instead. Is there any supported way to customize the destination of this link in a built-in user flow? If not, could someone confirm whether this behavior is fixed by design? Thanks!
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.
Orphaned TPM-bound Entra Workplace Join device — no tenant access, backend deletion required
I have a personal Windows device that remains stuck in a TPM-protected Workplace Join to a former Microsoft Entra ID tenant. I no longer have tenant access and am not an admin. Local remediation completed: - dsregcmd /leave executed as SYSTEM - All MS-Organization / AAD certificates removed - Device still reports WorkplaceJoined : YES Azure Support ticket creation fails with: AADSTS160021 – interaction_required Application requested a user session which does not exist. Tenant inaccessible / user not present in tenant. This is an orphaned Entra ID device object. Requesting guidance or escalation for backend deletion. Tenant ID: 99f9b903-8447-4711-a2df-c5bd1ad1adf7 Device ID: f47987f4-a20b-4c34-a5f7-40ab0f593c6c
TAP requires step-up MFA when user already has a passkey registered — expected behavior?
Environment Microsoft 365 Business Premium (Entra ID P1) Cloud-only tenant Authentication methods enabled: FIDO2/Passkey only + TAP All other methods disabled (no Authenticator push, no TOTP, no SMS) CA Policy configuration CA001 — Protect Security Info Registration Target: User action — Register security information Grant: Custom authentication strength "Bootstrap and Recovery" (TAP one-time + TAP multi-use + Passkey/FIDO2 + WHfB/Platform credential) Status: On CA002 — Require Phishing-Resistant Authentication Target: All cloud apps (excluding Azure Credential Configuration Endpoint and tested also excluding Microsoft App Access Panel) Grant: Built-in Phishing-resistant MFA Status: On What was tested Scenario 1 — User with no registered methods (only with Platform credential): Admin issues TAP (multi-use, 4 hours) User navigates to aka.ms/mysecurityinfo User authenticates with TAP Result: Access granted — user can register passkey without any step-up, even in a flow authenticating directly to a resource (such as Microsoft Teams in browser) Scenario 2 — User with an existing portable passkey already registered (in MS Authenticator): Admin issues TAP (multi-use, 4 hours) User navigates to aka.ms/mysecurityinfo User authenticates with TAP Result: Entra requests a second factor — specifically the existing passkey — before allowing access to My Security Info. Seems the system enforces CA002 or a platform-level step-up requirement. The TAP is accepted as a first factor, but the platform then requires the existing passkey as a second factor before proceeding. Sign-in log analysis: The behavior does not appear in the Conditional Access tab of the sign-in logs as a CA policy failure — it appears to be enforced at the platform level, not by any configured CA policy. Questions Is it by design that when a user already has a registered MFA-capable method (passkey), the platform enforces step-up authentication before allowing access to My Security Info — even when the user authenticates with a valid TAP? If so, does the correct recovery procedure require the admin to first remove all existing authentication methods before issuing a TAP — so the user has no registered methods and the TAP is accepted without step-up? Is there any way to allow TAP to bypass this step-up requirement for recovery scenarios, without removing existing methods first? Any pointers to official documentation or confirmed behavior would be appreciated.
