Status code=responder, SSO disabled

[pl2345]

Running Splunk Enterprise 8.0.0 on an internal network.
I went away on vacation for a few weeks with Splunk working fine and came back to it not. I'm not sure how long it had been down, and no one could really tell me what changed. The first problem was a service account password policy was implemented, so Splunk's service account password changed and it wasn't updated in services to launch Splunk. Once that was changed we could launch Splunk, and then received the errors.

Originally we were using ADFS for SSO and it worked fine, but now when going to the site we get the error, "IDP failed to authenticate. Status Code="Responder" Check Splunkd.log for more information about the failure."
I enabled web debug and it shows SSO Enabled as No.
The certificate has not expired.
I removed and set up SSO again following https://www.splunk.com/en_us/blog/cloud/configuring-microsofts-adfs-splunk-cloud.html
Currently I just log in locally to ensure it's still collecting data.
The splunkd logs show:

ERROR Saml - No extra status code found in SamlResponse, Not a valid status. Could not evaluate xpath expression /samlp:Response/samlp:Status/samlp:StatusMessage or no matching node foundNo value found in SamlResponse for key=/samlp:Response/samlp:Status/samlp:StatusMessage or no matching node foundCould not evaluate xpath expression /samlp:Response/samlp:Status/samlp:StatusDetail/Cause or no matching node foundNo value found in SamlResponse for key=/samlp:Response/samlp:Status/samlp:StatusDetail/Cause
ERROR UiSAML - IDP failed to authenticate request. Status Message="" Status Code="Responder"
ERROR UiSAML - IDP failed to authenticate request. Status Code="Responder"

[pl2345 · Accepted solution]

This seemed to fix it on one of our domains:

Splunk SAML Request Signing does not appear to work with ADFS and the requirement for it must be disabled on the Relying Party Trust. Disabling SAML Request Signing for the Relying Party Trust must be done from a PowerShell command. Open an elevated PowerShell command window and run the following command. Be sure to use the correct Identifier for the Relying Party Trust:

1. Get-AdfsRelyingPartyTrust -Identifier splunkEntityId | Set-AdfsRelyingPartyTrust - SignedSAMLRequestRequired $false
2. Next, the Claims Rules need to be created within the Relying Party Trust.
3. Right-click the newly created Relying Party Trust and choose Edit Claims Rules… Issuance Transform Rules tab > Click Add Rule…
4. Choose Rule Type > In the Claim Rule Template pull down, choose Send LDAP Attributes as Claims, and click Next.
5. Configure Claim Rule > Enter a name, e.g. “Send Name, Mail and Groups”, for the Claim Rule Name and select Active Directory in the Attribute Store pulldown menu. Add the following items to the Mapping of LDAP attributes to outgoing claim types table and click Finish:

LDAP Attribute (Select or type to add more)	Outgoing Claim Type (Select or type to add more)
Display-Name	realName
E-Mail-Addresses	mail
Token-Groups – Unqualified Names	Role

Customize the newly created rule. ADFS will ALWAYS use the Role schema string as if selected from the pulldown, even if the user manually types “role” for the Outgoing Claim Type in the table. Splunk will not recognize this schema string to associate the groups to the “role” label as required. An easy way to get the proper claim rule is to create the claim with the wizard to get the claim language, then copy and modify the claim rule language to create a new custom rule. Afterwards the original rule can be deleted, leaving only the custom version of the rule.

1. Highlight the claim rule that was configured to Send LDAP Attributes and click Edit Rule…
2. Click the View Rule Language at the bottom and copy the entire contents of the claim rule language box. Then click OK.
3. Click Cancel to close the Edit Rule box.
4. Click the Add Rule… button to create a new rule.
5. Choose Rule Type > In the Claim Rule Template pulldown, select Send Claims Using a Custom Rule. Click Next.
6. Configure Claim Rule > Enter a name in the Claim Rule Name box and paste the copied Claim Rule Language into the Custom Rule box.
7. Modify the Claim Rule Language as described below to replace the “Role” schema string: Original Claim Rule Language -
   1. c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("realName", "mail", "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = ";displayName,mail,tokenGroups;{0}", param = c.Value);
8. Modified Claim Rule Language -
   1. c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("realName", "mail", "role"), query = ";displayName,mail,tokenGroups;{0}", param = c.Value);
9. Click finish.
10. Highlight the originally created claim rule and click Remove Rule…, leaving only the newly created Custom Rule.
11. Create another rule with the Add Rule… button
12. Choose Rule Type > In the Claim Rule Template pull down, choose Transform and Incoming Claim, click Next.
13. Configure Claim Rule > Enter a name, e.g. “NameID”, in the Claim Rule Name field.
14. In the Incoming Claim Type pulldown:
15. Select UPN
16. In the Outgoing Claim Type pulldown, select Name ID
17. In the Outgoing name ID format pulldown, select Transient Identifier
18. Leave the rest of the items as their default selections and click Finish.

[terminaloutcome]

What'd you end up doing to fix this? I've got the same problem and can't work it out 😞

[pl2345]

We were never able to get SSO back up with Splunk, but its currently on our to do list. If I figure it out I'll let you know.

[FlorianScho]

Hi,

we also get this error in a new instance. Old configurations on other systems are working fine and ADFS seems to be configured correctly (like the working one). 

EDIT: pl2345 answer resolved it!