6

I have an ASP.NET MVC app, running as Azure Web App.

I use pre-authentication/EasyAuth, and for 5 deployment slots it works fine. Each of them has their own Azure AD App Registration.

But the production site (not a deployment slot, root of the app) throws an error when after logging in, at the /.auth/login/aad/callback path: pre-auth callback fail

I have compared Azure AD App manifest with one that works, and the only difference is the names, description and URLs - as expected.

Using Kudu to view an error, it seems to come from the EasyAuthModule: enter image description here

AjayKumar
  • 2,812
  • 1
  • 9
  • 28
MartinHN
  • 19,542
  • 19
  • 89
  • 131

2 Answers2

8

So, basically this was an issue with the App Registration used, were created from another deployment slot.

Even though Authentication / Authroization for the web app was set up as Express, the correct App Registration was selected - it turns out it did not get the Client Secret transferred from App Registration to the Web App (in my case, it had the wrong key): enter image description here

To fix it, you can switch to advanced as shown above, open the associated App Registration and create a new key: enter image description here

The key is not shown until you save, and is only shown once. Copy it, and insert it into the Client Secret input of the Web App.

After saving all the blades, it is possible to switch back to Express auth. setup and the key will remain.

MartinHN
  • 19,542
  • 19
  • 89
  • 131
2

As I cannot comment I'll add my case as an answer in a bit more detail than I would have to a comment.

I had the exact same error messages From Easyauth in an ASP.NET MVC app running as Azure App Service Web App.

The initial error message was just "The page cannot be displayed because an internal server error has occurred." And via FTP and/or Visual Studio Server Explorer and/or Cloud Explorer I could check the real error page after setting the detailed error messages on from App Service Logs. Those errors were the same as with MartinHN got using Kudu.

So in the more detailed error the predominantly shown 500.74 error originally pointed me to the wrong direction (MFA). But Request Url (.auth/login/aad/callback ) where the error message indicated the internal server error was occurring in, led me to this SO question.

In my case though I had the Advanced Configuration already selected in App Services Active Directory Authentication. And the client secret key was not just wrong. It turned out that the client secret had expired. But it wasn’t obvious to me as I don’t have access to the AAD. I had to contact a separate AD team to check the secrets.

So expired client secret (keys) can also cause this very same error.

Lupa
  • 81
  • 1
  • 11