I have office 365 + Onperm AD + ADFS for federation. I have configured Shibboleth as a second Claims provider (MFA enabled). When I tried to login to office 365, I get Windows AD and Shibboleth as options, when I click on Shibboleth, I get authenticated but finally I get the following error SAML 1.1 Assertion is missing ImmutableID of the user The IdP is providing the following IDPEmail = UPN ImmutableID =ObjectGUID adfssamaccountname = samaccountname I understand that I have to create a rule in ADFS, but not sure what to create Claim rule? or Claim issuance policy or both? I would appreciate your expert knowledge in this regard. Thanks in advance

Hello @Dinesh Loganathan Welcome to the Microsoft Q&A and thank you for posting your questions here. To affirm your question, you encountered an error "SAML 1.1 Assertion is missing ImmutableID" and you will need guides to create a rule in ADFS, but not sure what create either to create claim rule or claim issuance policy or both. Most of all, in the context of Active Directory Federation Services (ADFS), you typically create a claim rule to address issues related to claims transformation and issuance. A claim rule is used to define how incoming claims from an identity provider (IdP) are processed and transformed before being sent to a relying party (RP). Also, for the specific issue of mapping the ImmutableID attribute when using Shibboleth as a second claims provider in your ADFS setup, you should create a claim rule. Therefore, I provided guides here to help you with the solution required and how to create a claim rule: To resolve the SAML 1.1 Assertion missing ImmutableID issue in your ADFS setup with Shibboleth, you need to create a claim rule to map the ImmutableID attribute correctly. The ImmutableID attribute is crucial for Office 365 to correctly identify and match the user. Here are the steps to create a claim rule in ADFS: Open the ADFS Management Console: Navigate to "Start" > "Administrative Tools" > "AD FS Management." Add Claim Rule: In the ADFS Management Console, select the "Trust Relationships" node in the left pane. Right-click on "Relying Party Trusts" and choose "Add Relying Party Trust" to open the wizard. Claim Rule Configuration: Follow the wizard to configure the relying party trust settings until you reach the "Issuance Authorization Rules" page. Add Claim Rule: Click on "Add Rule" to open the "Add Issuance Authorization Claim Rule" wizard. Choose Rule Type: Choose "Send Claims Using a Custom Rule" and click "Next." Configure Rule: Enter a meaningful name for the rule. Enter similar to the following as the custom rule language to map the ImmutableID attribute: c:[Type == "http://schemas.xmlsoap.org/claims/UPN", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = ";objectGUID;{0}", param = c.Value); This rule essentially says that if the claim type is UPN and comes from the AD Authority (your Windows AD), it should issue an ImmutableID using the objectGUID. Complete Wizard: Click "Finish" to complete the claim rule creation. Apply Changes: Ensure to apply the changes to the relying party trust. Test: After configuring the claim rule, test the login process again to Office 365 using Shibboleth as the second claims provider. This claim rule should resolve the SAML 1.1 Assertion missing ImmutableID issue. Ensure that the rule is correctly configured, and the syntax is accurate. Adjustments might be necessary based on your specific configuration. NOTE: The information provided here is based on general knowledge. I hope this is helpful! Do not hesitate to let me know if you have any other questions. Please remember to "Accept Answer" if answer helped, so that others in the community facing similar issues can easily find the solution. Best Regards, Sina Salam

Hi @Dinesh Loganathan Your configurations seemed okay, without looking else to another trouble. We just need few clarifications and some additional points to consider: You need to create claims in the Claims Provider Trust (Shibboleth) based on the SAML attributes you receive from Shibboleth. These claims will map the incoming SAML attributes to ADFS claims. Ensure that the claim types, formats, and values match the SAML attributes you provided. Create Claim Issuance Policies in the Relying Party Trusts (for ClaimsXray and Office365) to specify how claims should be issued for these relying parties. In each Claim Issuance Policy, you'll define rules that determine which claims are issued and how they are mapped or transformed. For Office365, you mentioned an extra claim issuance policy for ImmutableID. Ensure that you are correctly mapping the ImmutableID claim to the corresponding attribute received from Shibboleth. You are doing a great job, check those three above and conduct all the necessary test. You should be fine. Success.

ADFS Single signon issue with external idp - SAML 1.1 Assertion is missing ImmutableID of the user

Accepted answer

Sina Salam 4,991 Reputation points

2024-01-20T21:17:02.86+00:00
Hello @Dinesh Loganathan

Welcome to the Microsoft Q&A and thank you for posting your questions here. To affirm your question, you encountered an error "SAML 1.1 Assertion is missing ImmutableID" and you will need guides to create a rule in ADFS, but not sure what create either to create claim rule or claim issuance policy or both.

