0

I've configured 2 instances of Sitecore to use Azure AD following this tutorial.

How to integrate Azure AD with Sitecore Content Management in 10 easy steps._

The two instances are:

  • Staging: XM single CM & CD combined configuration.
  • Production: XM single CM instance with multiple CD instances.

I first configured the staging environment, and everything worked as expected. However, in the production environment, clicking the Azure AD button on the login screen navigates to a 404 page.

Upon comparing the domains after clicking the Azure AD button, I noticed the following differences:

https://login.microsoftonline.com/[tenantID]/oauth2/authorize?client_id=[ClientId]&redirect_uri=[encoded return URL]

But the production one will navigate to itself:

https://[SI doamin]/[tenantID]/oauth2/authorize?client_id=[ClientId]&redirect_uri=[encoded return URL]

It's confusing because I used the same configuration in both environments.

Should this URL be configured using the well-known(or similar) page generated by the authority?

Has anyone else encountered this problem?

Improve this question
6
  • 1
    Can you also please share the Azure AD configuration which you have on production.
    – ckhanna
    Commented Jul 5 at 6:57
  • Hi, I've not had access to the Azure Entra configuration. The security team has just provided what is required ClientId, TenantId, and GroupIds (We have 4 groups) in this tutorial. I've now requested the information from them and will update. I suspect the configuration is correct tho. Because it's navigating to the correct domain in staging. So that would hint something is different on the production CM server.
    – Anthony
    Commented Jul 7 at 21:01
  • 1
    is the identity server configuration same as well on staging and Prod..Did you managed to check that as well..
    – ckhanna
    Commented Jul 7 at 21:14
  • Yes the "./sitecore/Sitecore/Plugin.IdentityProvider.AzureAd/Config/Sitecore.Plgin.dentityProvider.AzureAd.xml" are exactly the same when I compare the Production and Staging environments. The "./sitecore/Sitecore.Plugin.IdentityServer/Config/identityServer.xml" are not altered and are the same. On the CM server "./App_Config/Sitecore/Owin.Authentication.IdentityServer/Sitecore.Owin.Authentication.IdentityServer.config". The only difference between the servers is the <sc.variable name="identityServerAuthority"... /> but that is expected, and they are pointing to the correct domains.
    – Anthony
    Commented Jul 7 at 22:35
  • 1
    The registered domain is correct in the Azure Entra App. But what I have noticed, (which might be my issue) is that there are *.xdt files on the app services itself. Applying IIS rewrite and redirect rules. The only registered domain against the app services is the default generated azure domain. So seems infrastructure might be playing tricks on me. I'll come back soon with some kind of answer...
    – Anthony
    Commented Jul 9 at 22:07

1 Answer 1

Reset to default
0

In the end, the issue was unrelated to Sitecore or the Azure AD configuration. The problem originated from the Azure Resource configuration. The infrastructure team lacked full access to DNS management, so they used Host Headers and *.xdt files to add custom IIS redirects/rewrites, tricking the domains into hosting correctly. Consequently, the SI service couldn't interpret this setup and defaulted to using its own domain.

To resolve this issue, double-check your hosted file system and ensure the domains are set up as expected. Verify that your infrastructure team didn't implement any unconventional configurations. Ensure the DNS records are correctly configured and bound. Once these steps are confirmed, the SI service should function properly.

Thanks.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.