In the blog article series “How to integrate with LDAP”, we introduce a whole range of different options and possibilities for how the LDAP provided by UCS can be expanded or used in cooperation with other services.
In the first section of this article, “Typical Configuration Options”, I will be using an example to demonstrate the sort of information typically required to perform user authentication against the UCS LDAP. I will be taking you through the necessary configuration steps using the project management system Redmine as an example, as this requests all the typical information.
In the second section, “Types of Search Users”, I will go into more detail on the possibilities available to you if it is not possible to search through the UCS LDAP anonymously.
If you are not all that familiar with the topic of LDAP yet, I would recommend you read our blog article: Brief Introduction: What’s Behind the Terms LDAP and OpenLDAP? first of all.
1. Typical Configuration Options
Typical configuration options for an LDAP connection include the following elements:
- an LDAP server
- an LDAP port and
- an LDAP search filter
If the LDAP server does not permit any anonymous or unauthorized read accesses, you also need to define the following points:
- User account (using DN format) for the search
- Password for the user account for the search
The LDAP server is used to specify either the IP address or the host name – or even better the FQDN (fully qualified domain name) – of the server to be queried. The LDAP server itself also needs to be specified. For example: ucs-master.example.com.
Common designations for this field include Name, Server, and LDAP Server.
The UCS LDAP service can be reached via ports 7389 (unsecure) and 7636 (SSL encrypted). If Samba is installed on the server and configured as an AD-compatible domain controller, the ports 389 (unsecure) and 636 (SSL encrypted) are reserved for Samba and can no longer be used for the OpenLDAP communication. Tools which procure data from an MS AD should also be configured against the directory service provided by Samba.
Tools which procure data from an OpenLDAP, in contrast, should prefix the ports with a “7”. Example: 7389
Common designations for this field include Port and LDAP Port.
LDAP search filter
The LDAP search filter can be used to reduce the number of search results prior to the output, for example: only user accounts or Windows clients are queried. Example:
(&(objectClass=person)(mailPrimaryAddress=*)). This search returns objects which are a person and have a primary e-mail address.
Common designations for this field include Filter and LDAP Filter.
User for the LDAP search
If the LDAP server does not permit any anonymous search queries, a user name in the form of its distinguished name (DN) must additionally be specified in the configuration for the LDAP search. Example:
Common designations for this field include Account, BindDN and Bind-DN.
Password for the search user
The password needs to be specified for it to be possible to perform the LDAP query. The password here is unencrypted and unhashed. Such fields are normally correctly configured as password fields in a web interface, so that the password cannot be viewed.
Common designations for this field include Password and Bind-DN Password.
If a service such as Redmine, for example, maintains its own user database and only uses LDAP for user authentication, there may be an option for creating the user directly in the service’s database. As the service has its own compulsory fields for user accounts such as the user name, it is generally possible to specify LDAP attributes, which are then completed in the database. An overview of common fields can be found in the “Attributes” section.
Common designations for this option include On-the-fly user creation and Create a user, if not already available.
Some services such as Redmine, for example, maintain their own user database and only use the LDAP for user authentication. These services offer the option of connecting LDAP attributes to a field in the service. If the attribute is found in the LDAP, the value is transferred automatically and entered in the internal database.
Common attributes which are adopted include:
User name (LDAP attribute: uid)
Given name (LDAP attribute: givenName)
Surname (LDAP attribute: sn)
E-mail (LDAP attribute: mailPrimaryAddress or mail)
2. Types of Search Users
If the LDAP is configured in such a way that no anonymous LDAP searches can be performed, a user account must be specified, which can subsequently used to search the LDAP.
This can either be done using a user created in the LDAP or with the host account of a system on which a service is installed (insofar as the system has joined the UCS domain, this generally means all UCS systems).
User for the search
The configuration of the LDAP query with a user can be practical if a service is being used which is only provided on one system, as is this case in our example with Redmine.
The user’s configuration is transparent and facilitates the configuration of services, as it is immediately clear which user is being used to run the queries.
We recommend creating a specific LDAP search user so that it is not necessary to input the login data of domain users or the domain administrator in the configurations. You can find an illustrated guide in our wiki under Cool Solution – LDAP search user.
Searching with the host account
The configuration of the LDAP query with the host account can be practical if a service offers configuration of the LDAP search via a configuration file or a service is offered on multiple servers.
At the same time it is important to note that the search with the host account of the server on which the service is installed is subject to the regular and automatic changing of the server password. That means that if the server’s host account password changes it is no longer possible to perform LDAP searches with a configured service. As such, when creating the configuration file, the mechanism for changing the password for the host account must also be taken into consideration. Detailed instruction can be found in our developer documentation Documentation on Password Rotation.
One considerable advantage of the method described above is that the configuration can be rolled out simultaneously on all the servers capable of providing a similar service.
We hope that this article has been able to give you a good overview of the configuration possibilities in LDAP for connecting users.