Most of all, in the context of Active Directory Federation Services (ADFS), you typically create a claim rule to address issues related to claims transformation and issuance. A claim rule is used to define how incoming claims from an identity provider (IdP) are processed and transformed before being sent to a relying party (RP).

Also, for the specific issue of mapping the ImmutableID attribute when using Shibboleth as a second claims provider in your ADFS setup, you should create a claim rule.

Therefore, I provided guides here to help you with the solution required and how to create a claim rule: To resolve the SAML 1.1 Assertion missing ImmutableID issue in your ADFS setup with Shibboleth, you need to create a claim rule to map the ImmutableID attribute correctly. The ImmutableID attribute is crucial for Office 365 to correctly identify and match the user.

Here are the steps to create a claim rule in ADFS:

Open the ADFS Management Console: Navigate to "Start" > "Administrative Tools" > "AD FS Management."

Add Claim Rule: In the ADFS Management Console, select the "Trust Relationships" node in the left pane. Right-click on "Relying Party Trusts" and choose "Add Relying Party Trust" to open the wizard.

Claim Rule Configuration: Follow the wizard to configure the relying party trust settings until you reach the "Issuance Authorization Rules" page.

Add Claim Rule: Click on "Add Rule" to open the "Add Issuance Authorization Claim Rule" wizard.

Choose Rule Type: Choose "Send Claims Using a Custom Rule" and click "Next."

Configure Rule: Enter a meaningful name for the rule. Enter similar to the following as the custom rule language to map the ImmutableID attribute: c:[Type == "http://schemas.xmlsoap.org/claims/UPN", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = ";objectGUID;{0}", param = c.Value); This rule essentially says that if the claim type is UPN and comes from the AD Authority (your Windows AD), it should issue an ImmutableID using the objectGUID.

Complete Wizard: Click "Finish" to complete the claim rule creation.

Apply Changes: Ensure to apply the changes to the relying party trust.

Test: After configuring the claim rule, test the login process again to Office 365 using Shibboleth as the second claims provider. This claim rule should resolve the SAML 1.1 Assertion missing ImmutableID issue. Ensure that the rule is correctly configured, and the syntax is accurate. Adjustments might be necessary based on your specific configuration. NOTE: The information provided here is based on general knowledge. I hope this is helpful! Do not hesitate to let me know if you have any other questions. Please remember to "Accept Answer" if answer helped, so that others in the community facing similar issues can easily find the solution. Best Regards, Sina Salam
Please sign in to rate this answer.

1 person found this answer helpful.
Dinesh Loganathan 25 Reputation points

2024-01-20T23:57:56.2833333+00:00

Hello @Sina Salam , Thank you so much for the detailed explanation. I created the rule, but unfortunately, the issue is not resolved and I see the same error message. Shibboleth IdP provider informed us that the IDP provides the immutableID, but ADFS must be configured to use this attribute Attributes: IDPEmail = UPN ImmutableID =ObjectGUID adfssamaccountname = samaccountname Regards, Logan

Sina Salam 4,991 Reputation points

2024-01-21T00:10:09.9666667+00:00

Hi @Dinesh Loganathan It seems like the claim rule you created might need some adjustments. The objective is to map the UPN claim from the Shibboleth IdP to the ImmutableID attribute using the objectGUID from your Active Directory. Here's a revised version of the claim rule: c:[Type == "http://schemas.xmlsoap.org/claims/UPN", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = ";objectGUID;{0}", param = c.Value);

Please ensure that you have the correct claim type for UPN as provided by Shibboleth. If the claim type for UPN is different, you should replace "http://schemas.xmlsoap.org/claims/UPN" with the appropriate value.

Here's a step-by-step guide for creating a claim rule in ADFS:

Open the ADFS Management Console.

Navigate to "Relying Party Trusts" and select the appropriate relying party trust for Office 365.

1. Right-click on the relying party trust and choose "Edit Claim Rules..."

1. Add a new claim rule.

1. Choose "Send Claims Using a Custom Rule" and click "Next."

1. Enter a meaningful name for the rule.

1. In the custom rule language box, enter the revised claim rule.

1. Click "Finish" to complete the claim rule creation.

After applying these changes, test the login process again to Office 365 using Shibboleth as the second claims provider.

If the issue persists, consider checking the logs in both Shibboleth and ADFS for any additional error messages or information that may provide insights into the problem. Additionally, make sure that the claim types and attribute values are consistent between Shibboleth and ADFS. If necessary, work closely with Shibboleth support to ensure the correct attribute values are being provided.

