In February 2019, the Univention Directory Notifier received a new protocol version that makes replication of directory service contents within the UCS domain more secure. To achieve this, some modifications had to be made under the hood.

Univention Directory Notifier – What’s that anyway?

Within a UCS domain, information stored in the OpenLDAP directory service is replicated from the UCS master (or from UCS backups) to other UCS systems. The underlying concept has already been discussed on our blog in the articles UCS: How to set up LDAP Replication and Fail-safe performance and load distribution thanks to LDAP replication.

To be precise, the replication takes place by means of the so-called listener/notifier mechanism: The Univention Directory Listener (UDL) system service runs on all UCS systems that can join a UCS domain UCS systems. Additionally, the system service “Univention Directory Notifier” (UDN) runs on the UCS Master and the UCS backups. UDL then continuously queries a UDN for new transactions in the directory service, e.g. the password change of a user, in order to then transfer these to the local system:

The Replication Process

Previously (protocol version 2), the replication proceeded as follows:

  1. UDL establishes a connection to the UDN ( if it has not already done so).
  2. The UDL queries the number of the last transaction.
  3. The UDL waits for the next transaction and blocks for this time.
  4. As soon as the respective transaction has happened, the UDN sends – up to now unencrypted – the Distinguished Name (DN) of the entry that has been changed through the connection.
  5. UDL then establishes an encrypted connection to the LDAP server, authenticates itself with the machine account and retrieves the complete entry.

The problem arises in point 4 and the unencrypted connection. Although this does not allow highly sensitive information such as password hashes to be retrieved, the Distinguished Name (DN) is transmitted, from which information on user names and e-mail addresses may also be derived.

The new protocol version 3 now does the following differently:

  1. version 3 is negotiated during the connection setup.
  2. The listener now uses a different method to query the transaction. The Notifier no longer supplies it directly with the Distinguished Name (DN), but only with the most recent transaction number, which does not allow any further conclusions about the user.
  3. Instead of asking directly for the DN, the UDL first asks for the LDAP entry reqSession=$TRANSACTIONNUMBER,cn=translog over the encrypted, authenticated LDAP connection. Only this entry then contains in the attribute reqDN the DN of the actual LDAP entry, which is only then queried.

For UDL to be able to keep up to date even after a long downtime, UDN must keep old transactions in stock. Until now, the file /var/lib/univention-ldap/notify/transaction was used for this purpose. As of protocol version 3, the LDAP database cn=translog is additionally used. This is a newly introduced, second database that is independent of the LDAP database, which contains the regular directory service contents such as users and groups. You can find the new translog database at /var/lib/univention-ldap/translog/.

Older systems that are or have been installed with UCS 4.3 still offer the old protocol in version 2. New installations of UCS 4.4 and higher by default only offer version 3. This can be customized as needed with the UCR variable „notifier/protocol/version“.

Further Information
For developers, the Developer Reference has also been revised. Here you can find further details, for example regarding the listener cache, the transfer of information to the listener modules and an index to the transaction file.

Under the category „knowledge base“ at https://help.univention.com we have provided two articles for in-depth analysis and troubleshooting of possible replication issues:

Michael Grandjean

Open Soure Software Consultant and member of the Professional Services Team of Univention.

Philipp Hahn

Open Source Software contributor from Kernel to Python since 1996, Debian Maintainer since 2002 and Member of the Software Engineering Team of Univention since 2009.

What's your opinion? Leave a comment!

Your email address will not be published. Required fields are marked *