Hide Forgot
+++ This bug was initially created as a clone of Bug #951754 +++ Description of problem: I've two records in 389ds with the same uid value. For example: dn: uid=user1,ou=unix_users,dc=localdomain uid: user1 cn: user1 name objectclass: top objectclass: person dn: cn=user1 name,ou=people,dc=localdomain uid: thang cn: user1 name objectclass: top objectclass: person I added "dn: uid=user1,ou=unix_user,dc=localdomain" first and then added "dn: cn=test user1,ou=people,dc=localdomain" (the order is important). I've an ACI to allow read, compare and search from ldap:///self: aci: (targetattr="*")(version 3.0; acl "Allow self entry access"; allow (read,search,compare) userdn = "ldap:///self";) When I do a ldapsearch as following: ldapsearch -D 'cn=user1 name,ou=people,dc=localdomain' -w password -b 'ou=people,dc=localdomain' 'uid=user1' The ldapsearch doesn't return anything. The error log shows: 12/Apr/2013:12:21:12 -1000] NSACLPlugin - acl_init_userGroup: found in cache for dn:cn=user1 name,ou=people,dc=localdomain [12/Apr/2013:12:21:12 -1000] NSACLPlugin - Failed to find root for base: dc=edu [12/Apr/2013:12:21:12 -1000] NSACLPlugin - #### conn=46 op=3 binddn="cn=user1 name,ou=people,dc=localdomain" [12/Apr/2013:12:21:12 -1000] NSACLPlugin - Searching AVL tree for update:uid=user1,ou=unix_users,dc=localdomain: container:-1 [12/Apr/2013:12:21:12 -1000] NSACLPlugin - Searching AVL tree for update:ou=unix_users,dc=localdomain: container:-1 [12/Apr/2013:12:21:12 -1000] NSACLPlugin - ************ RESOURCE INFO STARTS ********* [12/Apr/2013:12:21:12 -1000] NSACLPlugin - Client DN: cn=user1 name,ou=people,dc=localdomain [12/Apr/2013:12:21:12 -1000] NSACLPlugin - resource type:768(search target_DN target_attr ) [12/Apr/2013:12:21:12 -1000] NSACLPlugin - Slapi_Entry DN: uid=user1,ou=unix_users,dc=localdomain [12/Apr/2013:12:21:12 -1000] NSACLPlugin - ATTR: uid [12/Apr/2013:12:21:12 -1000] NSACLPlugin - rights:search [12/Apr/2013:12:21:12 -1000] NSACLPlugin - ************ RESOURCE INFO ENDS ********* [12/Apr/2013:12:21:12 -1000] NSACLPlugin - conn=46 op=3 (main): Deny search on entry(uid=user1,ou=unix_users,dc=localdomain).attr(uid) to cn=user1 name,ou=people,dc=localdomain: no aci matched the subject by aci(182): aciname= "Allow self entry access", acidn="dc=localdomain" The interesting thing is that the client DN is "cn=user1 name,ou=people,dc=localdomain" and the Slapi_Entry DN is "uid=user1,ou=unix_users,dc=localdomain. However I get the "uid=user1,ou=unix_users,dc=localdomain" record when I do ldapsearch -D 'uid=user1,ou=unix_users,dc=localdomain' -w password -b 'ou=unix_users,dc=localdomain' 'uid=user1' I'm thinking the "uid=user1" is cached under "uid=user1,ou=unix_users,dc=localdomain" and not under "cn=user1 name,ou=people,dc=localdomain". After I deleted "uid=user1,ou=unix_users,dc=localdomain", I'm able to do a self search with ldapsearch -D 'cn=user1 name,ou=people,dc=localdomain' -w password -b 'ou=people,dc=localdomain' 'uid=user1' After I added back "uid=user1,ou=unix_users,dc=localdomain", I was able to do a self search ldapsearch -D 'cn=user1 name,ou=people,dc=localdomain' -w password -b 'ou=people,dc=localdomain' 'uid=user1' but NOT ldapsearch -D 'uid=user1,ou=unix_users,dc=localdomain' -w password -b 'ou=people,dc=localdomain' 'uid=user1' So I think whatever attributes were added first, it will be cached under that dn. Can you please check if this is a bug and any fix or workaround? thanks. Regards, --thang --- Additional comment from Nathan Kinder on 2013-04-13 00:37:50 EDT --- In your example, you are searching for "uid=user1" under "ou=people,dc=localdomain", but no such entry exists. The entry beneath "ou=people,dc=localdomain" has "uid=thang", so your search filter will never match that entry. The ACI debugging shows that you are properly denied "search" access to "uid=user1,ou=unix_users,dc=localdomain" since you are bound as a different user. --- Additional comment from Thang Nguyen on 2013-04-13 01:52:50 EDT --- Hi Nathan, Sorry... I had a typo. The uid on both record has the same value, "uid=user1". You can reproduce by creating two records in separate OU with the same value for "uid". Then create the aci aci: (targetattr="*")(version 3.0; acl "Allow self entry access"; allow (read,search,compare) userdn = "ldap:///self";) Then you can do a self search for the "uid=<value>" from both DNs you just added. When you bind as the first DN you added, you will get a back the record. If you bind as the second DN you added, you will not get back anything. Thanks for looking into this. Regards, --thang --- Additional comment from Nathan Kinder on 2013-04-16 11:57:09 EDT --- Upstream ticket: https://fedorahosted.org/389/ticket/47331 --- Additional comment from Thang Nguyen on 2013-09-13 15:24:42 EDT --- Hi Nathan, Is it possible that you put this fix in the 389-ds-base package on Red Hat Enterprise Linux 6? --- Additional comment from Nathan Kinder on 2013-09-13 15:48:28 EDT --- (In reply to Thang Nguyen from comment #4) > Hi Nathan, > > Is it possible that you put this fix in the 389-ds-base package on Red Hat > Enterprise Linux 6? This is not currently targeted for inclusion in RHEL6. We can certainly consider it for a future RHEL 6 update.
Quality Engineering Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Reopening, as this is a bug that engineering wants to get in for RHEL 6.6. Was the qe_ack- flag set by accident for this?
$ ldapadd -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1389 << EOF > dn: cn=test1,dc=example,dc=com > objectClass: inetorgperson > objectClass: organizationalPerson > objectClass: person > objectClass: top > uid: test > sn: test1 > cn: test1 > userPassword: Secret12 > > dn: cn=test2,dc=example,dc=com > objectClass: inetorgperson > objectClass: organizationalPerson > objectClass: person > objectClass: top > uid: test > sn: test2 > cn: test2 > userPassword: Secret12 > EOF adding new entry "cn=test1,dc=example,dc=com" adding new entry "cn=test2,dc=example,dc=com" $ ldapmodify -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1389 << EOF > dn: dc=example,dc=com > changetype: modify > delete: aci > EOF modifying entry "dc=example,dc=com" $ ldapmodify -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1389 << EOF > dn: dc=example,dc=com > changetype: modify > add: aci > aci: (targetattr="*")(version 3.0; acl "Allow self entry access"; allow (read,search,compare) userdn = "ldap:///self";) > EOF modifying entry "dc=example,dc=com" $ ldapsearch -LLL -D 'cn=test1,dc=example,dc=com' -w Secret12 -b 'dc=example,dc=com' 'uid=test' -H ldap://localhost:1389 dn: cn=test1,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson uid: test sn: test1 cn: test1 userPassword:: e1NTSEF9QWpjMnh3NHRPZmd5MVBpRDZjUWtyaFgvdjFGY2ZrbU41d1N3V1E9PQ= = $ ldapsearch -LLL -D 'cn=test2,dc=example,dc=com' -w Secret12 -b 'dc=example,dc=com' 'uid=test' -H ldap://localhost:1389 dn: cn=test2,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson uid: test sn: test2 cn: test2 userPassword:: e1NTSEF9YXNscG9DMEtvZGozcmRKSnp2emNrYVFhVHFIdEhKMDM1VWgvckE9PQ= = $ rpm -qa | grep 389 389-ds-base-debuginfo-1.2.11.15-36.el6.x86_64 389-ds-base-libs-1.2.11.15-36.el6.x86_64 389-ds-base-1.2.11.15-36.el6.x86_64
Without the fix, the test case described above should have return: ldapsearch -LLL -D 'cn=test1,dc=example,dc=com'... dn: cn=test1,dc=example,dc=com ... dn: cn=test2,dc=example,dc=com ... And bound with cn=test2: ldapsearch -LLL -D 'cn=test2,dc=example,dc=com'... <nothing>
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1385.html