In “Fail-safe performance and load distribution thanks to LDAP replication” I focused on describing the UCS OpenLDAP directory service. Unfortunately, OpenLDAP is only of comparatively little help to me if I want to operate Windows systems in my network, as Windows doesn’t speak the standard-compliant LDAP protocol as a rule, but rather a particular dialect that Microsoft selected for its Active Directory. I would now like to explain which technologies integrated in Univention Corporate Server we can use to deal with this situation and go into more detail about the replication via listener/notifier for OpenLDAP, DRS replication for the Active Directory and the “Univention S4 Connector”, which synchronises between the two worlds.
UCS has always been proud of its claim to be able to manage heterogeneous networks and build bridges connecting the Linux/Unix world with the Windows world. In order to allow the uncomplicated operation of Windows systems in a UCS domain, UCS also offers Active Directory-compatible domain services with the help of the Samba software suite, thus superseding the Microsoft Windows domain controller.
In order to be able to serve both the Linux clients and servers as well as the applications based on them and the Windows systems and their applications equally, a second, AD-compatible directory service is set up on a UCS system in addition to the OpenLDAP directory service which is always found there. This AD-compatible Samba directory service then also occupies the standard ports for LDAP 389 and 636 – because the Windows systems expect a directory service there which behaves likes Active Directory. In contrast, the OpenLDAP directory service uses ports 7389 and 7636 – the (re)configuration of the employed ports on client systems generally goes without any hitches. This is already the case automatically on UCS and UCC systems.
So, we now have one directory service for the Linux world and one directory service for the Windows world. The major advantage of UCS at this point is the automatic synchronisation between the two directory services. This is performed by Univention’s own “Univention S4 Connector”, which adopts the respective change in the other directory service as soon as relevant changes are made in one of the two directory services. In this way, the information in both worlds is always kept up to date and the two directory services are merged to create one shared domain.
In addition, Samba also takes over the Kerberos service in this scenario and provides its directory service as a DNS backend for the name server ISC Bind.
How does the replication function now?
As explained in the previous article, the replication of the directory service to server systems offers a range of different advantages. Whilst UCS implements a hierarchical replication model, the replication in Active Directory (and thus of course also with Samba AD domain controllers) is as so-called multi-master replication – each domain controller can replicate from and with every other domain controller. This is where the Directory Replication Service (DRS) comes into its own.
Multi-master replication has a number of advantages – for example, a change can subsequently be adopted on any domain controller – but also involves a number of disadvantages – for example, it is not possible to perform selective replication simply as mentioned in the previous article on OpenLDAP. The multi-master replication also scales more poorly in direct comparison – if each domain controller needs to communicate with every other domain controller, that process alone already creates a substantial load on the systems and at network level. Active Directory offers though further possibilities with its “site concept”.
Putting the pieces together
We also have hierarchical replication via listener/notifier for OpenLDAP, multi-master replication via DRS for Active Directory and the “Univention S4 Connector”, which synchronises between the two worlds.
The Univention S4 Connector is actually installed on all UCS domain controllers, but always only enabled on one. By default this is the first UCS system on which Samba is installed as the Active Directory-compatible domain controller. The UCS DC master is usually recommended for this role.
Changes performed via the web-based Univention Management Console (UMC), for example, arrive in OpenLDAP first of all and then, insofar as relevant, are replicated to the remaining UCS systems via the Univention listener/notifier mechanism. At the same time, the Univention S4 Connector synchronises the change, insofar as relevant, to the Samba directory service. Samba then replicates the change to the other Samba AD servers via DRS.
The process also functions in the same way in the opposite direction: For example, when a user changes their password on a Windows client, the change is initially performed against one of the Samba AD domain controllers. This in turn then replicates it to the UCS DC master via DRS and other mechanisms, where the Univention S4 Connector then synchronises the change of the password hash to OpenLDAP, from where the information is passed on to the remaining OpenLDAP instances by the listener/notifier. The same applies if the Windows Remote Server Administration Tools (RSAT) are used to create or modify users or groups for example. I also have this option with UCS.
Via these mechanisms, which transmit the changes on one directory service to the other directory service and its replicas in the blink of an eye, UCS also opens up the possibility of managing even large, heterogeneous IT infrastructures simply and centrally. This means that administrators always remain flexible for making changes and UCS ensures automatically that the information is passed on to all the relevant systems.