Community
Select to view content in your preferred language

SAML (Azure Entra ID) Encrypted Assertion Failure on DR Replica Environment – ArcGIS Enterprise 11.5

139
3
2 weeks ago
AYUSHYADAV
by
Frequent Contributor
2 weeks ago

Hi Everyone,

We are running into an issue configuring SAML authentication (using Azure Entra ID) for our Disaster Recovery (DR) environment.

Environment Details

  • Deployment Setup: Production and DR (Disaster Recovery) environments — both are exact replicas of each other.

  • ArcGIS Enterprise Version: 11.5

  • OS: Windows Server

  • Deployment Type: High Availability (HA)

  • Web Context URL: Identical on both Prod and DR

  • SSL Certificates: Identical on both Prod and DR

Use Case & Goal

To ensure members can seamlessly sign in after a failover event to our DR environment, we are configuring matching SAML certificates across both identical environments.

We followed the guidelines in the Esri documentation:

Reference: Organization-specific login considerations for geographic redundancy

Steps Completed So Far

  1. Configured SAML Logins: Set up SAML authentication on both the Prod and DR environments using the same Federation Metadata URL.

  2. Exported/Imported SAML Certificate: Exported the SAML certificate from Production and imported it into the DR environment.

  3. Enabled Encrypted Assertions (Prod): Turned on Encrypted Assertions on the Production environment. ------> Working as expected.

  4. Enabled Encrypted Assertions (DR): Turned on Encrypted Assertions on the DR environment. ------> Fails.

Issue & Error Details

When enabling Encrypted Assertions on the DR environment, authentication fails.

AYUSHYADAV_0-1785471471868.png

 

 

Has anyone encountered this behavior or can point out if we are missing any specific configuration steps for replica environments in Entra ID or ArcGIS Enterprise?

Thanks in advance for your assistance!

Regards,

Ayush

0 Kudos
3 Replies
ArchitSrivastava
by
Frequent Contributor
a week ago

Hello @AYUSHYADAV ,

Since Production is working and DR only fails after enabling Encrypted Assertions, I would probably focus first on the SAML encryption certificate side rather than the general SAML setup.

A few things I would check:

  • Does SAML login work in DR when Encrypted Assertions is turned off?
  • When the SAML certificate was exported from Production and imported into DR, was the private key included as part of that import?
  • In the DR HA setup, is the same SAML certificate available on both Portal machines?
  • If you download the SAML metadata from both Production and DR, do the encryption certificate, Entity ID, and Assertion Consumer Service URL look the same?
  • In Azure Entra ID, is token/assertion encryption using the certificate that matches what DR has?
  • Are the Identifier / Entity ID and Reply URL / ACS URL in Entra ID still correct for the failover scenario?
  • After importing the certificate into DR, was the SAML configuration saved or refreshed again in the DR portal?
  • Do the Portal logs show anything related to decryption, certificate mismatch, or private key issues?
  • Do the Entra ID sign-in logs show the SAML response being issued successfully, or does the failure happen before it comes back to Portal?

My thinking is that encrypted assertions depend on Entra ID encrypting the assertion with the public certificate, and Portal then needing the matching private key to decrypt it. So even if Prod and DR look identical from the outside, a missing private key or a certificate mismatch in DR could cause this kind of issue.

I would start by comparing the Production and DR SAML metadata side by side, especially the encryption certificate section, Entity ID, and ACS URL. If those look correct, then I would check whether the DR Portal actually has the matching private key available for decryption.

0 Kudos
AYUSHYADAV
by
Frequent Contributor
a week ago

Hi Archit,

Thanks for your reply. Here are the answers and details to your questions:

1. Does SAML login work in DR when Encrypted Assertions is turned off?

  • Answer: Yes, it works as expected after disabling Encrypted Assertions.

2. When the SAML certificate was exported from Production and imported into DR, was the private key included as part of that import?

  • Answer: Could you guide us on how to verify if the private key was included during the import?

Below are the exact steps we followed:

  1. Log in to the Production portaladmin endpoint.

  2. Go to Machines > SSL Certificates > samlcert > Export.

  3. Log in to the DR portaladmin endpoint.

  4. Go to Machines > Machine 1 > SSL Certificates > samlcert > Delete.

  5. Go to Machines > Machine 2 > SSL Certificates > samlcert > Delete.

  6. Go to Machines > Machine 1 > SSL Certificates > Import Root or Intermediate > Import the samlcert file exported from Production.

  7. Go to Machines > Machine 2 > SSL Certificates > Import Root or Intermediate > Import the samlcert file exported from Production.

