Study guide
6.1 Integrating Splunk with LDAP
Splunk Enterprise Certified Admin SPLK-1003
Track your progress as you read
Finished sections get a check mark.
1 Introduction
About the Splunk Enterprise Certified Admin Exam
2 Chapter 1: Splunk Admin Basics
1.1 Splunk Enterprise Architecture & Core Components
3 Chapter 2: License Management
2.1 License Types, Stacks, Pools & Licensing Architecture 2.2 License Violations, Rolling Window Warnings & Troubleshooting
4 Chapter 3: Splunk Configuration Files
3.1 Splunk Configuration Directory Structure 3.2 Configuration Layering, Precedence & Resolution Rules 3.3 Using btool to Inspect & Debug Configurations
5 Chapter 4: Splunk Indexes
4.1 Index Structure: Directories, Buckets & Bucket Files 4.2 Bucket Types & the Hot-Warm-Cold-Frozen-Thawed Lifecycle 4.3 Checking Index Data Integrity 4.4 indexes.conf Options: Paths, Bucket Sizing & Volumes 4.5 The Fishbucket: File Tracking, CRC Collisions & Re-reading Files 4.6 Applying a Data Retention Policy
6 Chapter 5: Splunk User Management
5.1 Splunk Roles, Capabilities & Custom Role Design 5.2 User Account Administration, Search Restrictions & Limits
7 Chapter 6: Splunk Authentication Management
6.1 Integrating Splunk with LDAP 6.2 Other Authentication Options & Enabling Multifactor Authentication
8 Chapter 7: Getting Data In
7.1 CLI Administration & Basic Data Onboarding Workflows 7.2 Forwarder Types: Universal Forwarder vs. Heavy Forwarder
9 Chapter 8: Distributed Search
8.1 How Distributed Search Works 8.2 Roles of the Search Head and Search Peers 8.3 Configuring Search Peers & Distributed Search Groups 8.4 Search Head Scaling & Search Head Clustering (SHC)
10 Chapter 9: Getting Data In – Staging
9.1 Ingestion Pipeline Stages: Input, Parsing, Merging, Typing & Indexing 9.2 Pipeline Component Placement & Queue Management 9.3 Splunk Input Options
11 Chapter 10: Configuring Forwarders
10.1 Forwarder Setup & outputs.conf Load Balancing 10.2 Indexer Acknowledgment, Data Cloning & Forwarder Routing
12 Chapter 11: Forwarder Management
11.1 Deployment Management & the Deployment Server 11.2 Deployment Apps & Deployment Clients 11.3 Server Classes, Client Grouping & App Deployment Strategies 11.4 Forwarder Management Monitoring & Troubleshooting
13 Chapter 12: Monitor Inputs
12.1 File & Directory Monitoring Mechanics 12.2 Monitor Input Tuning: Whitelists, Blacklists & CRC Settings 12.3 Deploying a Remote Monitor Input, Network Shares & Archives
14 Chapter 13: Network and Scripted Inputs
13.1 Creating Network Inputs: TCP & UDP 13.2 Optional Settings for Network Inputs 13.3 Scripted Inputs & PowerShell Data Collection
15 Chapter 14: Agentless Inputs
14.1 Windows Management Instrumentation (WMI) Inputs 14.2 HTTP Event Collector (HEC) Architecture & Administration
16 Chapter 15: Fine Tuning Inputs
15.1 Input-Phase Processing & Default Metadata Assignment 15.2 Character Set Encoding & Handling Binary Data
17 Chapter 16: Parsing Phase and Data
16.1 Line Breaking & Event Segmentation 16.2 Timestamp Extraction, Time Zones & Clock Skew Handling 16.3 Validating Event Parsing with Data Preview
18 Chapter 17: Manipulating Raw Data
17.1 Transformation Mechanics: props.conf & transforms.conf 17.2 Data Masking, Redaction & SEDCMD 17.3 Event Routing, Dynamic Index Assignment & Filtering to nullQueue
6.1 Integrating Splunk with LDAP
Key Takeaways Explain This Topic AI
authType in [authentication] selects Splunk (native), LDAP, Scripted, SAML, or ProxySSO; authSettings lists the LDAP strategies to use.
Native accounts are always tried first; Splunk tries LDAP only when the username does not exist locally.
An LDAP strategy defines host, port (389, or 636 with SSLEnabled = 1), bindDN and bindDNpassword, userBaseDN, userNameAttribute, groupBaseDN, and group attributes.
Groups map to roles in [roleMap_<strategy>] (role = group1;group2); you map either groups or users, and users in no mapped group cannot use Splunk.
When SAML is down, a native admin can still log in at /en-US/account/login?loginType=splunk.
Last updated: September 2026
LDAP Authentication in Splunk Enterprise
Blueprint domain 6 covers integrating Splunk with LDAP , the other user authentication options , and the steps to enable multifactor authentication . This section covers the authentication framework and LDAP. The next section covers SAML, scripted authentication, ProxySSO, and MFA.
Authentication Architecture in authentication.conf
The authentication subsystem is orchestrated through $SPLUNK_HOME/etc/system/local/authentication.conf . The core [authentication] stanza declares the active authentication mode and the resolution chain: [authentication]
- authType = LDAP
- authSettings = corp_ad_primary,corp_ad_dr
- Supported Authentication Types ( authType )
Splunk : Native local authentication. Splunk validates credentials against hashes stored in $SPLUNK_HOME/etc/passwd .
LDAP : Splunk queries external directory services over LDAP or LDAPS protocols, binding with a service account and verifying credentials against directory trees.
SAML : Splunk delegates authentication to an external Identity Provider (IdP) using the SAML 2.0 federated protocol.
Scripted : Custom external authentication through a script you supply.
ProxySSO : A reverse proxy authenticates the user and passes the identity to Splunk.
Precedence of Authentication Schemes
Native Splunk authentication is always tried first . If it fails for any reason other than "no such local user", Splunk does not try LDAP. Only when the user does not exist locally does Splunk attempt LDAP, and then scripted authentication.
Strategy Failover Chains ( authSettings )
With LDAP you can configure several strategies , typically one per LDAP server, and list them in authSettings . When multiple strategies are enabled, Splunk searches their servers in connection order to find the user. That order is set in Splunk Web through each strategy's Connection order field, which appears when you edit a strategy after more than one is enabled.
Local Authentication Fallback & Break-Glass Architecture
A critical design principle in Splunk Enterprise is that local accounts defined in $SPLUNK_HOME/etc/passwd remain intact and functional even when external authentication (LDAP or SAML) is actively configured .
Why Local Fallback is Essential
If external network connectivity fails, directory services crash, IdP signing certificates expire, or DNS resolution breaks, administrative personnel must retain the ability to authenticate to resolve the underlying failure.
The SAML Web Bypass Workflow ( loginType=splunk )
When authType = SAML is enabled, navigating to the Splunk Web root URL ( https://<searchhead>:8000/ ) automatically issues an HTTP 302 redirect sending the browser to the external IdP SSO page.
To bypass this redirection and authenticate using a local emergency account:
Open a browser and navigate explicitly to: https://<splunk_server>:8000/en-US/account/login?loginType=splunk
Splunk Web bypasses the SAML redirection handler and displays the native Splunk username/password login dialog.
Enter local administrative credentials (e.g., the default admin account).
Splunk verifies the credentials directly against $SPLUNK_HOME/etc/passwd .
REST API & CLI Fallback
The Splunk management port (TCP 8089) and CLI commands do not utilize SAML browser redirects. Commands such as splunk search ... -auth admin:LocalPassword or REST API calls against https://<searchhead>:8089/services/authentication/ always evaluate local credentials directly, ensuring headless orchestration and configuration management tools remain operational during IdP outages.
LDAP Integration Deep Dive
LDAP integration allows Splunk to authenticate users against corporate directories (such as Microsoft Active Directory or OpenLDAP) and map directory security groups to Splunk roles.
Transport Security: Port 389 vs. Port 636
TCP Port 389 (Plain LDAP or StartTLS): Transmits directory data. Plain LDAP should never be used across untrusted networks because credentials are sent in plaintext. If port 389 is utilized, StartTLS must be enabled.
TCP Port 636 (LDAPS - LDAP over SSL/TLS): Industry standard for enterprise deployments. The entire session is wrapped in TLS encryption. Enable it with SSLEnabled = 1 in the strategy (or the SSL enabled checkbox), and SSL must also be enabled on the LDAP server. Splunk uses the OpenLDAP and OpenSSL libraries, so client-side certificate trust follows OpenLDAP's ldap.conf conventions (Splunk's copy is under $SPLUNK_HOME/etc/openldap/ ).
- Stanza Structure in authentication.conf [authentication]
- authType = LDAP
- authSettings = corp_active_directory
- [corp_active_directory]
- # Network connection parameters
- host = ad.corp.example.com
- port = 636
- SSLEnabled = 1
- # Service Bind Account credentials
- bindDN = cn=splunk_svc,ou=ServiceAccounts,dc=corp,dc=example,dc=com
bindDNpassword = EncryptedSecretToken!
- # User Search Configuration
- userBaseDN = ou=Users,dc=corp,dc=example,dc=com
- userBaseFilter = (&(objectCategory=person)(objectClass=user))
- userNameAttribute = sAMAccountName
- realNameAttribute = displayName
- emailAttribute = mail
- # Group Search Configuration
- groupBaseDN = ou=Groups,dc=corp,dc=example,dc=com
- groupBaseFilter = (objectCategory=group)
- groupNameAttribute = cn
- groupMappingAttribute = dn
- groupMemberAttribute = member
- nestedGroups = 1
- Key Parameter Explanations
bindDN : The distinguished name of the service account used by Splunk to query the directory. Use a dedicated, read-only service account whose password does not expire unexpectedly.
bindDNpassword : The bind account password. If you type it in plaintext in authentication.conf , splunkd encrypts it the next time it starts.
userNameAttribute : The directory attribute containing the user's login ID ( sAMAccountName in Active Directory; uid in OpenLDAP).
nestedGroups : When set to 1 (enabled), Splunk recursively evaluates group memberships, resolving users who belong to child groups nested within a parent security group.
Mapping Directory Groups to Splunk Roles
Group-to-role mappings are declared in a dedicated stanza formatted as [roleMap_<strategy_name>] : [roleMap_corp_active_directory]
- # Splunk Role = Directory Group 1; Directory Group 2
- admin = Splunk_Enterprise_Admins;Domain Admins
- power = Splunk_Power_Users;Security_Engineers
- user = Domain Users;Engineering;IT_Helpdesk
If an LDAP user belongs to multiple mapped groups (e.g., both Splunk_Power_Users and Domain Users ), Splunk assigns the user both the power and user roles.
When you map by group, every LDAP user who should log in must belong to a mapped group. A user in no mapped group gets no Splunk role and cannot use Splunk.
You map either groups or users , not both. To map users directly, point groupBaseDN at the same location as userBaseDN in authentication.conf .
In Splunk Web: Settings > Authentication Methods > LDAP > Configure Splunk to use LDAP , then Map groups for the strategy and move roles into Selected Roles .
Applying and Testing LDAP Changes
Changes made in Splunk Web take effect when you save. After editing authentication.conf by hand, run splunk reload auth (or restart) so splunkd rereads the file.
Test with a user from each mapped group and confirm the roles under Settings > Users . LDAP users appear there after they log in.
Inspecting splunkd.log for LDAP Error Codes
When troubleshooting LDAP failures, administrators search $SPLUNK_HOME/var/log/splunk/splunkd.log (index=_internal) for LDAP errors. The numbers below are standard LDAP result codes:
LDAP Error 49 (Invalid Credentials): The bindDNpassword is incorrect, or the service account is locked out or expired in Active Directory.
LDAP Error 32 (No Such Object): The userBaseDN or groupBaseDN path does not exist in the directory tree (check for typos in OU/DC syntax).
LDAP Error 81 (Server Down): Splunk cannot establish a TCP socket to the host and port (check network firewalls, routing, or DNS resolution).