UCS: Add custom parameters to LDAP directory

UCS - Univention Corporate Server
, , , ,
#1

Hi there,

I am about to install Nextcloud on the UCS without using the docker image available in the UCS App Store. Nevertheless, I took the LDAP setup from the Nextcloud docker image as a basis. It appears that three additional parameters are available in the UCS LDAP directory as soon as the Nextcloud docker image is installed: nextcloudUser, nextcloudGroup and nextcloudQuota.

However, when installing Nextcloud “free style”, these parameters are not longer available in the LDAP directory. Could anybody give me a hint as how to manually add parameters to the UCS LDAP directory so that I can setup LDAP in Nextcloud in a similar way?

Thank you very much!

Best regards,
Peter

UCS Nextcloud Docker Container: Configure fulltextsearch:live
#2

Hey,

Univention provides an easy way to extend the LDAP with custom attributes by providing a range of pre-defined attributes (e.g. univentionFreeAttribute1) via a schema extension. The documentation shows how to configure and use them in the UMC. That way you can configure your user management close to how it would look & feel if you had the Nextcloud app installed.

m.

#3

Dear Moritz,

Thank you very much for your hint. I was able to add the required custom attributes in my latest UCS 4.4-1 environment. The attributes now show up in the LDAP user and group settings. However, when populating one of these fields, I receive the following error message:

Benachrichtigung

Das LDAP-Objekt konnte nicht gespeichert werden: LDAP-Fehler Undefined attribute type: nextcloudEnabled: attribute type undefined

I noticed that I needed to add the nextcloud.schema file from the Nextcloud docker image to the following location:

/var/lib/univention-ldap/local-schema/

Furthermore, I needed to re-run the LDAP configuration to take effect of the changes:

/usr/sbin/univention-config-registry commit /etc/ldap/slapd.conf
/etc/init.d/slapd crestart

Best regards,
Peter

#4

You cannot simply invent LDAP attribute names. The LDAP server is configured via LDAP schemas which object classes and which attributes it recognizes. If you do not use the UCS Nextcloud app, there will be no LDAP schema containing an attribute called nextcloudEnabled. Therefore you cannot use it. This isn’t a bug as you aren’t using the Nextcloud app.

What you can use is an attribute called univentionFreeAttribute1 (up to 20) because Univention recognized the need for custom attributes, and as it’s pretty hard to create valid LDAP schemas Univention provides one containing the attributes univentionFreeAttribute1…20 for you to use in whatever fashion you see fit.

The name of the attribute doesn’t have anything to do with the name used in the UMC or the udm command-line tool, though — meaning you can configure the custom attribute to store its value in the LDAP attribute univentionFreeAttribute1 while mapping that to the name nextcloudEnabled in the UDM.

And that’s exactly what you should do.

In Nextcloud’s configuration you’re dealing directly with LDAP attribute names as Nextcloud knows nothing about UDM, meaning you’ll have to use univentionFreeAttribute1 in Nextcloud’s LDAP user filter queries.

#5

Dear Moritz,

Thank you very much for pointing out that additional LDAP attributes cannot be simply added. I got this point. Therefore, I added nextcloud.schema from the Nextcloud docker image to /var/lib/univention-ldap/local-schema/

After updating the LDAP configuration with /usr/sbin/univention-config-registry commit /etc/ldap/slapd.conf and restarting slapd, I was able to access the LDAP attribute nextcloudEnabled in various LDAP users and the error was gone.

Is this a recommended setup?

Best regards,
Peter

#6

Hey,

providing your own LDAP schema is certainly a possibility. However, simply copying it to that directory is not the best way to go about it as it won’t be replicated to the other LDAP servers running on your UCS servers (DC Backups & DC Slaves). Please read the admin docs and the developer docs about packaging LDAP schema extensions for more information. The developer docs are more comprehensive as they explain how LDAP schema information is stored in the LDAP server itself and distributed to the other servers via the Directory Notifier/Listener mechanism.

Mastodon