Configure LDAP

Configure LDAP (Lightweight Directory Access Protocol) for users accessing OpsCenter.

LDAP configuration is extremely flexible with many configuration options possible within OpsCenter. To peruse all of the available [ldap] configuration options, see OpsCenter configuration properties. This procedure provides a basic configuration example to authenticate a user based on searching for a user in both user and group categories.

Prerequisites

There must be a properly configured LDAP v3 server running. The supported LDAP servers are:

  • Microsoft Active Directory:

    • Windows 2008

    • Windows 2012

  • OpenLDAP 2.4.x

  • Oracle Directory Server Enterprise Edition 11.1.1.7.0

Additional requirements:

  • If your organization started with standard OpsCenter authentication and subsequently switched to implementing LDAP, delete the old passwd.db file.

  • Roles: If using LDAP groups, create and mirror in OpsCenter the user role names and permissions that are in LDAP. Role permissions are stored in OpsCenter, not LDAP. Users must have at least one role to be able to log in to OpsCenter when LDAP is enabled.

Procedure

  1. Locate the opscenterd.conf file. The location of this file depends on the type of installation:

    • Package installations: /etc/opscenter/opscenterd.conf

    • Tarball installations: INSTALL_DIRECTORY/conf/opscenterd.conf

  2. Open the opscenterd.conf file for editing.

  3. Add an [authentication] section with the following options:

    Option Description

    password_db

    Contains the required OpsCenter user role information. The default directories are as follows:

    • Package installations: /usr/share/opscenter where sqlite3.db is stored

    • Tarball installations: install_directory/passwd.db

    enabled

    Set to True to enable LDAP authentication.

    authentication_method

    Set to LDAP, regardless if configuring Active Directory.

    Example of an [authentication] section:

    [authentication]
password_db = ./passwd.db
enabled = True
authentication_method = LDAP

  4. Set the configuration for your LDAP server. Add an [ldap] section to opscenterd.conf with the following LDAP server options as appropriate for your LDAP implementation.

    Additionally, see the [Example] to understand an SSL LDAP configuration versus an Active Directory configuration.

    Option Description

    server_host

    The host name of the LDAP server.

    server_port

    The port on which the LDAP server listens. For example, 389 or 636. * 389 is the default port for non-SSL LDAP and AD. * 636 is the default port for SSL LDAP and AD. For more information about ports, see OpsCenter ports.

    hostname_verification

    Sets whether hostname verification should happen for SSL/TLS connections.

    hostname_verification = True

    uri_scheme

    In LDAPv2 environments, TLS is normally started using the LDAP Secure URI scheme instead of the normal LDAP URI scheme. OpenLDAP command line tools allow either scheme to be used with the -H flag and with the URI ldap.conf(5) option. Defaults to ldaps for ldap_security = None; defaults to ldaps for ldap_security = SSL or TLS.

    search_dn

    The username of the user that is used to search for other users on the LDAP server. When a user attempts to authenticate with LDAP, OpsCenter searches for the user in LDAP to discover whether the user exists and which roles the user is associated with. The only permission that the search user needs to have in the LDAP system is the ability to perform LDAP searches.

    If the search_dn and search_password (that constitute the search user entry point for locating users in LDAP) are omitted from the configuration, LDAP attempts to make an anonymous bind to perform the user search.

    search_password

    The password of the search_dn user.

    user_search_base

    The search base for your domain, used to look up users. Set the ou and dc elements for your LDAP domain. For example, this can be set to ou=users,dc=domain,dc=top level domain. More specifically: ou=users,dc=example,dc=com. Active Directory uses a different user search base. For example: CN=search,CN=Users,DC=Active Directory domain name,DC=internal. More specifically: CN=search,CN=Users,DC=example-sales,DC=internal.

    user_search_filter

    The LDAP search filter used to uniquely identify a user. The default setting is (uid={0}), which looks for a user by unique user identifier. The value of the {0} variable is the username provided when logging in to OpsCenter. When using Active Directory, set the filter to (sAMAccountName={0}).

    There is a known limitation in OpsCenter when using search filters for Active Directory. See troubleshooting LDAP.

    group_search_base

    The LDAP search base used to find a group. Example: ou=groups,dc=qaldap,dc=datastax,dc=lan

    group_search_filter

    Deprecated. The LDAP search filter used to find a user’s group. Example: (member=cn={0},ou=users,dc=nodomain). Within the group_search_base, filter for members based on cn. For existing Active Directory implementations that have this configuration option already set, the group_search_filter_with_dn overwrites the returned value with the user’s DN.

    group_search_filter_with_dn

    The LDAP search filter that is used to find a user’s group. Uses the full user’s 'DN' from a user search. Overrides the deprecated group_search_filter. Example: (member={0}).

    group_name_attribute

    The LDAP field name used to identify a group’s name. For example: cn.

    admin_group_name

    The name of the admin group or a comma-separated list of admin group names; for example: admin, superusers. OpsCenter automatically creates the roles with admin permissions for the roles provided in the admin_group_name list. Escape any restricted LDAP characters. If your group name contains restricted LDAP characters such as "," a comma, you must escape them. For example, two admin groups "foo , bar" and "baz" should be entered as: foo \, bar, baz

    user_memberof_attribute

    Set to the attribute on the user entry containing group membership information. Set this option when using a memberof_search for the group_search_type.

    OpsCenter allows for an alternate method of determining a user’s role. When using memberof_search, rather than doing a directory search in LDAP for any roles that match the user, only the user is inspected. You can specify which attribute for a user is inspected. For example, you can define a user with a new attribute such as opscenter_role and populate it with the user’s role in OpsCenter. Specify the value of the new attribute so that OpsCenter can inspect the user attribute.

    group_search_type

    Defines how group membership is determined for a user.

    Available options:

    *directory_search: (Default) Performs a subtree search of group_search_base using group_search_filter to filter the results. *memberof_search: gets groups from the user_memberof_attribute of a user. Using this option requires the directory server to have memberof support. When using the memberof_search rather than directory_search for group searches, you do not need to specify the group_search_base or group_search_filter options.

    user_memberof_stores_dn

    Set to True if the memberof attribute’s value is distinguished names of groups. This option must be set to True when configuring Active Directory, OpenLDAP, or when any other LDAP implementation returns a DN for the memberOf attribute value.

    Default: False.

    Set user_memberof_stores_dn to False if the attribute specified by user_memberof_attribute denotes 0 or more group names that correspond to the roles in OpsCenter. For example, if the user_memberof_attribute is set to employeeType, set the user_memberof_stores_dn option to False because the employeeType attribute value is not a distinguished name.

    If the user_memberof_attribute_stores_dn is False and log in fails, and OpsCenter suspects the group name might be a DN, a warning is logged: [opscenterd] WARN: It looks like you might be using Active Directory for authentication. You may need to set the 'user_memberof_attribute_stores_dn' config value to True and set the group_name_attribute config value appropriately in opscenterd.conf.

    ldap_security

    The type of security to use with LDAP: None, TLS, or SSL. When set to TLS, uses TLS start. Setting this option to TLS or SSL sets the uri_scheme to LDAPS. Setting this option to None sets the uri_scheme to LDAP.

    truststore

    Path to the truststore for SSL certificates.

    truststore_type

    Type of the truststore. Default: JKS (Java Keystore).

    truststore_pass

    The password to access the truststore.

    enforce_single_user_search_result

    Returns an error when multiple entries are returned from a user search after all applicable referrals are followed. Set to False if the user_search_base is not confined to one Organizational Unit (OU). Default: True.

    connection_timeout

    The number of seconds to wait before concluding that the LDAP server is down. Default: 20 seconds.

  5. Restart OpsCenter for the changes to take effect.