Success.

Dinesh Loganathan 25 Reputation points

2024-01-21T09:49:09.1133333+00:00

Hello @Sina Salam Thanks for the prompt response. Much appreciated. The revised rule seems to be the same as the one provided earlier. c:[Type == "http://schemas.xmlsoap.org/claims/UPN", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = ";objectGUID;{0}", param = c.Value); Fyi, I have the following Claim rule under Claims Provider Trust (Shibboleth IdP) c:[Type == "urn:oid:0.9.2342.19200300.100.1.1"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = "Intech" + c.Value, ValueType = c.ValueType); This is the guide I followed https://shibboleth.atlassian.net/wiki/spaces/SHIB2/pages/2577072275/MicrosoftInterop#MicrosoftInterop-UsingShibbolethIdPastheauthenticationsourceforADFS

ADFS v3 (2012r2) Add ADFS metadata to the Shibboleth IdP: https://adfs.example.com/FederationMetadata/2007-06/FederationMetadata.xml (IdPv2 Only) Add http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password as an authentication method in handler.xml Add an allow rule to attribute-filter.xml to release some sort of username identifier. In this example, uid is used (urn:oid:0.9.2342.19200300.100.1.1) Add your shibboleth IdP as a Claim Provider to ADFS with powershell # Change these to match your environment $name = "Shibboleth IdP" $metadata = "https://idp.example.com/idp/profile/Metadata/SAML" $domainprefix = "AD-DOMAIN-PREFIX\" # Map and Tranform "uid" (username) to a Windows Account Name (e.g. "AD-DOMAIN-PREFIX\username") so AD can perform it's user matching for attribute lookups # You can extend this to pass further attributes if required, however in our use-case we rely on Active Directory to do further attribute look ups when defining relying parties as we only integrate ADFS with Microsoft Products $claims = "c:[Type == `"urn:oid:0.9.2342.19200300.100.1.1`"] => issue(Type = `"http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname`", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer,Value = `"$domainprefix`" + c.Value, ValueType = c.ValueType);" $signAlg = "http://www.w3.org/2000/09/xmldsig#rsa-sha1" #Warnings about incompatible elements are generally OK Add-ADFSClaimsProviderTrust -Name $name –MetadataURL $metadata -AcceptanceTransformRules $claims -SignatureAlgorithm $signAlg -MonitoringEnabled $true

Sina Salam 4,991 Reputation points

2024-01-21T19:27:35.1166667+00:00

I am so sorry for overlook while replying, PLEASE! If the revised claim rule is still not resolving the issue, let's review the configuration and consider a few additional troubleshooting steps:

Ensure Correct Claim Type for UPN: Confirm that the claim type for UPN provided by Shibboleth is correct. If it's different from "http://schemas.xmlsoap.org/claims/UPN," update the claim rule accordingly. Check ObjectGUID Claim Mapping: Verify that the ObjectGUID is the correct attribute in your Active Directory for uniquely identifying users. If your Active Directory is configured differently, adjust the claim rule accordingly.

Debugging and Logging: Enable detailed logging on both Shibboleth IdP and ADFS to capture more information about the SAML assertion, claims, and any errors during the authentication process. Examine the logs to identify any specific issues.

Attribute Mapping in Shibboleth: Confirm that the attribute mapping in Shibboleth is correctly configured to provide the UPN and ObjectGUID attributes to ADFS.

Attribute Statements in SAML Assertion: Inspect the SAML assertion generated by Shibboleth to ensure that the required attributes (UPN and ObjectGUID) are present in the attribute statements.

ADFS Claim Rule Syntax: Revisit the claim rule syntax to ensure there are no syntax errors. Double-check that the claim rule is correctly formatted and matches the attribute types provided by Shibboleth.

Consult Shibboleth and ADFS Documentation: Review the documentation for both Shibboleth and ADFS to ensure that you are following best practices and any specific requirements for attribute mapping and claim issuance.

Engage Shibboleth Support: If the issue persists, consider reaching out to Shibboleth support for assistance. They may be able to provide insights into any specific configurations or settings that need attention.

It's important to CAREFULLY review each step and ensure consistency in attribute names, claim types, and configurations between Shibboleth and ADFS. If the issue persists after these checks, detailed logging and, if necessary, engaging support from Shibboleth.

Dinesh Loganathan 25 Reputation points

2024-01-22T17:36:03.9833333+00:00

Hello @Sina Salam

Thank you so much for the guidance. I rechecked the configurations, did some more research, and did some testing with ADFS claimsxray tool.

