It’s always recommended that after you set up your Splunk environment, you should also configure a central authentication mechanism if you have plans to grow your Splunk user base. Luckily, there are various authentication options offered by Splunk, and you can choose whichever suits your needs. However, on this page, we shall address the various measures that must be taken when integrating Splunk with the LDAP authentication option.
LDAP is a popular authentication option as it is easily integrated with many providers like Microsoft Active Directory. And because of its simplicity, it supports more than one source. If you are getting started with the configuration of LDAP in the Splunk instance, there are some aspects you must be familiar with. These include the information-gathering stage, implementation of configurations as well as best deployment practices.
Use of a central Authentication Mechanism
Setting up local accounts is easier, but managing them can be quite challenging. However, these challenges can be addressed using central authentication mechanisms like LDAP. Using LDAP and another central authentication mechanism, we can use similar credentials to log in to corporate resources like Splunk.
Central management can be automated to add/remove access to Splunk as employees join and leave the organization when dealing with the account life cycle. Through these measures, the process of synchronizing accounts and credentials can easily be streamlined whenever the data is updated.
Information gathering
Before configuring LDAP, there are certain pieces of information required which includes
- The host running LDAP
- The Port for which the LDAP host is running where you can consider TCP/389 or TCP/636
- Service account with permission to bind to LDAP server (referred to as Bind DN)
- Password for Bind DN user account
- User Base DN or the user location data on the LDAP structure
- Location of the group that will need s-plunk access (group base DN)
- The standardized naming convention for groups
This information might seem complicated and too much when you are just getting started. But remember your security matters; that’s why all that information is essential to keep every user safe.
LDAP host
The LDAP host might vary significantly depending on your working environment. Another factor determining the type of LDAP host is whether it’s an active directory LDAP source or just another provider. Using a DNS name as a host is recommended, but it’s also not recommended to rely on a single host, which can be catastrophic in case of failures. If you use an active directory controller, you can point to the specified domain controller. However, we think it’s best to point to a high-end DNS name for your domain. Doing so will return a multi-value DNS record, thereby increasing a degree of redundancy because your site isn’t tied status of any single domain controller.
For seamless operation, the Splunk instance should be able to successfully make LDAP queries top any domain controller returned by DNS. There will be a need to make some network and firewall settings adjustments to enable effective communication between DNS and LDAP.
LDAP Port
It’s advisable to run SSL encrypted LDAP connection that runs on TCP/636. When using unencrypted LDAP on TCP/389, the data security can be compromised at any time as its sent in clear-text format. To connect to the Active Directory Global Catalog port, TCP/3269 (SSL) or TCP/3268 (insecure), you’ll have to configure your LDAP for it to access these ports. The kind of your Active Directory Admin/Architect will determine if there is a need for GC configuration.
Bind DN + Password
Making LDAP quarries isn’t possible without binding DN with persimmon for accessing LDAP. This applies to almost all LDAP environments unless it permits anonymous binds. However, anonymous binds aren’t encouraged as they can be a source of security bridge. The user should be able to read LDAP data on users and groups that want to sign in to Splunk. The distinguished name format is the specific format for the usernames and begins with a common name (CM). A simple code would look like this.
CN=splunk-ldap,OU=service-accounts,DC=your-domain,DC=com
Considering the example above, Splunk-ldap is the username, and it’s from a group/organization known as service account. The letters DC in the command line above refer to the domain component and are displayed as your-domain.com.
The user must also have an associated password to be added to Splunk settings. It’s advisable to consider the password expiration policy that your organization may have in place for the user’s account. The expiration of user credentials can prevent LDAP users from signing into Splunk. If you need to maintain a local account with administrative privileges and can be used for troubleshooting authentication or backup access when LDAP failure
User Base DN + Filter
Active Directory LDAP environment contains objects for several users. There are also non-user accounts like services and machines. User Base Filter and User Base DN instruct Splunk where to search in LDAP to get user information. Based on the active directory structure you are using; chances are high that user information may be located in one or more branches of the LDAP tree. Splunk supports more than one User Base DN, which can be effective for companies with this configuration. If you are specifying several User Base DNs, it’s advisable to separate them using a semicolon instead of space.
A simple example includes OU=Users,dc=your-domain, dc=com, but when you are specifying multiple DNs, then a typical example would look like this;
OU=Splunk-Users,OU=Groups,OU=US,DC=your-domain,DC=com;OU=Splunk-Users,OU=Groups,OU=EU,DC=your-domain,DC=com
In this example, the LDAP tree is branched to EU and US groups, each having Splunk user groups that are part of user Base DN. It, therefore, implies that the Splunk instances will search branches of LDAP trees for user information.
Group Base DN + Filter
User Base DN is for LDAP, while Group Base DN is for LDAP groups. Splunk relies on Group Base DN to get information were search groups in the LDAP environment. In case there is more than one location for groups, it can be specified in Splunk instances. Other than Group Base DN, Splunk user groups have consistent naming conventions. A practical example of Group Base DN looks like OU=Groups,dc=your-domain,dc=com. We can specify multiple group Base DNs and separate them by a semicolon. Splunk groups have to be named beginning with Splunk example, Splunk-users, or Splunk admin. When you apply a Group Base Filter, it will limit the output of the specified groups. If you wish to filter several group names, you can also specify them easily. To add a member of a group, begin with security; you can have a group base filter similar to (|(CN=Splunk-*)(CN=Security-*))
Nested Group
Based on your LDAP settings, you can have user objects directly in the groups, or groups can also be added to groups. When there is a group within a group, you’ll have to configure Splunk to use nested groups to follow members of extensions and expand the groups whenever needed.