Unable to login using Idp Unable to validate SAML response

12734
10
Jump to solution
06-10-2019 10:50 AM
WilliamShoop
New Contributor III

When trying to sign in we are receiving the error 'Unable to login using Idp Unable to validate SAML response'. Looking at the SAML responses in the SAML Message Decoder Extension, I noticed that the 'NameID' getting passed doesn't match the Portal's username. In our organization the username is the first initial and last name @ our domain for example wshoop@DQE, but the NameID getting passed is 'wshoop'. Is the @ causing issues when mapping to ADFS?

Thanks,

Bill

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
DanielUrbach
Occasional Contributor II

Bill,

The error you are getting is most likely the result of ADFS renewing it's signing/encryption SSL certificates, thus ArcGIS Online is not able to validate the signature on the SAML response with the certificate value it has on record.

You can confirm if this is the case by looking at the x509certificate value nested in the Signature element of the SAML response and seeing if it matches the certificate value contained in the "Edit Identity Provider" settings in your ArcGIS Online organization (Organization > Settings > Security > Edit Identity Provider).  If it does not match, you can update the Edit Identity Provider settings with the value contained in the SAML response.

Another way to potentially fix this would be to reconfigure the identity provider options in your ArcGIS Online organization.  You will need to get a new copy of the federationmetadata.xml file from your ADFS (which should contain the new SSL certificate values) and upload that to your AGOL organization (see https://doc.arcgis.com/en/arcgis-online/reference/configure-adfs.htm).

Let me know if this does the trick!

-Danny

View solution in original post

10 Replies
DanielUrbach
Occasional Contributor II

Bill,

I would confirm with your ADFS administrators that you are passing User-Principal-Name as NameID and not sAMAccountname within the Claims Attributes Rules in ADFS for the relying party trust you set up for your ArcGIS Online organization.

The User-Principal-Name (or UPN) typically is in the user@domain whereas sAMAccountname is usually just the username, so it looks as if the attribute was changed in your claims attributes rules.

-Danny

0 Kudos
WilliamShoop
New Contributor III

Hey Danny,

Thanks for getting back to me! And you are right! We went ahead and changed it to User-Principal-Name and the NameID is now wshoop@duqlight.com. Unfortunately we are still getting the error. I wasn't able to take a screenshot of our configuration after we made the change but please see below and just replace the SAM-Account-Name with the UPN.

Thanks!

0 Kudos
DanielUrbach
Occasional Contributor II

Bill,

The error you are getting is most likely the result of ADFS renewing it's signing/encryption SSL certificates, thus ArcGIS Online is not able to validate the signature on the SAML response with the certificate value it has on record.

You can confirm if this is the case by looking at the x509certificate value nested in the Signature element of the SAML response and seeing if it matches the certificate value contained in the "Edit Identity Provider" settings in your ArcGIS Online organization (Organization > Settings > Security > Edit Identity Provider).  If it does not match, you can update the Edit Identity Provider settings with the value contained in the SAML response.

Another way to potentially fix this would be to reconfigure the identity provider options in your ArcGIS Online organization.  You will need to get a new copy of the federationmetadata.xml file from your ADFS (which should contain the new SSL certificate values) and upload that to your AGOL organization (see https://doc.arcgis.com/en/arcgis-online/reference/configure-adfs.htm).

Let me know if this does the trick!

-Danny

WilliamShoop
New Contributor III

Thanks Daniel! That did the trick! 

Although it seems that anyone that is a member of Active Directory can logon to our Portal. Our vision was to have users that belong to Active Directory Groups (GISAdmin or GISEditor) which define their roles. Below is a snap of how our Issuance Transform Rules are set up. My thought was to remove the DefaultRule so it authenticates by the Groups. Am I on the right track?

Again thanks for resolving the SSO issue we were experiencing and sorry for perhaps diving down into a rabbit hole. Any help is appreciated.

Thanks,

Bill

0 Kudos
DanielUrbach
Occasional Contributor II

Bill,

The Issuance Transform Rules simply tell AD FS which attributes to release upon successful authentication.

If you want to limit who AD FS sends out the attributes to, you will want to set up an Issuance Authorization Rule instead.  Strangely in your screenshot I don't see the 'Issuance Authorization Rules' tab at the top of the window.  What version of AD FS are you using (or what version of Windows is AD FS on)?

If you click on the Relying Party Trust for your AGOL Org and click 'Edit Claim Rules..." on the right, you should get a window like the screenshot below.  In the Issuance Authorization Rules tab, you will want to remove the default rule ("Permit Access to All Users") and add one under the "Permit or Deny Users Based on an Incoming Claim" template:

Select "Group SID" under Incoming claim type, then click Browse and enter the names of the groups you want to allow access:

I hope this information is helpful!

-Danny

WilliamShoop
New Contributor III

Good Afternoon Danny,

Thank you so much for the above information! It was very helpful. I myself don't have access to the ADFS Server so I can't say for sure what version we are using but I can tell you our servers are Windows Server 2016. Anyway, a member of our Infrastructure team with access to ADFS and I were able to configure it to only allow members of certain AD Groups to be allowed access to our Portal with the help of the above screenshots. We are one step closer!!! 

The last step is to configure Portal Roles to the AD Groups. Currently when the user signs in for the first time the Default level and role is assigned to the new member. We would like to have the user's level and role automatically assigned based on what AD Group they are a part of.

It's a bit odd because I can see in 'My Groups' in the Portal that I am a member of the appropriate groups. Just seems like the roles are not being implemented.

Thanks again,

Bill

0 Kudos
DanielUrbach
Occasional Contributor II

Bill,

Glad to hear that is working for you!

Regarding the role assignment to new SAML users based on group membership (in Active Directory), to my knowledge there is no way to configure this although it would definitely be a great enhancement!  I would highly recommend logging a suggestion here in GeoNet or opening a case with Esri Support Services to get that enhancement logged.

If you are using ArcGIS Enterprise 10.7, you might have some luck using the new webhooks functionality, which can be set up to trigger a script to update the user's role when a new user is added.  Not the simplest solution but if you are dealing with a huge amount of SAML-based users it might save you some time.

-Danny

WilliamShoop
New Contributor III

Thanks again Danny!

I will log this suggestion to ESRI right away. We are running at ArcGIS Enterprise 10.6.1 currently so for the time being we could have Portal users with administrator privileges individually assign the appropriate levels and roles to new members. We do plan to upgrade to 10.7 in the near future so I will definitely try and take advantage of the new webhooks for this functionality.

Thanks for all your help,

Bill

0 Kudos
ChelseaRozek
MVP Regular Contributor

Thanks for the solution! Woke up to this issue and was able to resolve it quickly by importing a fresh federationmetadata.xml to Portal which fixed it for us.

0 Kudos