Michael Ströder wrote: > > Consider the following config for slapo-constraint in slapd.conf: > > constraint_attribute ou uri > ldap:///o=Test Company?ou?sub?(objectClass=organizationalUnit) > > With this example the constrained attribute is the same like the one > used in the LDAP URL. Now how are entries handled which are search > results of the LDAP URL? In this example how to deal with new values of > attribute 'ou' in case of adding a new entry with object class > 'organizationalUnit'? I would expect the source data for the constraint to reside in a separate DIT, outside the constraint overlay's control.

Michael Ströder wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Consider the following config for slapo-constraint in slapd.conf: >>> >>> constraint_attribute ou uri >>> ldap:///o=Test Company?ou?sub?(objectClass=organizationalUnit) >>> >>> With this example the constrained attribute is the same like the one >>> used in the LDAP URL. Now how are entries handled which are search >>> results of the LDAP URL? In this example how to deal with new values of >>> attribute 'ou' in case of adding a new entry with object class >>> 'organizationalUnit'? >> I would expect the source data for the constraint to reside in a >> separate DIT, outside the constraint overlay's control. > > IMO this would be a rather awkward requirement. IMO this would be a rather awkward configuration in the first place. Store the source data in some other attribute...

Let me restate: If "reside in a separate DIT" means a separate database this would be an awkward requirement. I'd rather like to see another parameter which controls for which entries the constraints are enforced applicable within the same database. Similar to parameters unique_uri and/or unique_base of slapo-unique.