Skip to main content
Lantern Home

 

Splunk Lantern

Troubleshooting SAML authentication for the Splunk platform

  1. Last updated
  2. Save as PDF

When using SAML authentication in the Splunk platform, you might encounter errors at login time that prevent users from accessing the system. This article provides a systematic approach to troubleshooting two common SAML authentication errors by inspecting the SAML response directly from your browser.

If you haven't yet configured SAML authentication, see Configuring SAML authentication for the Splunk platform for step-by-step setup instructions using Microsoft Entra ID.

Common SAML authentication errors

The two errors covered in this article are:

  1. "Verification of SAML assertion using the IDP's certificate provided failed. Error: failed to verify signature with cert" - This means that verification of the signature on the SAML response sent from the IdP (Identity Provider) has failed.
  2. "Saml response does not contain group information" - This means that the Splunk platform was unable to map the group information contained in the SAML response to a role.

Typical causes include:

  • The SAML signing certificate has been rotated on the IdP side, but the new metadata has not been imported into the Splunk platform.
  • The certificate contained in <X509Certificate> in the SAML response does not match the certificate that the Splunk platform trusts.
  • A configuration issue on the IdP side (for example, the response is signed with an unexpected certificate).
  • The SAML response contains a groups claim, but it does not align with the role alias or SAML groups configuration on the Splunk platform side.

This article uses Microsoft Entra ID as an example IdP, but the troubleshooting approach applies to any SAML IdP such as Okta, OneLogin, or PingFederate. The process you should use is always the same: check which claims (attributes) are configured on the IdP side, how they appear in the SAML response, and how the Splunk platform interprets them. Although the screenshots in this article are from Splunk Cloud Platform, the same troubleshooting steps also apply to Splunk Enterprise.

1. Obtain the SAML response from the browser's developer tools

The first step is to capture the actual SAML response that is reaching the Splunk platform.

  1. In the browser where the error can be reproduced, open the developer tools (DevTools). In Chrome / Edge, do this by pressing F12, and then selecting the Network tab.
  2. With the Network tab open, log in to the Splunk platform using a SAML user.
  3. Look for a POST request to https://<Splunk Server URL>/saml/acs.
  4. Select that request and open the Payload tab.
  5. In the SAMLResponse field, you will see a long Base64-encoded string. The example below shows this string as PHNhbWxw. Copy this value.clipboard_93dd52c6-5be7-4f1e-8cc8-77d5ddd46abf.png

2. Decode and inspect the SAML response

Decode the copied SAML response on the command line and format it as XML.

On Linux, macOS, or WSL:

$ echo 'PHNhbWxw...(snip)...' \
  | base64 -d \
  | xmllint --format - 2>/dev/null

This will output a nicely indented SAML response. The three main areas to check are:

  1. <Issuer> - The IdP endpoint.
  2. Attributes and AttributeValue (claims) under <AttributeStatement>.
  3. <Signature> → <KeyInfo> → <X509Certificate> - The signing certificate.

3. Verify attribute names and values against the IdP configuration

Compare the attributes in the decoded SAML response with the claim configuration on the IdP side. The following example shows the expected configuration in Microsoft Entra ID.

3-1. Example "Attributes & Claims" configuration in Entra ID

The configuration below is based on the Entra ID UI at the time of writing and is provided as an example. For the most up-to-date settings, refer to the official documentation of your IdP vendor. For the Splunk platform-specific Entra ID configuration steps, see Configuring SAML authentication for the Splunk platform.

clipboard_dceb50fc-33a3-474d-821f-f712d8ba86f6.png

Required claim:

  • Claim name: Unique user identifier (NameID)
  • Type: SAML
  • Value: user.userprincipalname
  • Format: nameid-format:emailAddress

Additional claims:

Claim name Value
http://schemas.microsoft.com/ws/2008/06/identity/claims/groups user.groups [SecurityGroup]
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress user.mail
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname user.givenname
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name user.userprincipalname
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname user.surname

3-2. Compare with the SAML response

In the formatted SAML response, check whether you see a block similar to the following:

<Subject>
  <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
    samltest@XXXXX.onmicrosoft.com
  </NameID>
  ...
</Subject>

<AttributeStatement>
  ...
  <Attribute Name="http://schemas.microsoft.com/identity/claims/displayname">
    <AttributeValue>samltest</AttributeValue>
  </Attribute>

  <Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/groups">
    <AttributeValue>groupid</AttributeValue>
  </Attribute>

  <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
    <AttributeValue>samltest@XXXXX.onmicrosoft.com</AttributeValue>
  </Attribute>
  ...
</AttributeStatement>

Verify the following:

  • Do the Attribute Names match the configuration on the Entra ID side? For example, groups, name, and emailaddress.
  • Are the values as expected? Check UPN, email address, Group Object ID, and any other values.

