The central management of a heterogeneous network has always been UCS’ strength. This was our goal from the beginning to provide a platform that bridges the Linux/Windows worlds. But how does the synchronization between UCS and Microsoft Windows actually work? The problem is that Windows doesn’t speak the same language as UCS. They don’t support the standard-compliant LDAP protocol that allows the communication between the server and clients in UCS. Microsoft has chosen a different approach for its Active Directory.
Let me explain you today which exact technologies we introduced in Univention Corporate Server to provide a solution to this problem. Among other things, I give you details about the replication process via listener/notifier for OpenLDAP, DRS replication for the Active Directory and the Univention S4 Connector, which synchronizes between Microsoft Windows and Linux.
Managing Linx/Windows systems centrally
To allow the uncomplicated operation of Windows systems in a UCS domain, UCS offers Active Directory-compatible domain services via the Samba software suite. With this setup you can replace the Microsoft Windows domain controller.
Setup of two parallel directory services
In order to be able to serve both the Linux clients, servers and their applications as well as the ones from Windows equally, we set up a second AD-compatible directory service on a UCS system in addition to the default OpenLDAP directory service. This AD-compatible Samba directory service also occupies the standard ports for LDAP 389 and 636, because the Windows systems there expect a directory service, 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 automatic case on UCS and UCC systems.
Automatic synchronization
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 synchronization 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.
Hierarchical and multi-master replication in work
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 also with Samba AD domain controllers, is a so-called multi-master replication. Meaning each domain controller can replicate from and with every other domain controller. This is where the Directory Replication Service (DRS) comes into place.
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. It is, for example, not possible to perform selective replication simply as mentioned in a 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”.
Automatic replication and synchronization in both directions
We also have hierarchical replication via listener/notifier for OpenLDAP, multi-master replication via DRS for Active Directory and the “Univention S4 Connector”, which synchronizes 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 synchronizes 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 his 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 synchronizes 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.
Summary
By all these mechanisms transmitting rapidly changes from one directory service to the other directory service and its replicas, UCS can manage even large, heterogeneous IT infrastructures simply and centrally. Thus administrators always remain flexible while UCS ensures automatically that all information is passed on to every systems involved.
I hope I was able to give you a good insight into how UCS synchronizes between AD and OpenLDAP via Samba 4. If you have any further questions, comment below, contact us or visit the Univention forum.
Related articles we recommend:
Fail-safe performance and load distribution thanks to LDAP replication
Central Domain Management with Samba and Active Directory