LDAP replication: ensuring fail-safe performance and reasonable load distribution

It is well-known among IT staff members: the administration tasks (for multiple applications and depending access rights) which apply even with a small amount of users can prove to be very time-consuming. With possible changes of responsibilities or the joining of new staff members, chances are high that uncontrolled growth arises quickly within the IT infrastructure. And not only does this procedure take a lot of time, but it also endangers the security of your system after a while. A common consequence: the administration of users and their access rights becomes a nuisance and tends to get neglected. If not taken on in due time, this problem grows in parallel with the company and will, eventually, cause quite a bit of trouble. To get back in charge as soon as possible, it is recommended to establish a centralized user management in the shape of an Identity Management System.
Quite often, the so-called LDAP directory service (which we have also integrated in UCS) is the core of the identity management system. Meaning „Lightweight Directory Access Protocol“, it rather describes „only“ the protocol itself, even though users tend to adress „the LDAP“, while in fact talking about the LDAP directory service.

Functions of the LDAP directory service

User data, necessary to authenticate a user, as well as group memberships which are used to simply map permission structures: this kind of data is made centrally available in IT networks via the LDAP directory service. This shows the decisive, business-critical role that the service takes on within the IT and thus underlines why it is important to make sure that failure (as a result of overloading, hardware damage or a lack of network connection) can be excluded.
LDAP replication is the keyword here. It describes the process of replicating the content of the directory service from a central server to (multiple) additional servers (which naturally also need an installed LDAP service). In doing so, the frequent load of requests can be distributed in a way that improves the performance of the IT infrastructure. Fail-safe performance as a result means a huge plus for enterprises, organizations etc. With multiple LDAP replicas connected in one network, the risk of a system collapse can be lowered significantly.

Possible scenarios for LDAP replication

Particulary for companies and organizations that are not limited to one single location, the LDAP replication is an excellent opportunity to increase the performance and reliability of their IT infrastructure.

Scenario “Company with several locations or branches”

In addition to its headquarters, a company operates other smaller sites. The employees working there need access to the IT infrastructure well as to the elementary running applications. In order to ensure this, a location server which can answer queries to the LDAP directories locally is set up on every company site. In case of a connection loss to the company headquarters, the workflow of the employees is not affected. There is only one restriction: changes to the directory service (e.g. to users and groups) can only be made if the central server (which we previously called “Domaincontroller Master”; with the release of UCS 5.0, the name will be changed to “Primary Directory Node”) is back online as the leading system.

Scenario “Increasing load distribution for further applications”

A young, dynamically growing company has discovered its requirement for groupware. Until now, the IT department of the company has operated one single UCS system. This UCS is already well utilized since it manages the tasks of LDAP, DNS, DHCP, Samba AD, printing- and file server. In order to be able to use the planned groupware without provoking a server failure, another server is set up. On this additional server, UCS is installed as Domain Controller Backup (with the introduction of the new names for system roles in UCS 5.0 it will be called “Backup Directory Node”). The groupware is installed on this UCS. Thanks to LDAP replication on the one hand and UCS on the other, the groupware system can now access a local copy of LDAP directory service without sending requests to the Domain Controller Master first.

Replicating LDAP directory service with UCS

Herein lies a great advantage for UCS users: the LDAP replication runs fully automatically. The process can be mapped via Univention’s own listener/notifier mechanism. Particularly useful: when setting up further UCS systems, only the roles “Domaincontroller Backup“ or “Domain Controller Slave” need to be assigned, while the Domain Controller Master is appointed as DNS server. Using DNS, the UCS to be newly installed is able to access all essential information. Usually it joins the domain automatically during the installation and also starts immediately with the LDAP replication. For the administrator, that means: manual configuration or editing of config files via command line is not necessary. The copy of the LDAP directory is ready to use once the installation process of the UCS is finished.
For further information on how to tap the full potential in terms of fail-safe performance, I‘d like to recommend the article “Fail-safe domain setup” from our help forum.

One step further: selective LDAP replication

There can be scenarios where a structuring according to organizational units in interaction with the selective LDAP replication is useful. This is the case, for example, if individual locations shall not have access to the directory contents of another location. In such a scenario the central provision of the data is still handled at the headquarters of the company or, more specifically, via the master server. However, only the contents of the respective site organizational units are replicated to the associated site server. This procedure offers the advantage that the total load within the IT structure is reduced. Furthermore, it is ensured that employees can only access the data which is relevant for them. For example, we at Univention are using this procedure as a standard with our product UCS@school, since the data of individual schools must of course be separated from each other.