Configure LDAP with Splunk Web

In both Splunk Cloud Platform and Splunk Enterprise, you can use Splunk Web to configure the Lightweight Directory Access Protocol (LDAP) authentication scheme.

There are three main steps to configure the LDAP authentication scheme with Splunk Web:

1. Create an LDAP strategy.
2. Map LDAP groups to Splunk roles.
3. If you have multiple LDAP servers, specify their connection order.

If you run Splunk Enterprise and want to configure LDAP using the authentication.conf configuration file, see Configure LDAP with configuration files.

Create an LDAP strategy

When you create an LDAP strategy, you let the Splunk platform connect to an LDAP server for the purposes of authentication using the settings that you specify for the strategy.

1. Click Settings > Users and authentication > Authentication Methods.
2. Check LDAP.
3. Click Configure Splunk to use LDAP. The LDAP strategies page opens.
4. Click New. This takes you to the Add new page.
5. Enter an LDAP strategy name for your configuration.
6. Enter the Host name of your LDAP server.

   If you run Splunk Enterprise, confirm that the DNS subsystem on the machine can resolve the host name of your LDAP server. At this time, there is no support for IPv6 address formats on Windows.

7. Enter the network Port that the Splunk platform is to use to connect to your LDAP server.
   • By default LDAP servers listen on TCP port 389.
   • LDAPS, or Secure LDAP, listens on TCP port 636.
8. To turn on SSL, check SSL enabled.
   • This setting is recommended for security.
   • You must also have SSL enabled on your LDAP server.
9. Enter the Bind DN.
   • This is the distinguished name that the Splunk platform uses to bind to the LDAP server. It is typically, but not necessarily, the administrator. This user needs to have read access to all LDAP user and group entries that you want to retrieve.
   • Leave blank if an anonymous bind is acceptable.
10. Enter and confirm the Bind DN password for the binding user.
11. Specify the User base DN. You can specify multiple user base DN entries by separating them with semicolons.
    • The Splunk platform uses this attribute to locate user information.
    • You must set this attribute for authentication to work.
12. Enter the User base filter for the object class you want to filter your users on.
    • This is recommended to return only applicable users. For example: (department=IT).
    • Default value is empty, meaning no user entry filtering.
13. Enter the User name attribute that contains the user name.
    • The username attribute cannot contain white spaces.
    • In Active Directory, this is typically sAMAccountName, but you can also authenticate on other attributes, like cn.
    • The value uid works for most other configurations.
14. Enter the Real name attribute, or the common name, of the user.
    • Typical values are displayName or cn (common name).
15. Enter an Email attribute
16. Enter the Group mapping attribute.
    • This is the user attribute that group entries use to define their members.
    • The default is dn for Active Directory; set this attribute only if groups are mapped using some other attribute besides user DN.
    • For example, a typical attribute used to map users to groups is dn.
17. Enter the Group base DN. You can specify multiple group base DN entries by separating them with semicolons.
    • This is the location of the user groups in LDAP.
    • If your LDAP environment does not have group entries, you can treat each user as its own group:
      • Set groupBaseDN to the same value as userBaseDN. This means you will search for groups in the same place as users.
      • Next, set the groupMemberAttribute and groupMappingAttribute to the same attribute as userNameAttribute. This means the entry, when treated as a group, will use the username value as its only member.
      • For clarity, also set groupNameAttribute to the same value as userNameAttribute.
      • For best results when integrating Active Directory, place your Group Base DN in a separate hierarchy than the User Base DN.
18. Enter the Static group search filter for the object class you want to filter your static groups on.
    • This is recommended to return only applicable groups. For example: (|(objectclass=groupofNames)(objectclass=groupofUniqueNames))
    • Default value is empty, meaning no static group entry filtering.
19. Enter the Group name attribute.
    • This is the group entry attribute whose value stores the group name.
    • This is usually cn.
20. Enter the Static member attribute.
    • This is the group attribute whose values are the group's members.
    • This is typically member, uniqueMember, or memberUid.
