Univention Bugzilla – Bug 56903
broken syntax of slapd.conf after a config change
Last modified: 2024-02-06 10:35:09 CET
There was a failure of the LDAP server because slapd.conf was created “defective” after a config change. The problem was that there was a line break in the middle of a filter in slapd.conf. The last line of the filter was *just* the closing bracket. The following lines of the filter were all correctly indented with spaces, except the last line with the brackets. # helpdesk access: grant access to specified groups for password reset access to dn.sub="dc=univention,dc=intranet" filter="(&(|(&(objectClass=posixAccount)(objectClass=shadowAccount))(objectClass=univentionMail)(objectClass=sambaSamAccount)(objectClass=simpleSecurityObject)(&(objectClass=person)(objectClass=organizationalPerson)(objectClass=inetOrgPerson)))(!(uidNumber=0))(!(|(uid=Administrator)(uid=B.surname)(uid=… ))" Indenting with spaces is important, but parentheses behave differently: )))“ slapd starts ))“ slapd won't start )“ slapd starts
ldap/server/type: master ldap/acl/user/passwordreset/protected/uid: <empty> ldap/acl/user/passwordreset/protected/gid: Domain Admins ldap/acl/user/passwordreset/internal/groupmemberlist/.*: <empty> ldap/acl/user/passwordreset/internal/groupmemberlist/Domain Admins: Administrator,B.Nachname,D.Nachname,J.Nachname,a.> ldap/acl/user/passwordreset/accesslist/groups/.*: <empty> ldap/acl/user/passwordreset/accesslist/groups/dn: cn=User Password Admins,cn=groups,dc=univention,dc=intranet ldap/acl/user/passwordreset/attributes: krb5Key,userPassword,sambaPwdCanChange,sambaPwdMustChange,sambaLMPassword,sambaNTPassword,sambaPwdLast> ldap/acl/nestedgroups: yes ldap/base: dc=univention,dc=intranet
Clarification from the customer on which config changes were made: The ACL on the helpdesk-group are probably generated when a new user is added to the helpdesk-group. With a certain length of the parameters the template is implemented in the config file with broken syntax.
Looks like the slapd config parser has an issue, specifically with the ! operator: This is triggering the issue: ``` filter="(!(uid=Administrator) )" ``` While all of the following works: Shifting the closing parenthesis, as the customer observed (nice catch!) ``` filter="(!(uid=Administrator ))" ``` works ok and other operators doen't seem to suffer from that issue either: ``` filter="(&(uid=Administrator) )" ```