Note: We did not use "Import Existing Server Certificate" because it prompts for a password, and we do not have the password for this SAML certificate.

3. In the DR HA setup, is the same SAML certificate available on both Portal machines?

  • Answer: Yes, it is available and imported on both machines.

4. If you download the SAML metadata from both Production and DR, do the encryption certificate, Entity ID, and Assertion Consumer Service URL look the same?

  • Answer: Yes, they are 100% identical.

5. In Azure Entra ID, is token/assertion encryption using the certificate that matches what DR has?

  • Answer: Yes.

6. Are the Identifier / Entity ID and Reply URL / ACS URL in Entra ID still correct for the failover scenario?

  • Answer: Yes.

7. After importing the certificate into DR, was the SAML configuration saved or refreshed again in the DR portal?

  • Answer: Yes, it was saved and we restarted the DR Portal machines.

8. Do the Portal logs show anything related to decryption, certificate mismatch, or private key issues?

  • Answer: Yes, please see the attached screenshot of the logs.AYUSHYADAV_0-1785745294734.png

     

9. Do the Entra ID sign-in logs show the SAML response being issued successfully, or does the failure happen before it comes back to Portal?

  • Answer: We do not have access to the Azure Entra ID sign-in logs.

Summary & Next Steps

I agree with your analysis: encrypted assertions require Entra ID to encrypt with the public key, and Portal requires the matching private key to decrypt it. Because we imported via "Import Root or Intermediate", the private key was likely omitted, which aligns with what the portaladmin logs indicate.

Could you help us verify if the private key is present on the DR certificate, or advise on the correct procedure to export/import the private key?

Thanks,

Ayush

0 Kudos
ArchitSrivastava
by
Frequent Contributor
a week ago

Hello @AYUSHYADAV ,

Thanks for sharing the details and the Portal log screenshot.

The log message seems important here:

Invalid_SAMLResponse: Unable to login using Idp. Error validating encrypted Assertion Unable to decrypt without a KEK

The lower log entry also says:

Exception in signIn using saml Unable to login using Idp. Error validating encrypted Assertion Unable to decrypt without a KEK

Since DR SAML login works when Encrypted Assertions is turned off, it looks like the general SAML flow is likely working. The Entity ID, ACS URL, metadata, and basic Entra configuration may be okay. The failure seems to happen specifically when Portal needs to decrypt the encrypted assertion.

Looking at the steps you followed, the part I would focus on is this:

You imported the Production samlcert into DR using Import Root or Intermediate.

From my understanding, that option is meant for importing root or intermediate CA certificates. It would not normally be the path used to make the DR Portal use the samlcert as the active SAML encryption/decryption certificate.

For this specific DR SAML scenario, I would follow Esri’s geographic redundancy documentation closely:

Disaster recovery and replication | ArcGIS Enterprise on Windows and Linux documentation

In the Organization-specific login considerations for geographic redundancy section, Esri lists this SAML workflow:

  1. Export samlcert from the Production portaladmin endpoint.
  2. Delete the existing samlcert from the standby/DR portal.
  3. Use Import Signed Certificate to import the exported certificate into the standby/DR portal.
  4. Configure SAML in the standby environment.

So I would try that documented path rather than importing the certificate as Root or Intermediate.

For the private key side, this Esri documentation may also help:

Import a certificate into the portal | ArcGIS Enterprise on Windows and Linux documentation

That page notes that when importing an existing server certificate, the certificate and its associated private key must be stored in PKCS#12 format, such as .p12 or .pfx. That also explains why Import Existing Server Certificate asks for a password.

This Esri Support article for encrypted assertions with Microsoft Entra ID may also be useful for comparing the Entra token encryption side:

Create a Certificate and Enable SAML Encrypted Assertions with ArcGIS and Microsoft Entra

Since you mentioned that you do not have access to the Azure Entra ID sign-in logs, it may be worth checking this with your Entra ID admin as well. They can help confirm whether Entra is issuing the SAML response successfully, whether encrypted assertions are enabled against the correct Enterprise application, and whether the certificate being used for token/assertion encryption matches what the DR Portal is expecting.

So I think the next thing to verify is not only whether samlcert is visible on the DR Portal machines, but whether it was imported using the correct DR workflow and whether Portal has access to the key material required to decrypt encrypted assertions.

The log message Unable to decrypt without a KEK seems to point strongly in that direction.

Hope it helps!

0 Kudos