On Fri, Sep 11, 2015 at 05:26:35PM +0000, Peter Heinemann wrote:

Working with an ldap implementation that builds the dit from scratch daily using extracts from an RDBMS. The nature of the source data/tables and the code that creates the extracts builds an ldif (imported via slapadd) that has some multi-value attributes, specifically cn, sn, and givenName because the RDBMS does no case checking.

Stanzas like this can occur in the ldif:

dn: uid=aperson,ou=people,dc=school,dc=edu

cn: Andrew Person cn: ANDREW PERSON sn: Person sn: PERSON givenName: Andrew givenName: ANDREW

and slapadd will happily write them all, but ldapmodify etc. can (and do) return errors when encountering these entries.

You should only use slapadd with correctly-formed LDAP entries. The example given here is not correctly formed because all the attributes you show have case-ignore syntax and the multiple values differ only in case.

What I'd like to do is use ldapadd under the uniqueness overlay instead of slapadd. But I'm unsure of the specific syntax for the unique_uri specification so that that cn, sn, and givenName attributes are unique under/in each DN. Most of the examples I've found are how to enforce uniqueness over an entire branch. Still reading the specifics about uri specification but would appreciate any assistance.

The uniqueness overlay will not do what you want. It is for enforcing uniqueness across multiple entries. If you use ldapadd rather than slapadd then you will not be able to load bad entries such as the one above. However, this is probably still not what you want as it will throw an error rather than removing the unnecessary extra values!

I think the best approach would be for your build process to check each attribute before writing the LDIF file. Where:

lowercase(next value) matches lowercase(any existing value)

then it should either ignore the new value or should overwrite the clashing value in the attribute (e.g. if the new one is mixed case and the existing one is all upper case).

It would still be wise to load the data through LDAP rather than using slapadd, but the process will be much slower.

How many entries do you have? Do you run multiple LDAP servers?

Andrew