Articles

Splunk Authentication: SAML, LDAP, and SSO Setup (2026)

April 6, 2026 6 min read

Splunk’s authentication systems are surprisingly flexible, allowing you to integrate with your existing identity providers, but the docs can be a maze.

Let’s see Splunk handle authentication using SAML. Imagine a user, Alice, trying to access Splunk.

// Splunk logs for a successful SAML login
{
  "_time": "2023-10-27T10:00:05-07:00",
  "host": "splunk-web.example.com",
  "source": "splunkd.log",
  "sourcetype": "splunkd",
  "component": "SAML",
  "message": "SAML authentication successful for user: alice@example.com",
  "user": "alice@example.com",
  "remote_ip": "192.168.1.100"
}

This log entry shows Alice’s identity provider (IdP) successfully authenticated her, and Splunk accepted the SAML assertion.

The Core Problem: Delegating Trust

At its heart, Splunk authentication with SAML, LDAP, or SSO is about delegating trust. Instead of Splunk managing individual user credentials, it relies on an external system (your IdP) to verify who a user is. Splunk then trusts the assertion from that IdP.

  • SAML (Security Assertion Markup Language): This is an XML-based standard for exchanging authentication and authorization data between parties, specifically between an identity provider (IdP) and a service provider (SP). In our case, Splunk is the SP, and your IdP (like Okta, Azure AD, PingFederate) is the IdP. When you log in, your IdP generates a SAML assertion—a digitally signed statement saying "This user is who they say they are"—which Splunk validates.
  • LDAP (Lightweight Directory Access Protocol): This is a protocol for accessing and maintaining distributed directory information services. Splunk can connect to an LDAP server (like Active Directory) to look up user credentials and group memberships. It’s less about a single "login event" like SAML and more about ongoing credential verification.
  • SSO (Single Sign-On): This is a broader concept where a user logs in once to an identity provider and gains access to multiple applications (including Splunk) without re-entering credentials. SAML is a common mechanism to achieve SSO.

Setting Up SAML with an IdP (e.g., Okta)

  1. Configure Splunk as a Service Provider (SP):

    • In Splunk Web, navigate to Settings > Server controls > Authentication tab.
    • Under "Authentication methods," select "SAML."
    • Click "Enable SAML authentication."
    • You’ll need to configure several fields. The most critical are:
      • Entity ID: This is Splunk’s unique identifier. A common format is http://<your_splunk_host_or_fqdn>:8000. Example: http://splunk.example.com:8000
      • Assertion Consumer Service (ACS) URL: This is where your IdP will send the SAML assertion. It’s usually https://<your_splunk_host_or_fqdn>:8000/en-US/auth/saml. Example: https://splunk.example.com:8000/en-US/auth/saml
      • Single Logout URL: Used for logging out of both the IdP and SP. Typically https://<your_splunk_host_or_fqdn>:8000/en-US/auth/saml/logout. Example: https://splunk.example.com:8000/en-US/auth/saml/logout
      • Metadata URL: Splunk can expose its metadata at https://<your_splunk_host_or_fqdn>:8000/en-US/auth/saml/metadata. You’ll often provide this URL to your IdP.

  2. Configure Your Identity Provider (IdP) as a SAML App:

    • Log into your IdP (e.g., Okta).
    • Create a new SAML application.
    • You’ll need to provide Splunk’s configuration details to the IdP. This typically includes:
      • Entity ID: The same one you configured in Splunk. Example: http://splunk.example.com:8000
      • Assertion Consumer Service (ACS) URL: The same one you configured in Splunk. Example: https://splunk.example.com:8000/en-US/auth/saml
      • NameID Format: Usually EmailAddress or Unspecified. This determines how Splunk identifies the user.
      • Attribute Statements: Map user attributes from your IdP (like email, firstName, lastName, groups) to SAML attributes. Splunk uses these for role mapping. Common attributes to send are NameID (which maps to username), email, firstName, lastName.
    • Your IdP will provide you with IdP metadata. This is an XML file or a URL containing the IdP’s signing certificate, SSO endpoint URL, and Entity ID.

  3. Import IdP Metadata into Splunk:

    • Back in Splunk Web (Settings > Server controls > Authentication > SAML), find the "Identity Provider SSO settings" section.
    • Paste the IdP’s metadata URL (if provided) or upload the metadata XML file.
    • Splunk will parse this and populate the "SSO endpoint URL," "IdP Entity ID," and "Signing certificate."
    • Crucially, ensure the "Signing certificate" is correctly imported and trusted by Splunk. If this is missing or invalid, SAML assertions won’t be trusted.

  4. Configure Role Mapping (Optional but Recommended):

    • In Splunk’s SAML settings, you can map IdP groups to Splunk roles.
    • Under "Role mapping," click "Add new."
    • SAML User Attribute: Enter the name of the SAML attribute that carries group information from your IdP (e.g., groups, memberOf).
    • SAML User Value: Enter the specific group name from your IdP.
    • Splunk Roles: Select the Splunk roles you want to assign to users belonging to that IdP group.
    • Example:
      • SAML User Attribute: groups
      • SAML User Value: splunk-admins
      • Splunk Roles: administrator

  5. Test!

    • Log out of Splunk.
    • You should now see a "Login with SSO" or similar button. Clicking it should redirect you to your IdP’s login page.
    • After authenticating with your IdP, you should be redirected back to Splunk, logged in.

