This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(80, 8%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBH%3C/text%3E%3C/svg%3E)
We are using Entra External ID for our application. We have added users with .mil domain (e.g. example@us.af.mil) as external local members users. Per documentation, local accounts should only need a local user name (identity) / password to sign in. However, what we have found is when these .mil users try to sign in through CIAM, they are getting an error "us.af.mil isn't in our system. Make sure you typed it correctly." - it looks like Entra was trying to federate the .mil domain, even though the users are set up as local members. Has anyone experienced the same issue? Is this a bug with Entra External ID or it's by design, as agreed by the DoD?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(166.4, 27%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERP%3C/text%3E%3C/svg%3E)
Hello @BRIAN HOANG,
Thank you for posting your query on Microsoft Q&A.
I see that you mentioned DoD, and I believe your organization is operating in cross-cloud scenarios. In such cases, sign-in attempts may fail if the application is not instance-aware and does not support the instance-unaware flow.
To address this:
instance_aware parameter in the OAuth request. Refer to the Authentication scenarios in sovereign clouds documentation for more details.Following these steps will redirect the user to the appropriate cloud instance login endpoint, allowing them to complete the authentication process.
Please try the steps above and let me know if the issue persists. If the above steps didn't help, we have to do a testing to understand the scenario.
Thanks,
Raja Pothuraju.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(281.6, 17%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGM%3C/text%3E%3C/svg%3E)
@BRIAN HOANG Just checking in to see if above information was helpful. If you have any further updates on this issue, please feel free to post back.
Well, I've been working with MS support for more than a week now. And it basically boils down to the SAML functionality in the "Enterprise App" is not working correctly (yet?). We'll need to use the OpenID Connect / OAuth way so the Sign-in page doesn't try to federate with other domains, even when the users are local. Also, for other people that might stumble on this later on, it's not just the .mil domain that has this issue, it's kinda random when Entra tries to federate with another domain to sign in, even when the user is a local account.
@BRIAN HOANG Thanks for the update, help me with the support ticket details to track the resolution of this issue.
2412020040013728
Hello @BRIAN HOANG,
Thank you for sharing the details here.
I was initially unable to fully understand the scenario due to the lack of a screenshot, but based on the details you have provided, I now have a clear overview of the issue.
Yes, this behavior has been reported by several customers regarding changes to the Entra External ID login page. Specifically:
When the flow is set to isSignUpAllowed: false, the CIAM login page behaves as follows:
When the flow is set to isSignUpAllowed: true, the CIAM login page changes to:
We have informed the product engineering team about this behavior. They have identified the root cause and confirmed that a fix has been developed. The complete fix is scheduled to be rolled out to all tenants next month. Until then, this behavior will persist when isSignUpAllowed: false is configured for user flows.
I hope this information is helpful. Please feel free to reach out if you have any further questions.
If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Thanks,
Raja Pothuraju.
Hello @BRIAN HOANG,
Following up to see if the below suggestion was helpful. And, if you have any further query do let us know.
Thanks Raja. I guess we'll wait for the bug fix. Thanks for following up and monitoring this chat.
Well, just an update, upon further testing, it looks like the root cause of this issue is the "isSignUpAllowed" flag in the UserFlow (https://learn.microsoft.com/en-us/answers/questions/1611622/external-identity-user-flows-disabling-sign-up-in) If we turned off this flag then this behavior occurs. If we turned it back on then things are back to normal, except now users can self-create accounts in our tenant, which we don't want. I've seen a number of online complaints about change in behavior of this flag since that last Entra External ID release as well. Seems to me like a bug.