At this point, you can isolate whether the SAML content sent by the IdP is correct:

  • For the "Verification of SAML assertion" error: If the attributes are correct but signature verification fails, proceed to check the certificate (see step 4).
  • For the "Saml response does not contain group information" error: Check whether a groups attribute exists and whether its values are as expected (see step 6).

4. Check the X.509 certificate in the SAML response

For signature verification errors (failed to verify signature with cert), you need to determine which certificate was used to sign the response.

In the SAML response, locate the <Signature> section and extract the <X509Certificate> value:

<Signature xmlns=...>
  ...
  <KeyInfo>
    <X509Data>
      <X509Certificate>MIIC8D...</X509Certificate>
    </X509Data>
  </KeyInfo>
</Signature>

Copy the Base64 string from <X509Certificate> and store it in an environment variable called X509_CERTIFICATE for use in the next step.

5. Use openssl to check certificate validity and matching

5-1. Check certificate validity (expiration)

$ echo "$X509_CERTIFICATE" \
  | base64 -d \
  | openssl x509 -inform der -noout -dates

notBefore=Feb 16 05:13:11 2023 GMT
notAfter=Feb 20 04:28:54 2025 GMT

If notAfter is already in the past, the IdP signing certificate has expired. To resolve this, update the SAML signing certificate on the IdP side to a new certificate and import its updated metadata into the Splunk platform.

5-2. Check the fingerprint (thumbprint)

$ echo "$X509_CERTIFICATE" \
  | base64 -d \
  | openssl x509 -inform der -noout -fingerprint -sha1

SHA1 Fingerprint=12:34:56:78:AB...

Compare this value with the certificate shown as the "Thumbprint" in Entra ID.clipboard_703d8153-b33c-44d1-bf83-8e5d7270a3fb.png

A frequent cause of signature verification failure is:

  • On the Entra ID side, the SAML signing certificate has been rotated, but the new Federation Metadata XML has not been imported into the Splunk platform.
  • As a result:
    • Entra ID signs the response with the new certificate.
    • The Splunk platform still trusts the old certificate.
  • This causes signature verification to fail, resulting in the error described in this article.

To resolve this, download the updated Federation Metadata XML from Entra ID and import it into the SAML configuration for the Splunk platform. For details on importing metadata, see Configuring SAML authentication for the Splunk platform.

6. Investigate missing group information

If you encounter the "Saml response does not contain group information" error, use the decoded SAML response to verify whether group information is present.

6-1. Check whether the groups attribute is present

In the <AttributeStatement>, look for a block like this:

<Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/groups">
  <AttributeValue>groupid-1</AttributeValue>
  <AttributeValue>groupid-2</AttributeValue>
  <AttributeValue>groupid-3</AttributeValue>
</Attribute>

If Group Object IDs (GUIDs) are present, it means that the IdP is sending group information. If this attribute is completely absent, review the user.groups claim configuration on the Entra ID side.

6-2. Check Role alias and SAML Groups on the Splunk platform side

If the SAML response does contain groups but you still see the error, check how it aligns with the Splunk platform configuration:

  1. Role alias (SAML settings → Alias section): 
    Role alias = http://schemas.microsoft.com/ws/2008/06/identity/claims/groups

    With this setting, the Splunk platform interprets the groups claim from Entra ID as the group information used to determine roles.

  2. SAML Groups (Group Name → Role mapping):
    • Register the Group Object ID contained in the SAML Response (for example, 12345-6789) as the Group Name in SAML Groups.
    • Assign a Splunk role like user to that group.

If this registration is missing, then even if the SAML response contains groups, the Splunk platform cannot map them to any valid role, and the "Saml response does not contain group information" error will occur.

For detailed instructions on configuring role mapping, see the Configure role mapping section in the SAML configuration article.

Summary

Both SAML authentication errors covered in this article can be isolated by inspecting the contents of the SAML response. Use the following checklist to guide your troubleshooting:

  1. Obtain the SAML response from the browser's DevTools.
  2. Decode and inspect the Issuer, Attributes (claims), Signature, and groups.
  3. Extract the <X509Certificate> and use openssl to check the validity period and fingerprint.
  4. Compare with the IdP configuration to determine:
    • Whether the certificate has expired.
    • Whether the certificate matches the metadata imported into the Splunk platform.
  5. Check the groups attribute to verify:
    • Whether it matches the "Attributes & Claims" (user.groups) setting in Entra ID.
    • Whether it aligns with the Role alias and SAML Groups configuration on the Splunk platform side.

By following these steps, you can determine whether the issue is a certificate problem on the IdP side, a metadata or role alias issue on the Splunk platform side, or a mismatch in group information between the IdP and the Splunk platform.

Additional resources

These resources might help you understand and implement this guidance: