DocumentationAPICommunitySupportLog In

Configure LDAP for On-Premises Deployments

This article describes how to configure Authentication and Authorization in an On-Premises environment using LDAP (Lightweight Directory Access Protocol). LDAP enables enterprises to authenticate users to access OverOps by storing credentials on an external LDAP server.
To enable LDAP for OverOps you need to have access to the following properties:

  • IP address and hostname of the LDAP server
  • Bind user to access the LDAP server
  • Bind password to the LDAP server.

LDAP configuration for OverOps is carried out from the On-Premises server properties file.


Authentication is the process through which users are verified at login. By default, user accounts are managed by the OverOps analysis server. User accounts managed by OverOps, are stored and encrypted using Bcrypt (industry standard with salt strings).
OverOps also natively supports integrations with LDAP to synchronize with the chosen identity management solution.

To enable LDAP:

  1. From /opt/takipi-server/storage/tomcat/shared directory, open the file.
  2. In the file, comment out and fill in the LDAP parameters as follows:
    Set the LDAP hostname according to the distinguished name of the organization configured in your LDAP server. Format: ldap[s]://<LDAP_HOSTNAME>:[port=636]

Set the binder user for your LDAP server.
Format: cn=,dc=,dc=

Set the password for the binder user of the LDAP server.
Optional properties
Set the root to search from in the LDAP tree. Default: empty (searches the entire tree)
Set the users search query. Default: uid=? (for example: For Active Directory, use “(sAMAccountName=?)”)
The provided default includes the standard options for extracting the correct email, lastname, firstname and other parameters from the LDAP server. All parameter names in the default string are matched against the LDAP server and the relevant one is used:
Set the property names for the email property. Default: “mail;email”
Sets the property names for the first name property. Default: “gn;givenName;firstName”
Sets the property names for the last name property. Default: “sn;surName;lastName”
Sets the property names for the phone property. Default: “telephoneNumber;phone;telephone;phoneNumber”




Authorization is the control mechanism that allows authenticated users to view or change certain information.
Owners of each environment key (identified by a unique environment key) have Admin capabilities
Admins are authorized to change key and security settings, while retaining the ability to access information. They can edit code redaction policies, Storage Server location, manage user roles, etc. Admin users can set other users’ roles, and set the IP address range, from which authenticated users can access the key, to a specific network or VPN.

Manage access of team members and IP access pointsManage access of team members and IP access points

Manage access of team members and IP access points

Members access is limited. Members may view snapshots, create views, and access information in OverOps, but they cannot change key or security configurations.

Automatic Distribution of Environment Keys

Every active environment key generated by the global domain initializer can be automatically shared with users logged in via LDAP.
To configure automatic key distribution:

  • In the file, comment out and fill in the global domain initializer:

Role Based Access Control

Organizations may decided to leverage LDAP to control access to services. This requires configuration in the LDAP service itself as well as an `ldap-mapping.yaml' file configured in OverOps.

LDAP memberOf Configuration

The LDAP server should have the memberOf extension. This is enabled in OpenLDAP by default. If you do not have the memberOf extension consult our vendors documentation. The LDAP Admin would then create a group and associate that group with the user:


Keep In Mind

These are very basic examples from our development teams test LDIF file. There are many ways of managing this. Use your LDAP server tools as you see fit. The key thing to know here is that OverOps uses the memberOf attribute on the user to determine LDAP group mapping.

Example Group

dn: cn=org1,ou=groups,dc=example,dc=org
cn: org1
objectclass: groupOfUniqueNames

Example User

dn: cn=jjordan,ou=users,dc=example,dc=org
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
cn: jjordan
. . .
mail: [email protected]
userpassword: password

Example Association

dn: cn=org1,ou=groups,dc=example,dc=org
changetype: modify
replace: uniqueMember
uniqueMember: cn=jjordan,ou=users,dc=example,dc=org

Configuring the `ldap-mapping.yaml' File

Once LDAP is configured for group management we need to tell OverOps what that group has access to. In order to do this we have created the example-ldap-mapping.yaml file in the configuration directory that you can copy/rename to ldap-mapping.yaml. The file format is YAML ( it was chosen to help organize and visualize the structure of the LDAP configuration. At the top of the file is documentation on the formatting as well as an example.

The main parts are as follows:
groups - Document root that is required (do not change this)
LDAP Group names - Fully qualified path to the LDAP Group
OverOps Role name - Valid values are: ADMIN, MEMBER, VIEWER
Service Names - OverOps service names owned by the domain initializer that you wish to give access to


Since this is a configuration file there is a chance mistakes will be made. Best effort is made to give access to resources that are configurable. If an LDAP group, role or service is not found that permission will be ignored. If users are not getting access to everything they should please check the logs; when we cannot match things we will let you know.

File Handling

This file is live meaning if you create, update, or delete the file configuration changes take effect right away. While changes take effect right away the user will need to log out and log back in to see the changes in there user session.