LDAP Port
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”.
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:
uid=searchuser,cn=users,dc=example,dc=com
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.
User Creation
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.
Attributes
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.