We customised our Azure AD B2C tenant's Combined Sign-Up/Sign-In Policy to serve up our own login page. This worked across all the major browsers when we tested last week, but it stopped working today for some of our users on Chrome and Firefox.
We are getting this 404 error when some of our users browse to our home page and they get redirected to the login page (our B2C tenant and custom login URL is redacted but all other query parameters are unchanged):
https://login.microsoftonline.com/redacted.onmicrosoft.com/B2C_1_sign_up_in/api/CombinedSigninAndSignup/error?code=UX004&diags=%7B%22version%22%3A%222.0.0%22%2C%22user-agent%22%3A%22Mozilla%2F5.0%20(Windows%20NT%2010.0%3B%20Win64%3B%20x64%3B%20rv%3A54.0)%20Gecko%2F20100101%20Firefox%2F54.0%22%2C%22online%22%3Atrue%2C%22trace%22%3A%5B%22%231%20T005%20(3ms)%22%2C%22%232%20T027%22%2C%22%233%20T021%20(37ms)%22%5D%2C%22code%22%3A%22UX004%22%7D&csrf_token=YzQ0N3F3NXlTVzBVWTFraG96cmlVU3FVbjVNRmZRbHZ6RURIaHdPRExNRTlDRVRNL3hPN00xRXhoOUV0bnE0V3pYc3ZYcEg0YzRhVnp5WE5QYTJZN0E9PTsyMDE3LTA4LTA4VDAwOjU3OjM2Ljc3MjM1MDlaO283Mm9nSFVXb3lIbWtVZy9CeHZVbFE9PTt7Ik9yY2hlc3RyYXRpb25TdGVwIjoxfQ==&tx=eyJUSUQiOiI4MDgwNWE3Ny02OTU2LTRiNGMtYmUyYi05OGZkZGEwYzM4MDkifQ&desc=https%3A%2F%2Fourdomain.redacted.html
We have tested the following with no success:
Clearing all our cache and cooking
Disabled all extensions
Private browsing/Incognito mode
Chrome on Android
But Internet Explorer loads the custom sign-in page just fine on their computer!
I have tried searching online for error code UX004 but didn't find anything. Can someone from Microsoft advise what this error code means? Thank you.
I didn't get any response from Microsoft, but we tried various fixes. The one that worked for us is to apply a SSL certificate issued by a commonly-trusted issuer on our test domain. I can't confirm that this error message means AAD B2C is complaining of an insecure connection, but it's worth exploring in case it works for anyone else too.
It appears as though this may be a CORS issue on your hosted login page. Use (F12) to open up your developer tools, look into the Console tab and ensure you have Preserve log switched on. Navigate to the website and hopefully the error should be visible.
For me it was a CORS issue with the storage account. Adding a CORS rule that allowed everything solved the problem.
Go to azure portal (https://portal.azure.com) and open the storage account that contains your custom login page templates. In the right hand navigation find Settings > Resource sharing (CORS)
Add a new rule with the following values
Allowed origins = *
Allowed methods = Select all items
Allowed headers = *
Exposed headers = *
Max age = 200
Hopefully that helps!
Related
The Azure AD B2C - App Registrations (both current and preview) will not save my non localhost address. i.e. if I add a redirect Uri as https://localhost:44734, and save it works fine. If I add a uri as https://mysite.azurewebsites.net it will not save. The details here is slightly different depending on the part of the portal you are in.
If you are using the "App Registrations (Preview)" version, you see a notification in the top right saying "Update application Authentication". This just stays there and never finishes.
if you are using the current Applications blade you get an error stating "Application Update Error" "Cannot update Application: One of the properties provided for the application 'XXXXX' has invalid value. Please read this article (https://go.microsoft.com/fwlink/?linkid=847767) for more details.". This seems to be the case for any URL except localhost.
Also manually editing the manifest is also giving the error.
You should be able to add both localhost, and any valid url in that screen. Which seems to work on a new Application, but not an existing one.
I can not reproduce your issue on my side. I think you can create a new application to resolve this issue.
Also, you can try to delete all the reply urls and then add it again.
In the Azure Portal, in certain scenarios when it prompts me to open a URL in a new tab, I get a 403 error.
"Error 403 - This web app is stopped"
I have followed the help link on that page (https://blogs.msdn.microsoft.com/waws/2016/01/05/azure-web-apps-error-403-this-web-app-is-stopped/), but none of these issues (see footnote for issues) apply to me.
Specific examples of when I get this message:
In an app service > App Service Diagnostics > Collect Memory Dump: the report is available to view in a pop-out URL. When I click on the link, it opens a new browser tab and I can see from the url that it's attempting an oauth sign-in, which eventually displays the 403 page.
In an app service > App Service Editor (Preview), when I click on the "Go" link, as before, it opens a new browser tab and I can see from the url that it's attempting an oauth sign-in, which eventually displays the 403 page.
In both cases, it redirects to a https://****.sso.azurewebsites.net url which displays the 403 message.
Any suggestions?
Footnote: According to that url, there are 3 conditions that can cause this error to be presented.
The site has reached a billing limit and your site has been disabled.
The Website has been stopped in the portal.
The Azure Website has reached a resource quota limit that applies to either Free or Shared scale modes.
Based on Ivan's comment, I checked my role settings. I was a Contributor for this Azure subscription. Since I changed it to an Owner (via Access control IAM > Role Assignments), it now works as expected.
It's frustrating that this is not made obvious in the Azure Portal.
In my case, There were network IP restrictions applied to the site. So I was getting the same error above from my home network. You can check the rules by going to the properties tab. To modify, go to Networking->Configure access restrictions.
If you are only getting the error when you open a new tab, it could be a problem with the maximum number of connections.
Are you running in debug mode? For Basic and below the maximum number of debug connections is 1.
We have an application that we want to host only once but allow 2 different domains to direct to the one instance then we change the branding based on the incoming host. For instance https://app.abc.com points the same instance as https://app.def.com.
So they are not subdomains but rather independent domains. This would mean they also share the same Azure registered application but different return url's https://app.abc.com/auth/openid/return and https://app.def.com/auth/openid/return.
The Azure portal, however, gives the error
"You may not use more than 1 external domain(s)"
.
Is there any way around this without having to host 2 instances of the same application, each with the own Azure application/client id?
As Wayne mentioned, it is not currently possible to reply to multiple domains.
However, one workaround is to build a proxy in one of the websites. You always redirect to this proxy, which then redirects to the proper site. You could use the state parameter to store which "site" the user clicked "sign in" from, and then based on that redirect properly. You would have to be careful in making sure the token is passed through securely.
Unfortunately, you cannot achieve this.
Reply URLs must all belong to the same domain. And Redirect URIs must all belong to the same domain .This is a limitation for AAD B2C application Registration.
You can also see this note in Azure portal:
Is there any way around this without having to host 2 instances of the
same application, each with the own Azure application/client id?
For Web API or Web App, as I known, there is no way to achieve this for now.
I suggest you can upvote this idea in this Uservoice Page, AAD B2C Team will review it.
Hope this helps!
In case anyone stumbles across this issue as I did today, I found a workaround for this.
Caution: This method is not officially supported by MS according to a warning from MS in the Azure portal (see the second screenshot)
1) In your B2C tenant, navigate "All services --> search for "App registrations" --> click "App Registrations"
All services --> App registrations screenshot
2) Find your application in the application list and click on it. Note the warning from MS (see screenshot)
App registration list screenshot
3) Click on "Authentication" and add your Redirect URIs to the list. This is the same UI as non-B2C tenants.
Redirect URI list screenshot
It allowed me to enter redirect URIs with different domains. It doesn't appear to have the limitation as the "Azure AD B2C" blade. I had to wait a minute for the change to propagate, but it worked for me. I'm not going live with this anytime soon, so I'm ok with doing this for now. When I do decide to go live I'll probably find some other way of doing what I want if MS still hasn't green-lit this method.
Again, MS warns against using this at the moment, but hopefully they'll officially support it soon.
I have completed all steps properly according to the following sample.
https://github.com/Azure-Samples/active-directory-b2c-dotnet-uwp
I have completed all optional steps as well, but when I test Run Now my SignUpSignIn Policy through azure portal, it keeps loading for a while and then just displays blank white page. I am pretty confident I have configured everything properly my only doubt is the Custom Redirect URI which I have set as following :
com.onmicrosoft.fluensoft.fluennative://redirect/path
fluensoft is my tenant name
fluennative is my native app name
in case of web app/ web api there are clear instructions that redirect uri is an http call, but in case of native custom redirect uri it is very confusing.
Solution :
It was actually a network problem for that specific attempt when I tried the demo, I tried it again the next day and now it works as expected, If you are having the same problem then check your network in developer tools, also check the console just in case.
I am trying out the Azure AD-B2C. The user signup/sign in is fine when the MFA is turned off. But when I turn it on, and the user tries to sign in and provides the phone number, and requests a text message by clicking "send code", I get the Http 400 error: size of request headers is too long. Anybody else have this issue?
The error HTTP 400: Size of header request is too long generally happens because there's too many cookies.
Azure AD B2C's login goes through login.microsoftonline.com, as does almost every Microsoft service (O365, Azure, etc). So if you've got several accounts that you've signed in to across these services, you're accumulating cookies that will cause this problem.
Clearing the cookies should resolve this problem. If this is happening on a recurring basis, you should edit your question to include details about the request and cookies in order to best figure out what's bloating the request and how to reduce it.
Short answer: The file with the custom UI was not found by Microsoft login service. After getting shipped around it resulted in the error.
I had the same error with AAD B2C but "cookies" was not the problem. In my case I got the error while testing in the Azure B2C portal checking the policies and the custom UI pages. We use Azure Blob storage to hold custom login setup, its fast and it scales without our attention. The problem was found by using my test website using the B2C service. I put a stop/break on the Account controller's "public Task OnRemoteFailure(RemoteFailureContext context)" method. The debugger message gave me the full context of the error, an http 404 error and it gave the file name it was trying to find. Blob storage is case sensitive. The setup configuration used to configure B2C has camelCase names. The group who created the actual UI customization uses all lower case names. It took someone with access to all the assets to find the simple case name issue. Errors in distributed systems can be difficult.