I have been testing a Blazor Server app (ASP.NET Core 6.0) locally for a while with no issues. It authenticates against Azure AD, and everything works fine.
I deployed it to an IIS 10 server on Windows Server 2019 (after installing Websockets, ASP.NET hosting runtime, etc.) and now I can't get past authentication, either locally on the server or remotely.
When I hit the URL, it immediately redirects to the Microsoft Login page, where I enter my username (email), then password, then 2FA challenge, then the yes/no stay logged in page, and then it appears to hang for a short while (although in the tab it is constantly switching between "Working" and "https://login.microsoft.com...") and then it either comes up with Bad Request - Request Too Long, or just "We can't sign you in".
If it's the Bad Request error, then the cookie store will be full of .AspNetCore.Correlation.xxx and .AspNetCore.OpenIdConnectNonce.xxx cookies, which is what makes the headers too long, and creates the bad request. If it's the "we can't sign you in" error, then clicking the three dots, and saying sign out and forget, resets things which will next time result in the Bad Request error.
Just to check that I hadn't done anything stupid, I created a new blank app, using the Blazor Server template, and deployed that in place of my app. Exactly the same thing happened. I could run it locally in VS, but after publishing to IIS, exactly the same Authentication errors.
Does anyone have any ideas or pointers?
OK, for anyone who finds this in the future... it was a simple fix - but there are no error messages which point to it until you look very deeply.
When I set up both my app, and the Blazor template app, I let the scaffolder set them up, and get a secret from the Azure API, which it placed into my local secret store.
When I published the app to IIS, the ClientSecret was not copied.
The quick fix was to simply put the client secret into the appsettings.json file at which point everything came good immediately. The longer fix is to use the server-based secret store.
Apparently the looping was caused by the client secret not being present. :(
Related
No idea where else to turn at this point. We're in the final stages of developing our app, which is hosted in a Linux-based NodeJS v12 Azure Web App.
Our app hooks up to Azure AD B2C to store and manage user accounts. AD B2C is configured entirely with Custom Policies.
When we try to change our account's password via B2C, we proceed with the password change successfully, but then B2C tries to redirect us back to our website, and it fails with a 431.
The Referer is ridiculously long, and looks something like this: https://%ADTenant%.b2clogin.com/%ADTenant%.onmicrosoft.com/%CustomPolicyName%/api/SelfAsserted/confirmed?csrf_token=%Token%&tk=StateProperties=%Token%&p=%CustomPolicyName%?diags=%ListOfEncodedClaimsAndControlInformation%
Encoded, the entire thing is roughly ~1,800-1,900 characters long. We also have about ~1,000-1,100 characters in our cookies, and the destination URL is ~1,300 characters long, for a total of ~4.1-4.3k characters.
If we reload the page the referer becomes empty so the call works fine.
Strangely enough, when in Incognito, the issue does not arise; the Referer becomes empty and it works fine.
At first we thought it was the NodeJS 8KB request header size maximum, but our request header is under that. And it works locally; it only breaks when the app is in an Azure Web App, making it harder to troubleshoot.
We even added WEBSITE_AUTH_DISABLE_IDENTITY_FLOW=true to our Web App: no luck
If anyone out there has an idea, that would be amazing, as we're running thin on ideas here :(
Thanks!
I guess you can try use –max-http-header-size arg for node.
We are developing an UWP app using ADAL authentication in Azure. We have configured our client in Azure Portal with the Redirect URI taken from the result of this method:
Windows.Security.Authentication.Web.WebAuthenticationBroker.GetCurrentApplicationCallbackUri()
It was working at the beginning, but now we've noticed that the URI generated by that method has changed. Therefore our login with ADAL does not worked anymore, stating that
The reply address 'ms-app://s-1-15-2-104.......' does not match the reply addresses configured for the application.
Of course, we added the new value of the URI to the client configuration, and it worked, but after a day or two it has changed again. I think this is not the right way to update the Azure configuration every couple of days.
How can we ensure that the result of GetCurrentApplicationCallbackUri stays unchanged?
The GetCurrentApplicationCallbackUri uses your app's SID to construct the URL. I'm not sure of the exact mechanics of it, but if you are still developed the app, especially in a team, the SID can change.
One way to ensure that it remains fixed, is to create the Application in the Windows Dashboard and associate the app with the Store:
From Visual Studio - right click on the Project and select Store->Associate app with the store.
You don't have to submit, but associating the app will update the package.appxmanifest with the real values from the Dashboard and they will persist across developers.
From documentation:
To support SSO, the online provider must allow you to register a redirect URI in the form ms-app://appSID, where appSID is the SID for your app. You can find your app's SID from the app developer page for your app, or by calling the GetCurrentApplicationCallbackUri method.
I've been reading for the last hour but it's still not clear for me how to automatically authenticate the current windows user in my node js application.
On my office PC, I'm already authenticated with my AD user when I access our company portal in Chrome (as it was added as a trusted sites). So the main question for me is what do I have to do to automatically detect/authenticate the user in my nodejs app if I add my site to the trusted sites? I'm pretty sure the browser must do half of the job as it probably sends some kind of data (hash) in the request, based on which the application must authenticate the user. I suspect this is the "www-authenticate: negotiate" header as I noticed this sends a hash in the request when I access the portal.
So far, the only tracks I'm still investigating are:
https://gist.github.com/charlesdaniel/1686663
But it's still not very clear for me how this automatic authentication works and what are the leads I should follow next. The entire process is still unclear to me
I appreciate any advices on this or at least a mid-level explanation on what happens behind the scenes when I access a page in Chrome and it automatically authenticates me. Thanks
I have 2 webapi2 projects that use the same database. If I'm on localhost I get a bearer token from one I can pass it to the other and the other will properly decrypt it and load the user. However when I publish them to separate urls on azure, I get the one token fine from one but when I pass it to the other I can't get the ticket to load and it gives me the unauthorized response.
I'm testing this by watching the owin AuthenticationTokenProvider.OnRecieve method. When context.DeserializeTicket is called the ticket remains null and the user never gets loaded.
Your first response will likely be about how the machine keys need to be the same between the 2 so they will work. The problem there is
All my online research says that azure machine keys are synced between apps in the same role (ones a web app and the other is a web api app) so this shouldn't be an issue
I can't specify a machine key because the first app has been in production for a while and changing it's machine key would mess up stored passwords etc...
using the machine key used by the production app on the new api nay work but there is no way to get the machine key of an azure web app.
I'm pretty sure this isn't a machine key issue though but I have no idea how to figure this out. Heeeeelllp!
So, I thought I had this all working until I deployed to a new set of environments. I have a webapp that's authenticating just fine with multi-tenant WAAD users. But when I try to hit the webapp from an HttpClient after authenticating via AcquireTokenAsync I always get the login page as the result.
The only concrete thing I have to go in is the fact that the on-boarding process never seems to complete. The login prompt always asks me to give the WebApp and Native Client permissions.
I've triple checked client ids, tenants, app id urls, etc. Is there anything else to investigate? I hit this snag once before only for it to just start working :(
Edit #1: Webapp + api works just fine via the normal cookies, just seems to completely ignore the Bearer token I'm setting?
So it turns out I had set the Audience on the WindowsAzureActiveDirectoryBearer object incorrectly so the token was never valid...