Even if you only have a small number of staff, the administration of individual user accounts for numerous applications and the corresponding access rights can still prove very time consuming. When responsibilities change hands or when new members of staff join the company at the latest, the IT infrastructure becomes characterized by uncontrolled growth, which not only requires a lot of time to handle, but also becomes more and more insecure over time. More often than not, the administration of the users and their rights gets neglected at some point. As the enterprise expands, this type of out-of-control infrastructure becomes more and more risky and dangerous. Centralized user management in the form of an identity management system can help you to rein your IT back in again.
The beating heart of an identity management system is often a so-called LDAP directory service, which is also integrated in our Univention Corporate Server. LDAP stands for lightweight directory access protocol, so it really only describes the protocol itself, although people also tend to talk about “the LDAP” when they actually mean the LDAP directory service.
So what does the LDAP directory service do?
The LDAP directory service makes certain data available centrally in an IT network, such as user data, which can be used to authenticate a user, and group memberships, which can then be used to map permission structures in a simple fashion. As such, the service often takes on a decisive, business-critical role, which is why it is important to ensure that it does not fail as a result of overloading, hardware damage or a lack of network connection, for example.
The magic word here is LDAP replication. The content of the directory service is replicated from a central server to additional servers with an installed LDAP service. This makes it possible to distribute the load of the requests better, and improve the performance of the IT infrastructure. Of course, there’s always the added bonus of fail-safe performance, as if there is only one instance of the LDAP directory available and it fails, this soon becomes very obvious to the users in an enterprise or organisation. If there are several LDAP replicas in the network, the risk of a complete collapse is, logically, considerably lower.
What application scenarios are available for LDAP replications?
An LDAP replication can be used to provide the data in an LDAP directory very diversely within the IT infrastructure. This is an excellent opportunity for increasing efficiency and fail-safe performance in enterprises and organisations spread over various sites in particular.
Example application scenario “Enterprise with several sites or branches”:
In addition to its headquarters, a company also has additional branches or sites where employees need to be able to access the IT infrastructure and the applications running in the main office. To this end, a DC slave server is set up in each of the company’s branches in order to be able to deal with the requests to the LDAP directory locally. If the connection to the headquarters is interrupted, the employees can continue working without any problems. It is merely not possible to make any changes until the central master server can be reached again.
Example application scenario “Increasing the load distribution for additional applications”:
A young, dynamically evolving company has finally decided to introduce a groupware system. Until now, the enterprise used a single UCS domain controller master, which already functioned as a LDAP, DNS, DHCP, Samba AD, print, and file server. The use of the new groupware would overload the server sooner or later, which is why a second server needs to be added. A UCS will then in turn be installed as a backup or slave on which the groupware will run. Thanks to UCS and the LDAP replication, the groupware system will then have a local copy of the LDAP directory service without the need for any further interventions. The groupware can then access this local copy directly and no longer needs to send its requests to the domain controller master over the network.
So how does LDAP replication with UCS function?
Fortunately, it is completely automatic in UCS. UCS also uses the Univention-developed listener/notifier mechanism for its LDAP replication. Among other aspects, this has the advantage that the role of “domain controller backup” or “domain controller slave” merely needs to be assigned to a second, third or whatever number UCS system when it is installed, and the first UCS system specified as the DNS server. The UCS system to be installed can access all the relevant information via DNS, generally joins the domain during the installation, and starts with the LDAP replication directly. As such, there is no more need for manual configuration or even editing of config files in the command line. The replica LDAP directory is ready for use immediately after the installation.
The SDB article “Fail-safe domain setup” can also be consulted for information on how to tap the full potential in terms of fail-safe performance.
For advanced users: Selective LDAP replication
If, for example, sites are not supposed to be able to access the LDAP directory contents of other sites, a structure based on organisational units (OUs) can be used in combination with selective replication. For example, these data are stored completely on the master in the headquarters, but only the directory service contents of the respective site OUs are also replicated to the site servers. Advantage: The load across the entire IT infrastructure is considerably lower and the head of branch A does not automatically have access to the data of branch B. This principle is used as standard with the UCS@school product, for example, in order to keep the data of the individual schools separate.
Coming soon: Synchronisation and replication with Samba Active Directory