On 2010-10-07, at 9:03 PM, Howard Chu wrote: > Owen Jacobson wrote: >> Hi there, >> >> I'm trying to enforce that the 'uid' attribute is globally unique in my >> tree using the unique overlay. For a collection of mostly-uninteresting >> reasons,
>> the LDAP server is publicly connectable but not publicly searchable (details >> below). It appears that the unique overlay uses the *worst possible* >> combination of credentials to perform the searches it uses to guarantee >> uniqueness. > >> >> All of the following information was obtained from ldapsearch -Y EXTERNAL >> -H ldapi:/// -b cn=config -- it's really what slapd thinks it's seeing. >> >> As you can see, (a) the IP address the search "comes from" is not the IP >> address of the LDAP server nor is it the LDAP server's ldapi:// socket (it's >> actually my client machine's IP address) and (b) the authenticated DN used in >> the search is empty. Combined, these two facts lead to slapd deciding the >> search is not permitted by the ACL, which in turn causes the unique overlay >> to >> decide no other entries with the same uid exist. This seems wrong: the >> connection from that IP and port has already authenticated as a user (which >> would've permitted the search). >> >> Assuming for the moment that allowing the world at large to search my LDAP >> server is not an option, how can I allow the unique overlay to enforce my >> constraint? >> > Re-read the slapo-unique(5) manpage. Specifically the 3rd paragraph. Thanks. I originally read the man page on my Mac, which is missing the relevant paragraph. (It's present on the Ubuntu version of the same man page.) In the future, you may want to include the paragraph, just in case. In case anyone else has the same problem: > The search is performed using the rootdn of the database, to avoid issues > with ACLs preventing the overlay from seeing all of the relevant data. As > such, the database must have a rootdn configured. Cheers, -o