To verify the configuration, I added the allow all rule in both the Relying Party (ClaimsXray) and Claims Provider (ShibbolethIDP)

x:[] => issue(claim = x); and tested the SAML authentication, results as follows.

SAML attributes are as follows:

1)

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" FriendlyName="adfsmail" a:OriginalIssuer="https://idp.myintec.org/idp/shibboleth" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>defender.test2@myintec.org</AttributeValue>

emailaddress = adfsmail - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress --result =(defender.test2@myintec.org)(AD attribute =mail)

2)

Name="IDPEmail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="UserId" a:OriginalIssuer="https://idp.myintec.org/idp/shibboleth" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>Defender.Test2@myintec.org</AttributeValue>

IDPEmail=UserId---------------------result (Defender.Test2@myintec.org)

3)

ame="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" FriendlyName="UserId" a:OriginalIssuer="https://idp.myintec.org/idp/shibboleth" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>Defender.Test2@myintec.org</AttributeValue>

upn=UserId http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

---result (Defender.Test2@myintec.org)

4)

Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="sAMAccountName" a:OriginalIssuer="https://idp.myintec.org/idp/shibboleth" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>Defender.Test2</AttributeValue>

windowsaccountname=sAMAccountName - http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname

---result (Defender.Test2)

My Login workflow as follows:

Access ClaimsXray

User will receive the adfs we page ( It contains Windows and ShibbolethIDP options)

User clicks on ShibbolethIDP

User will be authenticated by Shibboleth and MFA (backend authenticator is Windows AD)

Login successful

The same process will be applied when accessing Office365 (ADFS should query and issue ImmutableID to office365)

If my understanding is correct, I have to do the following

Create 4 claims in the Claims Provider trust (Shibboleth) to pass the above-mentioned attributes.

Create 4 Claim Issuance Policies in Relying party trust (XlaimsXray , Office365)

Create an extra claim issuance policy in Office365 for the ImmutableID (between ADFS and Office365)

FYI: My ADFS is on Windows Server 2022

I would highly appreciate it if you could check and let me know whether my understanding is right/wrong.

Thanks in advance,

Logan

Sina Salam 4,991 Reputation points

2024-01-22T22:17:59.5233333+00:00

I will station a sample and revert soon.

Dinesh Loganathan 25 Reputation points

2024-01-23T09:06:50.31+00:00

Hello @Sina Salam Yesterday, I added the allow all rule in both the Relying Party (Office365) (Production Env) and Claims Provider (ShibbolethIDP) x:[] => issue(claim = x); and tested the SAML authentication, and received the following errors:

Activity ID: c4d44128-3add-4070-3104-0040010000c3 Error details: POLICY0018: Query 'samAccountName={0};mail;{1}' to attribute store 'Active Directory' failed: 'POLICY3826: User name 'Defender.Test2' in LDAP query 'samAccountName=Defender.Test2;mail;Defender.Test2' is not in the required 'domain\user' format. POLICY3824: The LDAP query to the Active Directory attribute store must have three parts separated by semicolons. The first part is the LDAP query filter, the second part is a comma-separated list of LDAP attribute names, and the third part is the user name in 'domain\user' format.'. Node name: 374dbfe9-41f8-40be-98dc-8fc47cd08a5f Error time: Mon, 22 Jan 2024 20:28:29 GMT Cookie: enabled User agent string: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Activity ID: 191d6cef-c1f7-4257-2902-0040000000fd Error details: ID4216: The ClaimType 'IDPEmail' must be of format 'namespace'/'name'. Parameter name: claimType Node name: 374dbfe9-41f8-40be-98dc-8fc47cd08a5f Error time: Mon, 22 Jan 2024 19:51:32 GMT Cookie: enabled User agent string: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0

FYI my ADFS is configured in a Windows 2022 Server, Users are synchronized to AAD via AADConnect. Trust is also configured via AADconnect. Regards, Logan

Dinesh Loganathan 25 Reputation points

2024-01-26T10:40:46.2466667+00:00

Hi @Sina Salam Thank you so much for your response and guidance. I created the necessary claim rules and now the issue is resolved. Thanks.

Sina Salam 4,991 Reputation points

2024-01-26T14:36:24.0266667+00:00

Hi @Dinesh Loganathan Great! So good to read about your success. Keep up the good work, well done. Please remember to "Accept Answer", so that others in the community facing similar issues can easily find the solution. Cheers
Sign in to comment

Share via

ADFS Single signon issue with external idp - SAML 1.1 Assertion is missing ImmutableID of the user

1 additional answer