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.
My unique configuration:
dn: olcOverlay={0}unique,olcDatabase={1}hdb,cn=config
objectClass: olcUniqueConfig
olcOverlay: {0}unique
olcUniqueURI: ldap:///dc=unreasonent,dc=com?uid?sub?
My database configuration (indexes and hdb configuration elided):
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap/unreasonent.com
olcSuffix: dc=unreasonent,dc=com
olcAccess: {0}to attrs=userPassword
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by group=cn=Directory
Administrator,ou=Roles,dc=internal,dc=unreasonent,dc=com manage
by anonymous auth
by self write
by * none
olcAccess: {1}to attrs=shadowLastChange
by self write
by * break
olcAccess: {2}to dn.base=
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by group=cn=Directory
Administrator,ou=Roles,dc=internal,dc=unreasonent,dc=com manage
by * break
olcAccess: {3}to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by group=cn=Directory
Administrator,ou=Roles,dc=internal,dc=unreasonent,dc=com manage
by users read
by peername.regex=IP=10.27.70.6\:\d+ read
by * none
(The peername.regex ACL entry is shrapnel from my attempts to make this work on
my own, but it came in handy. The IP address there is the IP address of my LDAP
server.)
As you can see anonymous users are allowed to do one thing: authenticate. My
tree contains the following user already:
dn: uid=owen,ou=People,dc=internal,dc=unreasonent,dc=com
When I log in with the user above (who is in the group cn=Directory
Administrator,ou=Roles,dc=internal,dc=unreasonent,dc=com) and add the following
test user
dn: uid=owen,ou=test,ou=People,dc=unreasonent,dc=com
changetype: add
objectClass: inetOrgPerson
uid: owen
sn: Test
cn: Test
the add succeeds (which should not happen, as the UID is already in use). A
little digging with slapd -d -1 reveals that the unique overlay is doing a
search of its own:
== unique_add uid=owen,ou=test,ou=People,dc=unreasonent,dc=com
== unique_search (|(uid=owen))
str2filter (|(uid=owen))
put_filter: (|(uid=owen))
put_filter: OR
put_filter_list (uid=owen)
put_filter: (uid=owen)
put_filter: simple
put_simple_filter: uid=owen
begin get_filter
OR
begin get_filter_list
begin get_filter
EQUALITY
ber_scanf fmt ({mm}) ber:
ber_dump: buf=0xb5dd5438 ptr=0xb5dd543a end=0xb5dd5447 len=13
: a3 0b 04 03 75 69 64 04 04 6f 77 65 6euid..owen
end get_filter 0
end get_filter_list
end get_filter 0
= hdb_search
bdb_dn2entry(dc=unreasonent,dc=com)
= access_allowed: search access to dc=unreasonent,dc=com entry requested
= dn: [3]
= acl_get: [4] attr entry
= acl_mask: access to entry dc=unreasonent,dc=com, attr entry requested
= acl_mask: to all values by , (=0)
= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
= check a_dn_pat: users
= check a_peername_path: IP=10.27.70.6\:\d+
= acl_string_expand: pattern: IP=10.27.70.6\:\d+
= acl_string_expand: expanded: IP=10.27.70.6\:\d+
= regex_matches: string:IP=10.27.70.210:46908
= regex_matches: rc: 1 no matches
= check a_dn_pat: *
= acl_mask: [5] applying none(=0) (stop)
= acl_mask: [5] mask: none(=0)
= slap_access_allowed: search access denied by none(=0)
= access_allowed: no more rules
send_ldap_result: conn=1029 op=33 p=3
send_ldap_result: err=32 matched= text=
= unique_search found 0 records
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?
-o
