Hide Forgot
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/47950 I've activated bind dn tracking (nsslapd-plugin-binddn-tracking: on). There is an account that has the write to add the entries and to change some attributes (e.g. description). The corresponding ACI: {{{ dn: ou=Cours,ou=Enseignement,ou=Groupes,dc=id,dc=polytechnique,dc=edu aci: (targetattr = "objectClass || uniqueMember || owner || cn || description || businessCategory" ) (version 3.0;acl "Droits de rejouter/supprimer/modifier les groupes et leurs att ributs";allow (add, delete, read,compare,search,write)(userdn="ldap:///uid=sync-cours,ou=Comptes generiques,ou=Utilisateurs,dc=id,dc=polytechnique,dc=edu");) }}} Any attempt to modify an authorized attribute from the list above (for ex., description) results in {{{ ldap_modify: Insufficient access (50) additional info: Insufficient 'write' privilege to the 'internalModifiersName' attribute of entry 'cn=mec431-2014,ou=2014,ou=cours,ou=enseignement,ou=groupes,dc=id,dc=polytechnique,dc=edu'. }}} {{{ [11/Nov/2014:10:38:49 +0100] conn=4 fd=256 slot=256 connection from 129.104.31.54 to 129.104.69.49 [11/Nov/2014:10:38:49 +0100] conn=4 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [11/Nov/2014:10:38:49 +0100] conn=4 op=0 RESULT err=14 tag=97 nentries=0 etime=0.008000, SASL bind in progress [11/Nov/2014:10:38:49 +0100] conn=4 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [11/Nov/2014:10:38:49 +0100] conn=4 op=1 RESULT err=14 tag=97 nentries=0 etime=0.002000, SASL bind in progress [11/Nov/2014:10:38:49 +0100] conn=4 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [11/Nov/2014:10:38:49 +0100] conn=4 op=2 RESULT err=0 tag=97 nentries=0 etime=0.001000 dn="uid=sync-cours,ou=comptes generiques,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu" [11/Nov/2014:10:38:49 +0100] conn=4 op=3 SRCH base="dc=id,dc=polytechnique,dc=edu" scope=2 filter="(cn=MEC431-2014)" attrs=ALL [11/Nov/2014:10:38:49 +0100] conn=4 op=3 RESULT err=0 tag=101 nentries=1 etime=0.003000 [11/Nov/2014:10:39:00 +0100] conn=4 op=4 MOD dn="cn=MEC431-2014,ou=2014,ou=Cours,ou=Enseignement,ou=Groupes,dc=id,dc=polytechnique,dc=edu" [11/Nov/2014:10:39:00 +0100] conn=4 op=4 RESULT err=50 tag=103 nentries=0 etime=0.002000 }}} The workaround is to add to all the ACIs that allow modifications the right to modify internalModifiersName attribute (if i add it, everything is fine and the attribute internalModifiersName becomes "cn=ldbm database,cn=plugins,cn=config"). Expected behavior : internalModifiersName should be written like modifiersname without any explicit permission.
Fixed upstream
Please suggest verification steps, executed below which did not work:: ldapmodify -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF > dn: cn=config > changetype: modify > replace: nsslapd-plugin-binddn-tracking > nsslapd-plugin-binddn-tracking: on > EOF modifying entry "cn=config" ldapmodify -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF > dn: uid=ami,dc=example,dc=com > changetype: modify > replace: aci > aci: (targetattr = "objectClass || uniqueMember || owner || cn || description || businessCategory" ) (version 3.0;acl "bug"; allow (add, delete, read, compare, search, write)(userdn="ldap:///uid=ami1,dc=example,dc=com");) > EOF modifying entry "uid=ami,dc=example,dc=com" ldapadd -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 << EOF dn: uid=ami1,dc=example,dc=com cn: ams sn: ams givenname:ams objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson uid: ami1 mail: ams userpassword: Secret123 EOF adding new entry "uid=ami1,dc=example,dc=com" ldapmodify -D "uid=ami,dc=example,dc=com" -w Secret123 -p 389 -h localhost << EOF dn: uid=ami1,dc=example,dc=com changetype: modify replace: internalModifiersName internalModifiersName: Amita EOF
Hi Ami, The steps to verify is found in this patch: https://fedorahosted.org/389/attachment/ticket/47950/0001-Ticket-47950-Bind-DN-tracking-unable-to-write-to-int.patch Please see this python script written by Mark. dirsrvtests/tickets/ticket47950_test.py The issue is an ordinary user who is given the right to behave as a special user (e.g., directory manager) used to fail because the permission to write the user to internalModifiersName was missing. Now the issue was fixed. So, the goal to verify this bug is not updating internalModifiersName directly, but the special user "uid=ami1,dc=example,dc=com" can do something higher level such as creating a replication agreement and modifying it without any problems. Thanks, --noriko
There are two problems here: one is when you enable plugin bind dn tracking, and you perform an operation as a normal user(not Directory Manager!), that operation will unexpectedly fail because the access control plugin is incorrectly checking the rights for the "internalModifiersname" update. Access control should be ignoring internal updates for this attribute. The other issue is around the Directory Manager not being able to update replication settings when plugin bind dn tracking is enabled: Verification steps: [1] Enable plugin bind dn tracking: "nsslapd-plugin-binddn-tracking: on" [2] Add two users: userA & userB [3] Add an aci that allows userA "all" rights to "dc=example,dc=com" [4] Bind as userA, and modify the "sn" attribute of userB --> if this succeeds we have successsfully tested the first part [5] Setup replication(enable replication and create a replication agreement). The repl agreement does not need to point to a valid server - we just need the config entry created so we can test that we can modify it: [6] As "Directory Manager" modify the replication config ldapmodify -D "cn=directory manger" .... dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype; modify replace: nsDS5ReplicaId nsDS5ReplicaId: 8888 [7] Modify the repl agreement ldapmodify -D "cn=directory manger" .... dn: cn=testPluginTracking,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify replace: nsDS5ReplicaPort nsDS5ReplicaPort: 9999 [8] If we get here we have successfully tested the second part.
[root@dhcp201-126 ~]# ps -aef | grep slapd svrbld 7181 1 0 17:34 ? 00:00:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-dhcp201-126 -i /var/run/dirsrv/slapd-dhcp201-126.pid -w /var/run/dirsrv/slapd-dhcp201-126.startpid svrbld 10356 1 0 17:37 ? 00:00:01 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-M1 -i /var/run/dirsrv/slapd-M1.pid -w /var/run/dirsrv/slapd-M1.startpid svrbld 10793 1 0 17:37 ? 00:00:01 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-M2 -i /var/run/dirsrv/slapd-M2.pid -w /var/run/dirsrv/slapd-M2.startpid svrbld 11254 1 0 17:38 ? 00:00:01 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-M3 -i /var/run/dirsrv/slapd-M3.pid -w /var/run/dirsrv/slapd-M3.startpid svrbld 11739 1 0 17:38 ? 00:00:01 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-M4 -i /var/run/dirsrv/slapd-M4.pid -w /var/run/dirsrv/slapd-M4.startpid root 13128 3645 0 17:53 pts/0 00:00:00 grep --color=auto slapd [root@dhcp201-126 ~]# netstat -nlp | grep slapd tcp6 0 0 :::30104 :::* LISTEN 11254/ns-slapd tcp6 0 0 :::30105 :::* LISTEN 11254/ns-slapd tcp6 0 0 :::30106 :::* LISTEN 11739/ns-slapd tcp6 0 0 :::32730 :::* LISTEN 7181/ns-slapd tcp6 0 0 :::30107 :::* LISTEN 11739/ns-slapd tcp6 0 0 :::30100 :::* LISTEN 10356/ns-slapd tcp6 0 0 :::30101 :::* LISTEN 10356/ns-slapd tcp6 0 0 :::30102 :::* LISTEN 10793/ns-slapd tcp6 0 0 :::30103 :::* LISTEN 10793/ns-slapd PART 1 ======= [root@dhcp201-126 ~]# ldapmodify -D "cn=directory manager" -w Secret123 -p 30100 -h localhost << EOF > dn: cn=config > changetype: modify > replace: nsslapd-plugin-binddn-tracking > nsslapd-plugin-binddn-tracking: on > EOF modifying entry "cn=config" [root@dhcp201-126 ~]# ldapadd -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 << EOF > dn: uid=ami,dc=example,dc=com > cn: ams > sn: ams > givenname: ams > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetOrgPerson > uid: ami > mail: ams > userpassword: Secret123 > EOF adding new entry "uid=ami,dc=example,dc=com" [root@dhcp201-126 ~]# ldapadd -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 << EOF > dn: uid=B,dc=example,dc=com > cn: B > sn: B > givenname: B > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetOrgPerson > uid: B > mail: B > userpassword: Secret123 > EOF adding new entry "uid=B,dc=example,dc=com" [root@dhcp201-126 ~]# ldapmodify -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 << EOF > dn: dc=example,dc=com > changetype: modify > replace: aci > aci: (targetattr="*")(version 3.0; acl "Managerami"; allow (all) (userdn="ldap:///uid=ami,dc=example,dc=com");) > EOF modifying entry "dc=example,dc=com" [root@dhcp201-126 ~]# ldapmodify -h localhost -p 30100 -D "uid=ami,dc=example,dc=com" -w Secret123 << EOF > dn: uid=B,dc=example,dc=com > changetype: modify > replace: sn > sn: new > EOF modifying entry "uid=B,dc=example,dc=com" [root@dhcp201-126 ~]# ldapsearch -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 -b "uid=B,dc=example,dc=com" # extended LDIF # # LDAPv3 # base <uid=B,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # B, example.com dn: uid=B,dc=example,dc=com sn: new cn: B givenName: B objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: B mail: B userPassword:: e1NTSEF9Y2lWTUp6RzhKVWVyT1ZvTkN5TTIrOCtTaWhKUmRKMVB3NFNyZHc9PQ= = # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ========================= Part 2 ------ [root@dhcp201-126 ~]# ldapmodify -h localhost -p 30100 -D "cn=directory manager" -w Secret123 << EOF > dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config > changetype: modify > replace: nsDS5ReplicaType > nsDS5ReplicaType: 2 > EOF modifying entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" [root@dhcp201-126 ~]# ldapmodify -h localhost -p 30100 -D "cn=directory manager" -w Secret123 << EOF > dn: cn=M1_to_M2,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config > changetype: modify > replace: nsDS5ReplicaPort > nsDS5ReplicaPort: 9999 > EOF modifying entry "cn=M1_to_M2,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" Both parts are verified successfully. Hence VERIFIED.
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. https://rhn.redhat.com/errata/RHSA-2015-0416.html