Setting Up LDAP Integration

LDAP is often used for user lookup and authentication directly by Splunk.

  1. Configure LDAP Server Settings:

    • In Splunk Web, go to Settings > Server controls > Authentication tab.
    • Under "Authentication methods," select "LDAP."
    • Click "Enable LDAP support."
    • You’ll need to configure:
      • LDAP server: The hostname or IP address of your LDAP server. Example: ldap.example.com
      • Port: The LDAP port (usually 389 for unencrypted, 636 for LDAPS). Example: 636
      • SSL/TLS: Enable if using LDAPS.
      • Bind DN: A user account Splunk will use to connect to LDAP. This account needs read permissions on your directory. Example: cn=splunkbind,ou=service accounts,dc=example,dc=com
      • Bind Password: The password for the Bind DN.
      • User Base DN: The distinguished name (DN) where user accounts are located. Example: ou=users,dc=example,dc=com
      • User Filter: A filter to find user objects. Example: (uid=%(username)s) or (&(objectClass=user)(sAMAccountName=%(username)s)) for Active Directory.
      • Username Attribute: The attribute in LDAP that stores the username. Example: uid or sAMAccountName.

  2. Configure Group Mapping (Optional):

    • Similar to SAML, you can map LDAP groups to Splunk roles.
    • Group Base DN: The DN where group accounts are located. Example: ou=groups,dc=example,dc=com
    • Group Filter: Filter for group objects. Example: (objectClass=group)
    • Group Membership Attribute: The attribute on a user object that lists their group memberships. Example: memberOf or gidNumber.
    • Group Name Attribute: The attribute on a group object that holds its name. Example: cn.

  3. Test!

    • In Splunk Web, navigate to Settings > Server controls > Authentication tab.
    • Under "LDAP configuration," click "Test LDAP connection." Enter a valid username and password from your LDAP directory.

When a user logs in via Splunk Web, if LDAP is enabled, Splunk will attempt to bind to the LDAP server using the provided credentials. If successful, the user is authenticated. For group mappings, Splunk queries the LDAP server to find the user’s group memberships and applies the corresponding Splunk roles.

The most overlooked aspect of SAML setup is ensuring the signing certificates are correctly exchanged and trusted. If Splunk receives a SAML assertion signed by an IdP certificate that it doesn’t trust (because the certificate is missing, expired, or the wrong one), it will reject the assertion, leading to login failures. Splunk validates the signature on the assertion against the public key of the IdP’s certificate it has stored.

Next, you’ll likely run into issues with attribute mapping for role assignments.

More Deep Dives in Splunk

Want structured learning?

Take the full Splunk course →