Sign In Error 90072 with On Prem Accounts - How to mitigate?
We receive weekly reports from one of our security vendors regarding login failures across our environment. As of recent, we've noticed a spike in interactive login failures, particularly with Microsoft services. The application that produces many of these logs is Microsoft Office. Upon investigation, we've determined that many of these sign ins procure error code 90072 with the following error message: "User account '{user}' from identity provider '{idp}' does not exist in tenant '{tenant}' and cannot access the application '{application}'({appName}) in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account" As a disclaimer, I did not edit this message to insert the unfilled variables in brackets - that's how the error message appears in our Entra portal. We currently run a hybrid environment, and all of the users with high volumes of failed sign ins with the given error code and message are on-prem accounts. These logs produce a lot of noise that we would rather not have polluting our reports. Do you have any information we can use to help remediate this issue?
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?
Passwordless POC Blocked by CA BYOD Policy – Looking for Workarounds
We’re currently running a POC for passwordless authentication in our environment. One challenge we’ve hit is that our CA BYOD policy blocks personal devices, which prevents users from enabling passwordless sign-in via the Microsoft Authenticator app. Since Authenticator is not a cloud app, we can’t exclude it from the CA policy using the usual cloud app filters. This is causing issues when users try to register or use passwordless sign-in from their personal phones. Has anyone dealt with this scenario or found a workaround that allows passwordless sign-in while still enforcing BYOD restrictions? Any ideas, suggestions, or creative solutions would be much appreciated! Thanks in advance!
User Identities in EntraID - how to remove?
I have a user that shows up with multiple identities. No other users are like this and we believe its stopping him from logging in with his alias email address. When i run get-entrauser it returns the following under Identities: {@{signInType=federated; issuer=MicrosoftAccount; issuerAssignedId=}, @{signInType=federated; issuer=MicrosoftAccount; issuerAssignedId=}, @{signInType=userPrincipalName; issuer=OURPRIMARYDOMAIN.onmicrosoft.com; issuerAssignedId=UPN}} Every other account just has this @{signInType=userPrincipalName; issuer=OURPRIMARYDOMAIN.onmicrosoft.com; issuerAssignedId=UPN}} How would i go about removing those identies from that user? Struggling to find any info online.Problems configuring federation to SAML IdP
Hi. I'm trying to configure our Entra domain to federate to our existing IdP, following the guidance found https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-saml-idp#supported-bindings and am having real problems when it comes to using the Microsoft Graph API in PowerShell. After eventually working out what permissions I needed to request (more than what is stated in the doc), I ran the New-MgDomainFederationConfiguration cmdlet, and received the following error: "FederatedIdpMfaBehavior cannot be empty" This parameter is not mentioned in the doc either. So, then I added that parameter, and got the following: "Domain already has Federation Configuration set." But when I run Get-MgDomainFederationConfiguration, I get: "Resource 'federationConfiguration' does not exist or one of its queried reference-property objects are not present." When I run Get-MgDomain, AuthenticationType shows as "Federated", but I still see a managed login when I check. So I seem to be stuck with it seemingly half-configured, with no way to view or remove the configuration. Any ideas? Thanks, Nick
Understanding Sign-In logs - password hash sync from another country?
Gday Had a couple users show up today at risk - failed logins from the US, while we're in Canada. Users are not in the US, not using VPNs, logins are to Microsoft services (Office Home, One Outlook Web). The useragent is the axios client, the auth method is 'password in the cloud' - which as i understand it, means the password is being auth'd directly against Entra. However, one of them is Azure AD sync'd. The auth method on this is 'password hash sync' - as I understood it, this means the password is going to the DC first, then the resulting hash is being passed to the cloud. This is what we have on our Hybrid 1-way tenants. But I don't really understand what's going on when I see a Password Hash Sync attempt, from another country. Is that random person passing a (wrong) password to my closed-off server? Or... is it just that the hash that Entra has to authenticate with, is from the DC? Is the 'password to DC, to Cloud' the 'passthrough' auth method? Thanks
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, ErikUnwanted MFA Method Options Displayed During Login
We have DUO configured and enforced as an MFA provider via an external authentication setup. However, during the login process, users are still being presented with additional method options, including: • Email (Receive a code to reset password) • Hardware token (Sign in with a code from a hardware token) • Phone (Call or text) • Microsoft Authenticator We want to remove at minimum the Email and Hardware token options from being shown, as these are not approved methods in our security policy. They are shown as disabled in Entra with the screenshots provided. What’s been done: • DUO is configured as an external authentication method • An exemption group has been added in Azure AD Authentication Methods policy to exclude users from using SMS and Microsoft Authenticator, yet users are still prompted to set up another authentication method during login We are in the process of transitioning users over to DUO so still need to have Microsoft authenticator as an option, but want users who are configured to use the DUO authentication method to not require another form
Fido passkeys blocked by policy
Hi all I'm helping out a customer with deploying physical passkeys and I'm running into a weird error. I've activated the sign in method and selected the two AAGuids for the Authenticator app and I've added the right AAGuid for the brand and model of passkey we are using. We can select the authentication method and enroll the security correctly but when trying to sign in using it we get the error as displayed in the attached picture. When checking the sign in logs i get this error message FIDO sign-in is disabled via policy and the error code is: 135016 I've not been able to track down any policy that would be blocking passkeys. anyone got any ideas?
