After a Veeam restore the slapd does not start

We made several attempts to restore a directory backup server VM utilizing Veeam using backups from different Days. After the server start slapd is not up.

systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
Loaded: loaded (/etc/init.d/slapd; generated)
Active: failed (Result: exit-code) since Tue 2023-04-25 12:05:05 UTC; 44min ago
Docs: man:systemd-sysv-generator(8)
Process: 27356 ExecStart=/etc/init.d/slapd start (code=exited, status=1/FAILURE)

Apr 25 12:05:05 ucs slapd[27368]: DIGEST-MD5 common mech free
Apr 25 12:05:05 ucs slapd[27368]: DIGEST-MD5 common mech free
Apr 25 12:05:05 ucs slapd[27368]: slapd stopped.
Apr 25 12:05:05 ucs slapd[27368]: connections_destroy: nothing to destroy.
Apr 25 12:05:05 ucs slapd[27356]: Starting ldap server(s): slapd ...failed.
Apr 25 12:05:05 ucs slapschema[27371]: Loaded metadata from "/usr/share/univention-management-console/saml/idp/[](
Apr 25 12:05:05 ucs slapd[27356]: 6447c1f1 /etc/ldap/slapd.conf: line 213: unknown attr "clientsecret" in to clause 6447c1f1 <access clause
Apr 25 12:05:05 ucs systemd[1]: slapd.service: Control process exited, code=exited, status=1/FAILURE
Apr 25 12:05:05 ucs systemd[1]: slapd.service: Failed with result 'exit-code'.
Apr 25 12:05:05 ucs systemd[1]: Failed to start LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol).

We are grateful for any useful hint.

did you install or remove some additional apps/integrations in between?
The slapd.conf refers to some attribute named clientsecret which is not defined by a schema.
There might be a chance to find the cause looking at the templates and see if there is a remnant or incomplete configuration.

grep clientsecret /etc/univention/templates/files/etc/ldap/slapd.conf.d/*


Hello Dirk,
thank you for taking care.
We performed

grep clientsecret /etc/univention/templates/files/etc/ldap/slapd.conf.d/*
/etc/univention/templates/files/etc/ldap/slapd.conf.d/58openid-connect-provider.ldapacl:access to filter="objectClass=univentionOIDCService" attrs=clientsecret

We had to perform the UCS updates. In the first attempt we had to realise we need the connector. However, the VM restore should set back the former state but since then the SLAP demon does not start.
Interestingly, a parallel freshly set up machine (we wanted to find out if anything outside is influencing the situation) can sync and does not show any result of the grep above.

I dont have a reference system with OIDC installed. So I can only lookup what should happen…
The inst script ( create a schema-file (/usr/share/univention-openid-connect-provider/openid-connect-provider.schema) which is installed later using ucs_registerLDAPExtension. Interestingly the ACL is installed at the same time.
Further steps depend if the LDAP has attributes defined by the schema. I guess that this is the case and would opt to re-install the schema. Running ucs_registerLDAPExtension from the script (and of course using the files referenced there) should work from my point of view.


Hi Dirk, thanks for your reply!
We don’t need the OpenID connect provider. It was installed before, but removed weeks ago, because we don’t use it. After removing the reference in slapd.conf to the mentioned attributes (clientsecret), the daemon started and I was able to log in with my LDAP credentials.
Then I ran the rejoin script and all packages joined successfully, except 65univention-ox. The error message in the join log “module ‘univention.admin.syntax’ has no attribute ‘oxFetchmailProtocol’” and a Google search led me to a bug report related to an older version of UCS: Bug 41090 – AttributeError: 'module' object has no attribute 'oxFetchmailProtocol'
If there is a fix for this issue, please let us know - we’re running the latest UCS 5 release with recent updates.

There is an article Problem: The joinscript 65univention-ox.inst failes with Failed to register LDAP module dealing with the oxFetchmailProtocol-Issue.