21. To expand nested groups, check Nested groups.
    • This controls whether the Splunk platform will expand nested groups using the 'memberof' attribute. Only check this if you have nested groups that leverage the 'memberof' attribute to resolve their members. On OpenLDAP, you need to explicitly enable the 'memberof' overlay.
22. Enter the Dynamic group search filter to retrieve dynamic groups, if any.
    • This must match the object class of your dynamic groups definition to ensure that those groups get returned to Splunk. For example: (objectclass=groupOfURLs)
    • Default value is empty, meaning the Splunk platform will not look for dynamic group entries during authentication and authorization.
23. Enter the Dynamic member attribute.
    • This is the group attribute that uses the form of an LDAP search URL (such as ldap:///o=Acme, c=US??sub?(objectclass=person) ) to define its members.
    • This is typically memberURL.
24. If you check Advanced settings, there are several additional options you can set:
    • Enable referrals with anonymous bind only.
      • This setting is on by default. Turn this off if you have no need for referrals.
      • Splunk can chase referrals with anonymous bind only. You must also have anonymous search enabled on your LDAP server.
      • If you are seeing long LDAP search timeouts (likely in Active Directory) and "Operations error" in splunkd.log for ScopedLDAPConnection, the issues might be related to referrals.
    • Search request size limit
      • To avoid performance-related issues, you can set the search request size limit. The Splunk platform will then request that the LDAP server return the specified maximum number of entries in response to a search request. In a large deployment with millions of users, setting this limit to a high value could result in a long response, depending on the search filter set in the LDAP strategy configuration. If this limit is reached, splunkd.log should contain a size limit exceeded message.
      • You should set the search request time limit and search request size limit values in conjunction with the splunkweb timeout property, described in Configure user session timeouts. If you have a group that is not showing up in the Splunk console, it was likely excluded due to one of these limits. Tune these properties as needed.
      • To set the request size limit higher than 1000, you must also edit max_users_to_precache in limits.conf to accomodate the number of users you set for your request size limit.
    • Search request time limit
      • To avoid performance-related issues, you can set the search request time limit. The Splunk platform will then request that the LDAP server complete its search within the specified number of seconds. In a large deployment with millions of users, setting this limit to a high value could cause Splunk Web to time out. If this limit is reached on Splunk Enterprise, the splunkd.log log file will contain a time limit exceeded message.
      • You should set the search request time limit and search request size limit values in conjunction with the splunkweb timeout property, described in Configure user session timeouts. If you have a group that is not showing up in the Splunk console, it was likely excluded due to one of these limits. Tune these properties as needed.
    • Network socket timeout
      • This property is used to break the loop in the authentication chain when one of the LDAP servers in a multiple strategy configuration is unreachable due to network congestion or otherwise takes too long to respond. After waiting the specified number of seconds, the authentication process will continue with the next available strategy, if any.
      • When an LDAP strategy is first created, the Splunk platform validates the LDAP server/port and other parameters. If the LDAP server is down or one of the parameters cannot be validated at that time, the LDAP strategy does not get created.
25. Click Save.

Map LDAP groups to Splunk roles

After you have configured the Splunk platform to authenticate using your LDAP server, map LDAP groups in your environment to Splunk roles. If you do not use groups, you can map users individually.

See Map LDAP groups to Splunk roles in Splunk Web for the procedure.

Specify the server connection order

If you have enabled multiple LDAP strategies, you can specify the order in which the Splunk platform searches their servers to find a user, as described in How Splunk works with multiple LDAP servers.

By default, the Splunk platform searches the servers in the order in which they were enabled. To change the connection (search) order, you need to edit the properties for each strategy individually:

1. From the main menu, select System > Users and Authentication > Access Controls.
2. Click Authentication method.
3. Select the LDAP radio button.
4. Click Configure Splunk to use LDAP and map groups. This takes you to the LDAP strategies page.
5. Click on the strategy whose connection order you want to specify. This takes you to the properties page for that strategy.
6. Edit the Connection order field. This field appears only if you have enabled multiple strategies.

   The '''Connection order''' field does not appear when you initially create the strategy. It only appears when you later edit its properties. Also, if you have disabled the strategy, the field appears grayed out.

7. Click Save.
8. Repeat the process for any other enabled strategy whose connection order you want to change.