Passkey/FIDO2 for users in mainland China – recommended approach?
Hi, We are currently evaluating the adoption of Passkey/FIDO2 in Microsoft Entra ID as part of our strategy to move users away from traditional authentication methods such as SMS and voice and towards phishing-resistant authentication. Our Microsoft Entra ID tenant is a global tenant (not Azure China operated by 21Vianet), but we have a group of users who are physically located in mainland China. For users in other regions, we are evaluating Passkeys in Microsoft Authenticator and FIDO2 security keys. However, before defining the approach for our users in China, we would like to better understand the supported and recommended architecture for this particular scenario. We have reviewed the Microsoft documentation and understand that: Passkeys are not available for Microsoft Azure operated by 21Vianet. On iOS, Microsoft Authenticator Passkeys can be used to sign in to global organizations while the user is in China. On Android, Passkey authentication has dependencies such as Google Play Services, which raises questions for devices operating in mainland China. Our main questions are: For users physically located in mainland China but authenticating against a global Microsoft Entra ID tenant, what is Microsoft's recommended approach for deploying phishing-resistant authentication with Passkey/FIDO2? Is Microsoft Authenticator Passkey on iOS considered a fully supported option for users permanently located in mainland China, rather than only users temporarily traveling there? For Android users in mainland China, what is the recommended approach considering the dependency on Google Play Services? Is Passkey in Microsoft Authenticator a realistic supported option in this scenario? Would physical FIDO2 security keys be the preferred or more consistent alternative for users in China when mobile Passkeys cannot be reliably used? Are there any other Microsoft-supported Passkey providers or authentication approaches that should be considered specifically for mainland China? From an enrollment perspective, what would be the recommended bootstrap process for these users? For example, would Temporary Access Pass (TAP) be the recommended method to allow users to register their Passkey/FIDO2 credential before SMS/Voice is removed? Are there any additional regional, connectivity, mobile OS, or application compatibility considerations that should be taken into account before enforcing a phishing-resistant Authentication Strength through Conditional Access? Our objective is not simply to enable Passkey in the tenant, but to define a supported and sustainable authentication model for users located in mainland China before starting a broader rollout. Any experience, Microsoft guidance, or recommended architecture for this type of scenario would be greatly appreciated. Thanks in advance.
Entra ID 53003: How to identify primary authentication when Authentication Details are empty?
We are investigating repeated interactive Microsoft Entra ID sign-ins with the following pattern: - ErrorCode: 53003 (BlockedByConditionalAccess) - isInteractive: true - AppDisplayName: OfficeHome - Authentication requirement: Multifactor authentication Conditional Access correctly blocks these requests because they originate outside our trusted locations. We have already confirmed through controlled testing that the authentication flow can reach 53003 after the correct credentials are provided. Our current problem is different: We need to determine what mechanism satisfied the primary/first authentication factor for the observed 53003 events. For these events, Authentication Details are empty: - Authentication method: empty - Authentication method detail: empty - Result detail: empty Therefore, we cannot determine whether primary authentication was performed using a password, an existing token/session claim, PHS, PTA, federation, Seamless SSO, or another mechanism. Our questions are: 1. Is there any tenant-visible telemetry that can identify the primary authentication mechanism when AuthenticationDetails is empty? 2. Can fields such as AuthenticationProcessingDetails, AuthenticationProtocol, IncomingTokenType, OriginalTransferMethod, or AuthenticationMethodsUsed reliably distinguish between password validation and reuse of an existing authentication/token? 3. If additional authentication infrastructure is used: - can PTA Authentication Agent logs be correlated using RequestId or CorrelationId? - should Seamless SSO generate a corresponding Kerberos 4769 event for AZUREADSSOACC$? - should federated authentication be traceable in AD FS logs? 4. For Password Hash Synchronization, is there any tenant-visible telemetry confirming that Entra ID actually validated the password for a specific sign-in request? 5. If this information is not exposed to the tenant, can Microsoft Support retrieve backend authentication telemetry for a specific Sign-in ID / RequestId / CorrelationId and determine how primary authentication was satisfied? Our goal is not to determine why Conditional Access generated 53003 — that part is already understood. We specifically need to identify what satisfied primary authentication before the Conditional Access evaluation.Entra External ID email OTP send event requestType always set to "signIn" regardless of user action
Hi, In a recent workload, I'm assisting a client with implementation of Entra External ID for identity management and app authentication, which includes sending OTP codes with customized email templates. To accomplish this, a custom authentication extension has been created that authorizes the request and then communicates with an email service via an event-driven, loosely coupled architecture. While implementing and testing this feature together with the client, we noticed that it seems like the different modes or states in the user flows are not reflected in the requestType property in the request payload posted to the OnOtpSend auth extension configured. E.g., if a user tries to sign in but has forgotten their password and navigates to the password reset view and requests to send the OTP code to their email address to reset the password, the following payload is sent to the auth extension endpoint (the original payload below was logged with Application Insights, with identifiers below then redacted and formatted, otherwise intact): { "type": "microsoft.graph.authenticationEvent.emailOtpSend", "source": "/tenants/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee/applications/11111111-2222-3333-4444-555555555555", "data": { "@odata.type": "microsoft.graph.onOtpSendCalloutData", "otpContext": { "identifier": "email address removed for privacy reasons", "oneTimeCode": "<REDACTED>" }, "tenantId": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee", "authenticationEventListenerId": "22222222-3333-4444-5555-666666666666", "customAuthenticationExtensionId": "33333333-4444-5555-6666-777777777777", "authenticationContext": { "correlationId": "44444444-5555-6666-7777-888888888888", "client": { "ip": "192.0.2.10", "locale": "en-gb", "market": "en-gb" }, "protocol": "UNDEFINED", "requestType": "signIn", "clientServicePrincipal": { "id": "55555555-6666-7777-8888-999999999999", "appId": "11111111-2222-3333-4444-555555555555", "appDisplayName": "Example Web App", "displayName": "Example Web App" }, "resourceServicePrincipal": { "id": "55555555-6666-7777-8888-999999999999", "appId": "11111111-2222-3333-4444-555555555555", "appDisplayName": "<client-app-name>-Web", "displayName": "<client-app-name>-Web" } } } } The above payload was captured using browser-based authentication (native auth is not used), with the below parameters passed (identifiers, tenant name etc. redacted, otherwise intact): https://example.ciamlogin.com/ aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee/oauth2/v2.0/authorize ?response_type=code &client_id=11111111-2222-3333-4444-555555555555 &redirect_uri=https%3A%2F%2Fexample.com%2Fsignin%2Fcallback%2F &scope=openid+profile+email &state=<REDACTED> &prompt=login &ui_locales=de-DE &mkt=de-DE &nonce=<REDACTED> &code_challenge=<REDACTED> &code_challenge_method=S256 Following having navigated to the authorize endpoint above, the issue can be reproduced by entering an email address or an existing user identity, then on the password entry view, press the “Forgot Password?” link under the password input field, and then press the button/element “Email code to <user-email>”. I have looked at using the requestType in the email OTP send event payload to determine which email template and email content are used as per client requirement, but noted that the requestType seemingly always contains the value "signIn" even if the OTP code was sent as part of a password reset operation. At first glance, it would seem like this property indicates which step in the UI the user is currently at, even though I’m not certain whether that is what the property is actually meant to represent or indicate or not. However, for the above scenario and requirement, some identifier or value indicating the action would be needed in order to tailor the email content. The alternatives to having a reliable context property in the payload to indicate user action would require more or less significant additional components and infrastructure, thus increasing the complexity of the solution. Based on its name and values, it would seem like the requestType property appears be a good candidate to carry a user action context identifier. A suitable alternative solution has been adopted currently, using a generalized OTP template, which works well, but the requirement that it would be preferable to tailor the content based on user context and intent, e.g., whether the request was triggered as part of a password reset action or for another authentication scenario, is still present, ideally via the event payload sent from Entra External ID to the auth extension. If there would be any further/follow-up questions on the above, e.g., to clarify the requirement, or further explain the reproduction steps and behaviour observed, or anything else, please tell, and I'll ensure to get back as soon as possible. Also, would someone have some input on potential other/additional ways to make the requestType include a context identifier, that would be much appreciated as well, thanks! Regards Kristoffer
Guest accounts and MFA via Conditional Access in MS Entra
Hi experts, trying to get some help on my scenario and issue that external users started to experience since I've enabled MFA for external identities & guest users via Conditional Access. We have lots of external partners that we share some documentation with from our SharePoint. Some time ago, I have enabled "MS Entra B2B Integration for SharePoint and OneDrive" so that any external user that access shared files/folders in our SharePoint gets a GUEST account created in our tenant. This was also preparation for enabling MFA for External users via Conditional Access. I believe these are called "B2B Collaboration guests" Now, few days ago, I have enabled MFA via Conditional Access for all external users and guests, enabled for all cloud apps and require MFA to grant access. Until now, I got feedback from two external partners that their existing access doesnt work anymore - and they need to go through MFA (which is expected). The problem is that when they go through MFA set up, it ends up in a "loop" - meaning, they go through all steps but when completing the last step they are returned back to the very 1st step again. So they: scan QR code successfully authenticate get the page that it was successful get back to the 1st step asking to install or use MS Auth app The user tried different browsers also with Incognito tabs... When I am checking sing-in logs: guest account is created fine the status is: "Interrupted" additional details: The user was presented options to provide contact options so that they can do MFA. conditional access forcing MFA is marked as FAILED as MFA was not completed Both external partners that reported this are using MS Entra and I see their IDENTITY as ExternalAzureAD. Have not heard back from anyone else using other than ExternalAzureAD so not sure if there is something extra that needs to be configured. Anyone experienced this issue? Any idea what can be wrong? I do not have any cross-tenant collaboration etc configured...Unexpected button behaviour when using the prompt=create parameter in Entra External ID user flows
Hi, In a recent workload, I'm assisting a client to implement Entra External ID for streamlined authorization as well as single sign-on for associated registered external facing third-party applications for external customer users through their Entra External ID identity, as well as assisting the client with auth branding and other UI customizations, and preparing Entra ID federation custom OIDC providers and configuration for enabling SSO with organizational internal and remote work- and school accounts etc. The sign-up / create account experience is of importance to the client, as a rather substantial amount of users are expected to sign-up via self-service sign-up following having received an invite via another app. To ensure that the user lands on the create account view, in order to minimize the number of steps and actions the users need to take to get there, the prompt=create parameter is used to pre-select the sign-up/register experience in the user flows UI. Having stress-tested the user flows and experience recently, we noticed that in a specific scenario, some UI elements behave in a manner that could be described as unexpected, and even though a workaround has mitigated it to some extent, the behaviour of some elements could probably be improved a bit to ensure an even more consistent user experience in the built-in user flows. Specifically, if the user flow is invoked with the prompt parameter set, the user lands on the create account screen as expected, however, unless custom CSS modification is applied, the Back button that would typically be there, as if having arrived there from the initial sign-in screen where it’s also displayed. If pressing the Back button displayed on the Create account view when having navigated there with the prompt=create set in the /authorize request, pressing the button seemingly doesn’t have any impact or result in any action, one can click it, but nothing happens. I'd suspect it's perhaps a "remnant" from if the flow is invoked without any prompt parameter set, or with prompt=login set, but when prompt=create is set, there is no state/page history in the UI to navigate back to, as no previous page has been displayed or rendered yet and added to the history, and the Back button click thus doesn’t have any effect. In general, I think buttons that don't have any tangible action should not be displayed, also, if prompt=login is set, the Back button isn't shown then either on the very initial user flow view shown then, so it would seem the built-in user flows actually already follow such approach in fact, but not when the prompt=create has been set, thus causing some inconsistency in the UI that users could notice unless custom CSS styling is applied. The expected behaviour for our business case would be that if prompt=create is set, then, similar to the prompt=login, no Back button should be displayed, or, if shown, it should result in some navigation (perhaps something like javascript.go(-1), but that could/would be dependent on from where the user arrived, e.g., going back a step in the browser history won't work if the user clicked a link from an invite email ) and preferably not be non-actionable. Furthermore, on the topic of the Back button and its behaviour when the prompt=create parameter is set, there is another case at which we observed some unexpected button behaviour as well, that could probably benefit from some attention. At a specific second scenario, it seems that the Continue button is displayed without providing any action, and when clicking the Back button then, clicking it seemingly resets the "create account", state likely set by the prompt=create initially, and instead switches the flow back to the sign-in state, which can at least affect the display text of some subsequent buttons shown in later steps in the UI. The user arrives at a built-in Entra External ID user flow /authorize endpoint, with the prompt=create query parameter set The user triggers the OTP challenge by entering an email address to verify the email address The user receives the OTP code but enters it incorrectly, i.e., doesn't copy the full code length of eight digits, and instead enters/pastes six of the eight code digits. The UI then shows an error message that the code could not be used/validated, and the email address field is displayed again with the email address that was used for the verification attempt prefilled. If the user clicks the Continue button at this stage, nothing happens. If the user clicks the Back button instead (given that it’s not hidden), it shows the same view one more time, with the Back and Continue buttons at the bottom. However, if the user clicks the Continue button this time, it works and a new code is sent. On the next screen, where the newly sent code can be entered, instead of a button named "Continue", it will now instead show a button with the text "Sign-in" (it would seem like the create account state has gotten lost somewhere along the way at this point, perhaps when the back button in the step 5 above was pressed). If one omits the prompt=create parameter, or when using prompt=login, things seem to work fine, the above occurs when the prompt=create is set. The reason why is the prompt=create is used is due to a business requirement to try to minimize the steps, especially in conjunction with the registration/sign-up, as far a possible when signing up. We have opted for the built-in user flows, not the self-hosted native authentication UI pages, for this project, and then as I understand it, it is the prompt=create parameter that can/should be used to enable the user to land directly on the registration page without having to navigate there manually via the sign-up link, that is otherwise shown on the initial sign-in page. It would thus be great if the prompt=create parameter could have some attention (or perhaps if a dedicated sign-up user flow type could be added potentially, even though that would perhaps warrant some update to the user flow app linking as well, as my understanding is that one user flow can be linked to one app registration at a time currently) to avoid that some buttons become unresponsive when the parameter is used, or falls back to sign-in, to improve the built-in user flows further, as the prompt=create fulfils the business requirement well otherwise. If there would be any further/follow-up questions on the above, e.g., to clarify the requirement, or further explain the reproduction steps and behaviour observed, or anything else, please tell, and I'll ensure to get back as soon as possible. Also, would someone have some input on potential other/additional ways to pre-select the create account/sign-up experience, that would naturally be much appreciated as well, thanks! Regards KristofferPHS 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!
