The Nextcloud app has been available for installation from the Univention Appcenter for almost four years. It is a very effective way of making a functioning integration of the popular “File Sync and Share” solution into the management system of the Univention Corporate Server within a very short time. This is suitable for making the services of the Nextcloud hub available to a manageable number of users. On occasion, even to a larger circle of several hundred or thousand users.
However, the Docker-based integration has a few disadvantages due to its architecture, for which a Nextcloud installation on a different platform would be worth considering.
A first point is the space limitation in the use of a local hard disk: The Docker instance only has access to the overlay mounts of the host machine provided by the integration. Therefore, it cannot use additional local hard disks without further effort. There are similar challenges when integrating NFS or S3-based network storage. With the increased use of Nextcloud service it would still be worth considering being able to scale horizontally to multiple peer Nextcloud instances. This would require significant subsequent changes to the system setup. Also, a separation of the database, which relies on the Appcenter integration PostgreSQL, or use of a highly available database cluster, e. g. based on Galera, is not supported by the integration innately.
In general, it is also conceivable to install the file-sharing platform on UCS natively. However, the dependency of Nextcloud towards very new PHP versions does not make such an undertaking easy and not very recommendable considering the higher operating costs, feared in the long term.
Luckily, the above arguments are no exclusion criteria for the operation of a highly scalable Nextcloud platform together with the identity management system provided by UCS. In the following, I would like to explain the steps and further considerations that are necessary or reasonable for manual integration. It is irrelevant on which platform Nextcloud is installed, as well as which database backend or web server is in use. Therefore, I will not go into the initial setup of Nextcloud itself.
First, another app…
Firstly, Nextcloud must be configured so that the users and groups defined in UCS are also available in Nextcloud. Since the UCS stores this information in a directory based on OpenLDAP, it is obvious to use the “LDAP application“. This method is also used by the Nextcloud integration from the Appcenter, but for automating reasons, the configuration using the “occ” command-line tool. If not already available, the Nextcloud app “LDAP user and group backend” must be installed and activated.
The documentation above mentions some elementary configuration options for the LDAP connection. First, the DNS name or IP address of the LDAP server is needed. One might be tempted to enter the first
domain controller of a UCS domain (“DC Master” or “Primary Directory Node”). This will certainly work, but is rather questionable, at least if a very large group of users (several thousand) are supposed to use the service. Although Nextcloud tries to cache received LDAP information, it will generate enough requests on a busy Nextcloud server to cause a good basic load on the LDAP server. It is a good idea to select another existing domain controller here.
Integration with TLS ports and certificates
Another point is the selecting the target port on the LDAP server and, directly related to this, the TLS-secured transmission of user information from the directory. Again, the LDAP standard port 389, which Nextcloud also wants to use initially, is not the best choice. This port is only served by OpenLDAP on systems in which no “Active Directory-capable domain controller” is running. In such a constellation, the self-discovery mechanisms of Nextcloud would probably detect a Windows server. This can also work, but somewhat limits the configuration options that are mentioned later. The alternative port 7389 which is always used by OpenLDAP on every domain controller, is better suited for this purpose.
However, ports 389 and 7389 are the ones where “plain text” is spoken. Protection is only optional there via “StartTLS”. In this case, the connection security is only put into operation after the initial establishment of a plaintext connection. This may seem sufficient, but it offers no transparency as to whether the connection is TLS-secured or not. Only those who explicitly use the TLS ports are on the safe side in this sense. In the case of LDAP, this would be port 636 and – under UCS – 7636. In summary, one would want to enter ” ldaps://directorynode.example.com in the Server field and “7636” in the Port field.
To make this work, the LDAP configuration of the Nextcloud server must be familiarised with the certificate of the UCS. UCS systems do this automatically during the domain join. More precisely in the file /etc/ldap/ldap.conf, you can see that the path to a certificate is stored in the configuration “TLS_CACERT”. This certificate is that of the
UCS root CA and is linked in the Univention Management Console, among other things. The simplest way to get it is to use
wget https://primarydirectorynode.example.com/ucs-root-ca.crtand save it, for example, under /etc/ssl/certs. After adjusting the above-mentioned configuration in ldap.conf, there should be a good chance that an LDAPS connection will work.
Integrate users with LDAP connection
For an application to identify users, an LDAP connection is initially established in most cases. Meanwhile, for security reasons, it is rather unusual to make an LDAP directory accessible to anonymous readers. This is also the case under UCS. Applications which insist on a so-called “anonymous bind” could be enabled by specifying the source IP address with the UCR variable “ldap/acl/read/ips”. Details can be found in the UCS manual at https://docs.software-univention.de/manual-4.4.html#domain-ldap:acls. However, this is not necessary for Nextcloud. Here, a “bind DN”, which is an account that can search the LDAP directory, can be specified.
If you search the internet for example configurations for LDAP with Nextcloud, you will sometimes find a “uid=admin,…” at this position. This is rather questionable, as one must assume that somewhere in the configuration the password of a presumably very highly privileged user account is present in plain text and is regularly sent through the network in the case of an unsecured connection. The current “LDAP application” from Nextcloud does not require any write permissions in the LDAP directory itself. Therefore, it is a good idea to use a separate, low-privileged service account. Its setup under UCS is described in detail in https://help.univention.com/t/cool-solution-ldap-search-user-simple-authentication account/11818. There you will also find how to test the account and the password with (hopefully) sufficient entropy in advance. This will also tell you what the “Distinguished Name” of the service account (e. g. uid=ldapsearch-nextcloud,cn=users,dc=example,dc=com) to be entered in the “User DN” field and the LDAP base for the “Base DN” field (e.g. dc=example,dc=com) is.
The agony of choice
The next step in the configuration is to specify a suitable (LDAP) filter for choosing the user accounts that are allowed to use Nextcloud. The Nextcloud app from the Univention App center uses an extension of the LDAP directory to store and use additional information for example the user authorization and quota information. In compliance with the license conditions and with the instructions from https://docs.software-univention.de/developer-reference-4.4.html#settings:ldapschema, it would be possible to configure the extension of the scheme from https://github.com/nextcloud/univention-app/blob/master/nextcloud.schema manually.
For this extension to be accessible in the management console or on the command line, “extended attributes” must be defined. The latest link also shows the possibility of getting by without an extension of the LDAP schema: the object class “univentionFreeAttributes“.
If this is too complex or the requirements for a granular filter simply do not exist, an LDAP filter can also be modeled based on existing attributes and mappings. Object classes often serve as the first criteria, starting with “inetOrgperson” (https://tools.ietf.org/html/rfc2798). When using UCS@School version 4.x, one could further restrict the group of persons with the object classes “ucsschoolStudent”, “ucsschoolTeacher” and “ucsschoolStaff”. Another common selection method is the use of group memberships.
The Nextcloud documentation mentions that “member-of-overlay” must be activated in the LDAP server for this to work. Under UCS, this is the case for all installations since version 4.3.0 (https://help.univention.com/t/memberof-attribute-group-memberships-of-user-and-computer-objects/6439). This would make the LDAP filter “(&(objectClass=inetOrgPerson (memberOf=cn=nextcloudusers,ou=groups,dc=example,dc=com))” specified in the Nextcloud manual almost suitable.
Under UCS, however, the default groups are in “cn=groups”. When searching for a suitable LDAP filter, the button “Check settings and count users” is very helpful. When adjusting the filter afterward, it is recommended to use a local Nextcloud user just like during the initial setup, i. e. not an administration account defined via LDAP. Otherwise, you could very easily lock yourself out in the event of a configuration error, since all changes are saved immediately.
Under the tab “Logon Attributes” it is useful to allow logon using the “LDAP/AD e-mail address” in addition to the preselected “LDAP/AD user name”. This results in a change of the LDAP filter which allows the use of the attribute “mailPrimaryAddress”. It holds the main SMTP address of the account in case of a mail integration under UCS, as well as an optional mail address that can be defined under the contact information for logging in to Nextcloud. From the user’s point of view, this may be more understandable than a “username”.
Synchronizing the groups with the central LDAP directory can be helpful to simplify the administration of rights to Nextcloud apps or shares. As with the filter for users, it is only a matter of selecting suitable object classes and optionally certain groups for synchronization.
And now enter the LDAP user name…
The configuration steps that have been carried out so far should already have led to a functioning LDAP connection. However, depending on your point of view, this has a small flaw that you may want to correct right at the start. But you do not necessarily have to. In the expert settings of the LDAP configuration, you will find the hint that Nextcloud uses the “UUID” attribute as an internal user name by default. OpenLDAP uses the entryUUID attribute to define a universally unique identifier. However, the uniqueness makes it a little harder to assign an LDAP account to an entry like “597ae2f6-16a6-1027-98f4-d28b5365dc14” at first glance.
Alternatively, you can enter “uid”, i. e. the LDAP user name as the internal name in Nextcloud. Although, you must then consider how name changes are handled in general.
Backup host for redundancy and high availability
A UCS environment that is redundant in terms of availability will always provide several domain controllers (directory nodes) with a complete copy of the LDAP data stock. This of course also makes it possible to connect LDAP-based services in a highly accessible way. Nextcloud also has such a possibility. A backup host entered under the tab “Advanced” uses the configuration that was entered for the main server and can take over its task in the event of an error. Information on how this works can be found at Nextcloud Docs Handling with backup server. It is noteworthy that no real load distribution of the LDAP connections can be achieved with Nextcloud built-in methods. If necessary, a suitable load balancer should be used.
For a successful long-term operation of Nextcloud with a central LDAP, you should also deal with the question of what happens to accounts in Nextcloud if their counterpart in the LDAP is deleted. Within the Nextcloud Docs you will find information on how to deal with remnants.