Deployment Architecture

SSO / LDAP - Is it possible to delegate the authentication step to Apache reverse proxy with a search head that doesn't have access to the LDAP server?


Hello !

We are currently building the future IT architecture of our Splunk production site, in this purpose i am testing that security requirements my customer is asking for can be achieved or not.

The challenge in a few words is having search head nodes without any access to the LDAP service, only the reverse proxy has access to LDAP and authenticates uses with SSO.

Architecture Schema:

  • In frontal zone, an active / passive cluster of Load balancers (Alteons or F5 BigIP)
  • Behind the VIP, a cluster of Apache reverse proxies with access to the LDAP secured service
  • Apache RP are using load balancing to serve request to online search head nodes
  • Apache RP uses session stickiness to ensure request from a same client are always served to the same search head node as long as it is available
  • Head server nodes (at least 2 search head nodes) have no access to the LDAP infrastructure for security purposes
  • Since search head nodes have no access to the LDAP service, the reverse proxy needs to manage every item of the authentication step and pass them in the http header for SSO over Splunk

Currently, i have tested above everything with success BUT the fact that search head nodes have no access to the LDAP.

My question: Is it possible to delegate the authentication step to RP while in the mean time search head nodes don't have access to the LDAP service ?

For testing purposes, i have built a configuration as follows: (Note i use LDAP without SSL as it is not the main challenge here)
An LDAP service with a testing organization had been built using OpenLDAP.

Testing hosts are running Debian X86, future Production will run RHEL.
Testing hosts are individual virtual machine (1 reverse proxy, 2 search head, 3 peer nodes, 1 master node, 1 deploy node, clients)
The Splunk root is set to "/splunk"

All testing hosts (and future Production hosts) will be running over Linux OS. (RHEL)

Apache 2 reverse proxy testing configuration, using mod_ldap and session stickiness:

<VirtualHost *:80>
        DocumentRoot /var/www/
        ProxyRequests Off

        <Proxy *>
          Order deny,allow
          Allow from all

        ProxyPass /balancer-manager !
        ProxyPass /splunk balancer://mycluster/

        ProxyPassReverse /splunk http://splunk-head1:8000/splunk
        ProxyPassReverse /splunk http://splunk-head2:8000/splunk

        Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED

        <Proxy balancer://mycluster>
          BalancerMember http://splunk-head1:8000/splunk route=http1
          BalancerMember http://splunk-head2:8000/splunk route=http2
          ProxySet stickysession=ROUTEID
          ProxySet lbmethod=byrequests

        <Location /balancer-manager>
          SetHandler balancer-manager

          Order deny,allow
          Allow from all

        <Location /splunk>

        AuthType Basic
        AuthBasicProvider ldap
        AuthName "Splunk Proxy Web Site: Login with User ID "

        AuthLDAPURL  "ldap://splunk-ldap:389/cn=users,dc=splunktest,dc=com?uid"

        AuthLDAPBindDN "cn=admin,dc=splunktest,dc=com"
        AuthLDAPBindPassword "admin"
        require valid-user

        RewriteEngine on
        RewriteRule .* - [E=RU:%{REMOTE_USER}]
        RequestHeader set X_REMOTE_USER %{RU}e



server.conf of search head nodes:

serverName = splunk-head1

trustedIP =


web.conf of search head nodes: ( is the IP of the Apache RP)


SSOMode = permissive
trustedIP =
remoteUser = X-Remote-User

# Splunk's root
root_endpoint = /splunk

# port number tag is missing or 0 the server will NOT start an http listener
# this is the port used for both SSL and non-SSL (we only have 1 port now).
httpport = 8000

Initially and for testing purposes, my search head nodes have the LDAP configuration in authentification.conf, notably for group mapping:

authSettings = splunk-ldap
authType = LDAP

admin = splunk-admins
power = splunk-powerusers
user = splunk-users

SSLEnabled = 0
anonymous_referrals = 1
bindDNpassword = $1$yA==
charset = utf8
groupBaseDN = ou=groups,dc=splunktest,dc=com
groupMappingAttribute = uid
groupMemberAttribute = memberuid
groupNameAttribute = cn
host = splunk-ldap
nestedGroups = 0
network_timeout = 20
port = 389
realNameAttribute = cn
sizelimit = 1000
timelimit = 15
userBaseDN = cn=users,dc=splunktest,dc=com
userNameAttribute = uid

With this configuration, and with search head nodes having access to the LDAP service, everything works absolutely like a charm.

The question is what now...

if i prohibit search head nodes from accessing the LDAP server, then the SSO won't work anymore.
If i remove the authentification.conf, the SSO won't work either.

How (and if it is possible) can i achieve the SSO / LDAP without having search head nodes communication with the LDAP service ?

Is it to possible to send the group of the user within the http header, then having only the group mapping in search head nodes authentication.conf ?

Thank you very much for any help !


1 Solution

Splunk Employee
Splunk Employee

It seems that communication between splunkd and the SSO is required (see here: ) unless users are already declared in Splunk !

View solution in original post

Splunk Employee
Splunk Employee

It seems that communication between splunkd and the SSO is required (see here: ) unless users are already declared in Splunk !


Thanks, that's right !

0 Karma
Get Updates on the Splunk Community!

Splunk Forwarders and Forced Time Based Load Balancing

Splunk customers use universal forwarders to collect and send data to Splunk. A universal forwarder can send ...

NEW! Log Views in Splunk Observability Dashboards Gives Context From a Single Page

Today, Splunk Observability releases log views, a new feature for users to add their logs data from Splunk Log ...

Last Chance to Submit Your Paper For BSides Splunk - Deadline is August 12th!

Hello everyone! Don't wait to submit - The deadline is August 12th! We have truly missed the community so ...