Become Part of our Team and Push Digital Sovereignty
- Teamleader IT / Project Manager (m/f/x)
- IT Consultant (m/f/x)
- Outbound Sales Represantative (m/f/x)
Our work environment is becoming more ‘colorful’, but also more difficult to handle and control. Employees increasingly determine for themselves which tools they use and where they work. As an admin, you easily lose track and become afraid of losing control over the security of your corporate IT.
Fortunately, UCS provides an identity and access management (IAM) that centrally manages and supervises all tools, devices, data, and accesses. By setting up a centralized IAM, you not only avoid shadow IT, but most of all, you regain control over your network and your precious data.
For those of you who have little technical knowledge in UCS, I like to explain today the terms LDAP / OpenLDAP, as they are the cornerstones of our central IAM system.
LDAP is the abbreviation for “Lightweight Directory Access Protocol”. This is a protocol which was defined to standardize the access to and maintenance of directory services. It emerged as a simplification of the considerably more comprehensive X.500 standard, and has since managed to establish itself as the de facto standard for the handling of directory services.
OpenLDAP is a reference implementation for this standard and brings with it both a server implementation and a client library for access to LDAP servers. UCS employs both.
An LDAP server implements a database to which queries can be sent via the LDAP protocol. Just like with other databases, the actual information here is stored in a file system. As a “database server”, OpenLDAP ensures the high-performance availability of the data, e.g., through indexing of the contents. Every “object” in the database corresponds to a data set, which stores for example the attributes of a specific user.
To give an example, that would look as follows in the LDAP notation:
dn: uid=steuwer,cn=users,dc=univention,dc=local objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: posixAccount objectClass: top uid: steuwer mail: email@example.com displayName: Ingo Steuwer sn: Steuwer homeDirectory: /home/steuwer givenName: Ingo title: Head of Professional Services o: Univention GmbH
A data set is always composed of attribute value pairs, e.g.:
sn: Steuwer for the surname (surname / sn). In contrast, the LDAP context employs special attributes such as:
objectClass:The “objectClass” attribute defines the type of data set that the object represents. Each of the assigned object classes allows a specific number of attributes. Which attributes these are and what syntax they support depends in turn on schemas, which are notified to the LDAP server.
dn:The “Distinguished Name” (DN) defines the position of the object in the directory service. The directory is built like a tree, as are the majority of file systems. The order in a DN leads from the leaf to the root, in other words the “opposite” of what we are used to in a file path in a file system. In our example, the object is referenced by
uid=steuwer; the path by the elements
cn-users(what is referred to as a container) and
dc=univention,dc=local(the LDAP basis, in other words the “root” of the tree).
Directory services have established themselves for the storing of infrastructure information and, above all, identities. Thanks not least to the widespread use of Active Directory, the storage of comprehensive information concerning users (name, contact details, etc) and the corresponding authentication and authorization data has now become the norm. In this context, a considerable advantage of LDAP compared with SQL databases lies in the fact that users can define the access rules to data in the directory service in considerably more detail.
There are various LDAP clients available for access to the data. In UCS, the corresponding modules in the Management Console are generally used.
However, the following example illustrates a query via the command line tool
The most important parameters are:
dc=univention,dc=local, as such the input is performed based on the basis in the configuration file. However, if the tools are used to access other LDAP servers, the relevant basis there must be specified.
The complete request for the command line tool
ldapsearch is therefore:
ldapsearch -H LDAPS://ucs-master.univention.local \ -x -D "uid=steuwer,cn=users,dc=univention,dc=local" -w "secret"\ (&(objectClass=person)(uid=Administrator))
-H option makes it possible to specify an LDAP URI for definition of the LDAP server to be used. In the specification selected here with
LDAPS, the connection is encrypted via SSL. To this end, it is important that the certificates are named and the server is specified with the fully qualified domain name (FQDN). The parameter
-x selects a simple LDAP bind as an authentication procedure and
-w are used to pass on the user DN and password. The filter then searches for the “Administrator” user account – no prefixed option letter is required for this.
UCS offers the command line tool
univention-ldapsearch on all systems. As such, it is possible for “root” users to access the LDAP with the account of the current UCS system. The tool uses
ldapsearch in the background, but passes the correct values for the LDAP server, LDAP basis and authentication on. As such, specifying the LDAP filter is sufficient for a search:
For further background knowledge about LDAP you find a good introduction on Wikipedia. As a first starting point for the concrete use of OpenLDAP you can refer to the documentation on the OpenLDAP project site.
In addition to the good man pages (“man ldapsearch”) etc. there are also numerous books available. And last but not least, you can always get a profound introduction into the UCS implementation via our documentation.