Authenticate OpsCenter users with LDAP
The Lightweight Directory Access Protocol (LDAP) is a standard way of authenticating users across applications. OpsCenter supports LDAP authentication for external LDAP services.
When you enable LDAP authentication in OpsCenter, users that are managed by external LDAP servers can be authenticated by OpsCenter. DataStax Enterprise (DSE) supports LDAP as well. See Defining an LDAP Scheme.
LDAP must be configured for both DSE and OpsCenter if you plan to use LDAP with both applications. DSE and OpsCenter can share the same underlying user base accessed through LDAP or Active Directory, but those applications do not share their LDAP configuration settings. LDAP configuration settings for DSE and OpsCenter are nearly identical.
Supported LDAP servers
OpsCenter LDAP requires a running LDAP v3 server. The supported LDAP servers are:
-
Microsoft Active Directory (Windows 2008 or 2012)
-
OpenLDAP 2.4.x
-
Oracle Directory Server Enterprise Edition 11.1.1.7.0
LDAP group mapping
To authenticate LDAP users to OpsCenter, at least one of the user’s assigned groups must map to a role with the same name in OpsCenter. If none of the groups match, authentication fails.
Upon successful authentication, OpsCenter grants the user the permissions associated with the mapped role in OpsCenter. If a user belongs to multiple mapped LDAP groups, the user is granted the permissions for all of their mapped roles.
Role mapping is defined in the OpsCenter LDAP configuration:
-
The
admin_group_nameoption explicitly defines LDAP group names that map to OpsCenter admin roles. OpsCenter automatically creates roles for each group name specified inadmin_group_name. -
The
group_search_typeoption determines how LDAP group membership is retrieved from the LDAP server for non-admin roles:-
directory_search(default): For successful authentication, the distinguished name (DN) set in thegroup_search_filter_with_dnoption must return a list of LDAP groups that matches at least one OpsCenter role. -
memberof_search: For successful authentication, the list of LDAP roles provided by a user’smemberOfattribute must match at least one OpsCenter role. ThememberOfattribute is set in theuser_memberof_attributeoption.
You must create roles in OpsCenter for non-admin LDAP groups that require access to OpsCenter.
-
Add roles for LDAP users
For each non-admin LDAP group that requires access to OpsCenter, create a corresponding role in OpsCenter and configure the appropriate permissions. This isn’t necessary for admin groups because OpsCenter automatically creates roles for those groups.
-
Log in to OpsCenter with an OpsCenter admin user.
Admin permissions are required to create and manage roles in OpsCenter.
If you haven’t enabled any authentication strategy in OpsCenter, you must enable default authentication before you can log in as an admin user and create roles.
-
Click Settings, and then click Roles.
The Manage Roles dialog appears.
-
Click Add Role.
When LDAP is enabled, you can only manage roles in OpsCenter. User management is disabled in OpsCenter because user management is handled by the LDAP server. If you need to change a user’s role assignments when LDAP is enabled, you must change their group membership on the LDAP server.
If you delete a role in OpsCenter, the mapping is invalidated and users with that role lose the associated permissions. If a user has no other roles, they lose access to OpsCenter entirely.
-
Select a cluster.
-
Enter a role name that matches an LDAP group name.
OpsCenter LDAP supports non-ASCII character sets in role names. By extension, non-ASCII character sets are also supported in user names provided by the LDAP server.
-
Select the appropriate permissions.
You can edit role permissions at any time in OpsCenter. For existing users, the new permissions take effect the next time that they authenticate to OpsCenter.
-
Click Save.
Configure LDAP for OpsCenter
The OpsCenter LDAP configuration is flexible with many options. For demonstration purposes, these steps configure a basic LDAP authentication example that searches for users in user and group categories.
-
If you are converting to LDAP from standard OpsCenter authentication, delete the old
passwd.dbfile. -
Edit the
opscenterd.conffile.The location of this file depends on the type of installation:
-
Package installations:
/etc/opscenter/opscenterd.conf -
Tarball installations:
INSTALL_DIRECTORY/conf/opscenterd.conf
-
-
Add an
[authentication]section with the following options:Option Description password_dbContains the required OpsCenter user role information. The default directories are as follows:
-
Package installations:
/usr/share/opscenterwheresqlite3.dbis stored -
Tarball installations:
install_directory/passwd.db
enabledSet to
Trueto enable LDAP authentication.authentication_methodSet to
LDAP, regardless if configuring Active Directory.For example:
[authentication] password_db = ./passwd.db enabled = True authentication_method = LDAP -
-
Add an
[ldap]section toopscenterd.confwith the relevant LDAP server options for your environment.The following table lists commonly used options. For all options, see OpsCenter configuration properties. For examples, see Example: SSL LDAP implementation and Example: Active Directory (AD) implementation.
Option Description server_hostThe host name of the LDAP server.
server_portThe OpsCenter port on which the LDAP server listens:
-
389: Default port for non-SSL LDAP and AD. -
636: Default port for SSL LDAP and AD.
hostname_verificationWhether hostname verification should happen for SSL/TLS connections. For example:
hostname_verification = True.uri_schemeIn LDAP v2 environments, TLS is normally started using the LDAP Secure URI scheme instead of the LDAP URI scheme. OpenLDAP command line tools allow either scheme to be used with the
-HandURI ldap.conf(5)options.Defaults:
-
ldapifldap_security = None -
ldapsifldap_security = SSLorTLS
search_dnThe 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 you omit
search_dnandsearch_password, which constitute the search user entry point for locating users in LDAP, then the LDAP server connection attempts to make an anonymous bind to perform the user search.search_passwordThe password of the
search_dnuser.user_search_baseThe search base for your domain, used to look up users.
Set the
ouanddcelements for your LDAP domain. For example:ou=users,dc=domain,dc=top level domainor the more specificou=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=internalor the more specificCN=search,CN=Users,DC=example-sales,DC=internal.user_search_filterThe LDAP search filter used to uniquely identify a user.
The default value
(uid={0})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 OpsCenter authentication issues.
group_search_baseThe LDAP search base used to find a group. For example:
ou=groups,dc=qaldap,dc=datastax,dc=lan.group_search_filterDeprecated. Use
group_search_filter_with_dninstead.The LDAP search filter used to find a user’s group. The following example filters
group_search_basefor members based oncn:(member=cn={0},ou=users,dc=nodomain). For existing Active Directory implementations that have this configuration option already set,group_search_filter_with_dnoverwrites the returned value with the user’s DN.group_search_filter_with_dnThe LDAP search filter that is used to find a user’s group. Uses the full user’s
DNfrom a user search. For example:(member={0}).Overrides the deprecated
group_search_filter.group_name_attributeThe LDAP field name used to identify a group’s name. For example:
cn.admin_group_nameAn explicit mapping for the OpsCenter admin role. Provide one or more admin group names, using comma-separation for multiple group names. For example:
admin,superusers.OpsCenter automatically creates roles with admin permissions for each group name specified in
admin_group_name.Escape restricted characters, such as commas, in group names. For example, two admin groups
foo , barandbazare specified asfoo \, bar, baz.user_memberof_attributeSet to the attribute on the user entry containing group membership information. Set this option when using a
memberof_searchfor thegroup_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 an attribute likeopscenter_role, and then populate it with the user’s role in OpsCenter. Specify the value of the new attribute so that OpsCenter can inspect the correct user attribute.group_search_typeDefines how group membership is determined for a user.
Available options:
-
directory_search(default): Perform a subtree search ofgroup_search_baseusinggroup_search_filter_with_dnto filter the results. -
memberof_search: Get groups from a user’smemberOfattribute on the LDAP server, as specified in theuser_memberof_attributeoption. To usememberof_search, the directory server must supportmemberOf. Thegroup_search_baseandgroup_search_filter_with_dnoptions aren’t required.
For more information, see LDAP group mapping.
user_memberof_stores_dnSet to
Trueif the value of thememberOfattribute in your LDAP directory is distinguished names of groups. This option must be set toTruewhen configuring Active Directory, OpenLDAP, or when any other LDAP implementation that returns a DN for thememberOfattribute value.Set to
Falseif the value ofuser_memberof_attributeis an attribute that contains 0 or more group names corresponding to roles in OpsCenter. For example, ifuser_memberof_attributeis set toemployeeType, you would setuser_memberof_stores_dntoFalsebecause theemployeeTypeattribute value isn’t a distinguished name.If authentication fails when
user_memberof_stores_dnisFalseand 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_stores_dn' config value to True and set the group_name_attribute config value appropriately in opscenterd.conf.Default:
Falseldap_securityThe type of security to use with LDAP:
-
None: Don’t use TLS or SSL, and seturi_schemetoLDAP. -
TLS: Use TLS, and seturi_schemetoLDAPS. -
SSL: Use SSL, and seturi_schemetoLDAPS.
truststorePath to the truststore for SSL certificates.
truststore_typeType of the truststore.
Default:
JKS(Java Keystore)truststore_passThe password to access the truststore.
enforce_single_user_search_resultWhether to return an error when multiple entries are returned from a user search after all applicable referrals are followed.
Set to
Falseifuser_search_baseisn’t confined to one Organizational Unit (OU).Default:
Trueconnection_timeoutThe number of seconds to wait before concluding that the LDAP server is down.
Default:
20 -
-
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 = ldaps
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