In the blog article series “How to integrate with LDAP”, we introduce a whole range of different options and possibilities for how you can use LDAP provided by UCS to expand or use 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 detail 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 reading our blog article first:
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 you 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 (TLS encrypted). The UCS LDAP service has two dedicated ports:
- Port 7389 (unsecure)
- Port 7636 (TLS encrypted)
If Samba is installed on the server and configured as an AD-compatible domain controller, the ports 389 (unsecure) and 636 (TLS encrypted) are reserved for Samba and can no longer be used for the OpenLDAP communication.
In case your LDAP is required to communicate with a Microsoft Active Directory the use of Samba is inevitable. In this particular case Samba will use the ports:
- 389 (unsecure)
- 636 (TLS encrypted)
An thus they can not 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:
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 in order 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, 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. This is the case in our example software Redmine. Since the the service has mandatory fields such as „username“ further LDAP attributes can be set which willl be inserted by 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, 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)
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 be 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 (e.g. 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.