KnowledgeBase: You receive error ‘AADSTS5000812: The SAML 1.1 credential must contain exactly one or zero claims of type ImmutableID’ when signing into Azure AD-integrated resources

KnowledgeBase

In Hybrid Identity implementations, Active Directory Domain Services (AD DS), Active Directory Federation Services (AD FS) and Azure AD work together to authenticate people in your organization, so that they can work with Azure AD-integrated resources like Office 365.

Sometimes, the constellation fails and you get an error page, instead of reaching the desired application, system or service.

  

The situation

The organization has been enjoying Hybrid Identity with AD FS for several years already. They hit some snags in recent months, but no major incidents.

The organization uses multiple Active Directory forests due to recent mergers and acquisitions. They are consolidating these forests into a single Active Directory forest. All forests are in scope for Azure AD Connect. The mail attribute is used as alternative login ID.

The most recent version of Azure AD Connect is used.

  

The issue

Some people in the organization receive an error “AADSTS5000812: The SAML 1.1 credential must contain exactly one or zero claims of type ‘http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID.” instead of reaching the desired application, system or service.:

ErrorAADSTS5000812

When we use the SAML-Tracer plug-in and inspect the SAML token, we can clearly see that AD FS sign-in was successful, but that a SAML token was posted to Azure AD that, indeed, contained two values for the ImmutableID claim type.

 

The cause

The error is caused by faulty claims issuance rules.

The default rules build an ImmutableID claim type and then issue it following this process:

  1. The default rule (named ‘Query objectguid and msdsconsistencyguid for custom immutableid claim’, the second rule in the default rule set) checks if objectGUID or mS-DS-ConsistencyGUID is present.
  2. The third default rule (named ‘Check for the existence of msdsconsistencyguid’) checks if mS-DS-ConsistencyGUID is present.
  3. The fourth and fifth default rules (‘Issue msdsconsistencyguid as Immutable ID if it exists’ and ‘Issue objectGuidRule if msdsConsistencyGuid rule does not exist’) determine which value to send as Immutable ID.
  4. The sixth default rule actually sends it.

These default rules don’t take into account the mail attribute for the Immutable ID claim type. 

To remedy another device-related issue, the AD FS admin had added an additional rule. This rule added another Immutable ID value for people who were recently migrated to the new Active Directory forest:

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”]

=> issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID”), query = “samAccountName={0};objectGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”), param = c.Value);

         

The solution

We removed the additionally added rule. This made authentication work again.
Then, we built new AD FS claims issuance rules for the ‘Microsoft Office 365 Identity Platform’ Relying Party Trust (RPT) using adfshelp.microsoft.com and implemented them.

  

Concluding

I have a sneaking suspicion that upgrading Azure AD Connect in an environment with AD FS and Alternative Login ID doesn’t consistently upgrade the AD FS rules, based on the settings in Azure AD Connect.

Further reading

Pro Tip! Use the claim rules from ADFSHelp for your ‘Office 365 Identity Platform’ Relying Party Trust 
HOWTO: Enable Auditing and Logging for AD FS Servers and the AD FS Farm 
Creating the ‘Microsoft Office 365 Identity Platform’ Relying Party Trust manually

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.