Hello all,
we want to ensure that all entries added to the member and manager attributes are valid DNs and point to existing objects in our LDAP. We had the refint overlay do this on version 2.2 but as it seems 2.3 removed this undocumented feature. We lately moved to 2.5 and have issues with faulty entries.
When I tried to configure the overlay with:
olcConstraintAttribute: member uri ldap:///dc=example,dc=com?dn?sub?(objectClass=*)
or
olcConstraintAttribute: member uri ldap:///dc=example,dc=com??sub?(objectClass=*)
or both URIs with an actual objectClass specified, my slapd (2.5.19) crashes on the URI verification step as it seems.
Is my usage of the overlay itself correct (including the URI) or is there a better way to ensure the existence of an referenced object?
Thanks a lot!
Best, Adrian
Hi all,
to answer / correct my own mail. I had an off-by-one with the versions I think. 2.2 did not have the refint overlay, at least not in code, so we might moved from 2.3 to 2.5 but I can't remember. It still stands that at some time refint lost the feature that it ensured validity of add/modify operations of references to other objects.
In the meanwhile I found: https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/m... where Michael Ströder pointed out that the attribute has to be entryDN. with
olcConstraintAttribute: member uri ldap:///dc=example,dc=com?entryDN?sub?(objectClass=*)
everything works now. I have no clue why slapd segfaults with a wrong attribute specified in the olcConstraintAttribute URI but it now works.
Best, Adrian
On 2025-04-11 21:51, Adrian Nöthlich wrote:
Hello all,
we want to ensure that all entries added to the member and manager attributes are valid DNs and point to existing objects in our LDAP. We had the refint overlay do this on version 2.2 but as it seems 2.3 removed this undocumented feature. We lately moved to 2.5 and have issues with faulty entries.
When I tried to configure the overlay with:
olcConstraintAttribute: member uri ldap:///dc=example,dc=com?dn?sub?(objectClass=*)
or
olcConstraintAttribute: member uri ldap:///dc=example,dc=com??sub?(objectClass=*)
or both URIs with an actual objectClass specified, my slapd (2.5.19) crashes on the URI verification step as it seems.
Is my usage of the overlay itself correct (including the URI) or is there a better way to ensure the existence of an referenced object?
Thanks a lot!
Best, Adrian
On Sun, Apr 13, 2025 at 09:33:18AM +0200, Adrian Nöthlich wrote:
Hi all,
to answer / correct my own mail. I had an off-by-one with the versions I think. 2.2 did not have the refint overlay, at least not in code, so we might moved from 2.3 to 2.5 but I can't remember. It still stands that at some time refint lost the feature that it ensured validity of add/modify operations of references to other objects.
In the meanwhile I found: https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/m... where Michael Ströder pointed out that the attribute has to be entryDN. with
olcConstraintAttribute: member uri ldap:///dc=example,dc=com?entryDN?sub?(objectClass=*)
everything works now. I have no clue why slapd segfaults with a wrong attribute specified in the olcConstraintAttribute URI but it now works.
Hi Adrian, great that you found a solution already. It looks like your crash is related to ITS#10204[0] fixed in 2.6.8. If you've just upgraded to 2.5, I suggest you go all the way to 2.6 which is now the LTS release stream, while 2.5 is in the 2-year sunset phase already.
[0]. https://bugs.openldap.org/show_bug.cgi?id=10204
Regards,
openldap-technical@openldap.org