Example: SSL LDAP implementation

The following example configuration reflects a typical SSL LDAP (OpenLDAP or Oracle) implementation.

The server_port value of 636 is for an SSL configuration.

If the search_dn and search_password options are omitted, LDAP attempts to make an anonymous bind to perform the user search.

This example configuration attempts to authenticate a user by searching in user categories (user_search_base and user_search_filter) and group categories (group_search_base and group_search_filter). Notice that the group_search_type is directory_search.

The user_search_base and user_search_filter options are commented out because they are only applicable to an Active Directory (AD) configuration.

[authentication]
password_db = ./passwd.db
enabled = True
authentication_method = LDAP

[ldap]
server_host = ldap.myCompany.lan
server_port = 636
hostname_verification = true
uri_scheme = ldaps
search_dn = cn=admin,dc=devldap,dc=datastax,dc=lan
search_password = ****
user_search_base = ou=users,dc=devldap,dc=datastax,dc=lan
user_search_filter = (uid=\{0})
#user_search_base = CN=search,CN=Users,DC=datastax,DC=internal # AD base
#user_search_filter = (sAMAccountName=\{0}) # AD filter
group_search_base = ou=users,dc=devldap,dc=datastax,dc=lan
group_search_filter_with_dn = (member=\{0})
group_name_attribute = cn
group_search_type = directory_search
admin_group_name = superusers,superusers2
ldap_security = SSL_TLS
truststore_type = JKS
truststore = ./truststore.jks
truststore_pass = secret

Example: Active Directory (AD) implementation

The following example reflects an Active Directory (AD) for Windows 2008 configuration. Unlike the previous LDAP example for OpenLDAP or Oracle, this AD configuration makes use of user_search_base and user_search_filter for Active Directory configuration options.

The user search base configuration for AD differs in format from the LDAP example.

The user_memberof_stores_dn option is explicitly set to True so that OpsCenter correctly handles the value of the memberof_attribute as a distinguished name (DN).

[authentication]
password_db = ./passwd.db
enabled = True
authentication_method = LDAP

[ldap]
server_host = mywin2008.myCompany.lan
server_port = 636
hostname_verification = true
uri_scheme = ldap
search_dn = CN=Administrator,CN=Users,DC=prodwin2008,DC=datastax,DC=lan
search_password = ****
user_search_base = CN=Users,DC=prodwin2008,DC=datastax,DC=lan # AD base
user_search_filter = (sAMAccountName=\{0}) # AD filter
admin_group_name = superusers
group_search_type = memberof_search
group_name_attribute = cn
user_memberof_attribute = memberof
user_memberof_stores_dn = True
ldap_security = SSL_TLS
truststore_type = JKS

Was this helpful?

Give Feedback

How can we improve the documentation?

© Copyright IBM Corporation 2026 | Privacy policy | Terms of use |  Manage Privacy Choices

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: Contact IBM