Giovanni Mancuso
2009-Jul-15 16:56 UTC
[389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
Hi, i try to configure 2 Directory Server with db link. I have first DS that point to second DS that have DB in filesystem. I create a proxy user in second DS: # tproxy, config dn: uid=tproxy,cn=config uid: tproxy givenName: test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson sn: proxy cn: test proxy userPassword:: ********************************************* and i create in first DS the "Dababase link" that use this user to bind in second DS. In second DS i add the following aci: (targetattr = "*") (target = "ldap:///dc=example,dc=com") (version 3.0;acl "AciChepermettetutto";allow (all)(userdn "ldap:///uid=tproxy,cn=config");) (targetattr = "*") (target = "ldap:///dc=example,dc=com") (version 3.0;acl "proxy acl";allow (proxy)(userdn = "ldap:///uid=tproxy,cn=config");) Bu if i try to execute the ldapserach in first directory server i have the following error: dapsearch -h localhost -x -p 20389 -D "cn=Directory Manager" -w ********* -b "dc=example,dc=com" "(objectclass=*)" # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 53 Server is unwilling to perform text: Proxy dn should not be rootdn # numResponses: 1 If i enable verbose logging in my error log i have: [15/Jul/2009:18:44:47 +0200] - activity on 65r [15/Jul/2009:18:44:47 +0200] - => slapi_reslimit_get_integer_limit() conn=0xb1557d68, handle=3 [15/Jul/2009:18:44:47 +0200] - <= slapi_reslimit_get_integer_limit() returning NO VALUE [15/Jul/2009:18:44:47 +0200] - read activity on 65 [15/Jul/2009:18:44:47 +0200] - add_pb [15/Jul/2009:18:44:47 +0200] - => slapi_reslimit_get_integer_limit() conn=0xb1557c08, handle=3 [15/Jul/2009:18:44:47 +0200] - <= slapi_reslimit_get_integer_limit() returning NO VALUE [15/Jul/2009:18:44:47 +0200] - get_pb [15/Jul/2009:18:44:47 +0200] - conn 1 activity level 2 [15/Jul/2009:18:44:47 +0200] - conn 1 turbo rank = 2 out of 3 conns [15/Jul/2009:18:44:47 +0200] - do_search [15/Jul/2009:18:44:47 +0200] - => get_filter_internal [15/Jul/2009:18:44:47 +0200] - PRESENT [15/Jul/2009:18:44:47 +0200] - <= get_filter_internal 0 [15/Jul/2009:18:44:47 +0200] get_filter - before optimize: (objectClass=*) [15/Jul/2009:18:44:47 +0200] get_filter - after optimize: (objectClass=*) [15/Jul/2009:18:44:47 +0200] - SRCH base="dc=example,dc=com" scope=2 deref=0 sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=*)" attrs=ALL [15/Jul/2009:18:44:47 +0200] - => get_ldapmessage_controls [15/Jul/2009:18:44:47 +0200] - => slapi_control_present (looking for 2.16.840.1.113730.3.4.2) [15/Jul/2009:18:44:47 +0200] - <= slapi_control_present 0 (NOT FOUND) [15/Jul/2009:18:44:47 +0200] - => slapi_control_present (looking for 1.3.6.1.4.1.42.2.27.8.5.1) [15/Jul/2009:18:44:47 +0200] - <= slapi_control_present 0 (NOT FOUND) [15/Jul/2009:18:44:48 +0200] - <= get_ldapmessage_controls 2 controls [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for 2.16.840.1.113730.3.4.3) [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for 2.16.840.1.113730.3.4.20) [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for 2.16.840.1.113730.3.4.14) [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for 1.3.6.1.4.1.42.2.27.9.5.2) [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) [15/Jul/2009:18:44:48 +0200] - mapping tree selected backend : example [15/Jul/2009:18:44:48 +0200] - => slapi_reslimit_get_integer_limit() conn=0xb1557cb8, handle=2 [15/Jul/2009:18:44:48 +0200] - <= slapi_reslimit_get_integer_limit() returning NO VALUE [15/Jul/2009:18:44:48 +0200] - => slapi_reslimit_get_integer_limit() conn=0xb1557cb8, handle=1 [15/Jul/2009:18:44:48 +0200] - <= slapi_reslimit_get_integer_limit() returning NO VALUE [15/Jul/2009:18:44:48 +0200] - => compute_limits: sizelimit=2000, timelimit=3600 [15/Jul/2009:18:44:48 +0200] - Calling plugin ''ACL preoperation'' #1 type 403 [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for 2.16.840.1.113730.3.4.12) [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 1 (FOUND) [15/Jul/2009:18:44:48 +0200] - => send_ldap_result 53::Proxy dn should not be rootdn [15/Jul/2009:18:44:48 +0200] - flush_ber() wrote 43 bytes to socket 65 [15/Jul/2009:18:44:48 +0200] - <= send_ldap_result [15/Jul/2009:18:44:48 +0200] - mapping tree release backend : example [15/Jul/2009:18:44:48 +0200] - slapi_filter_free type 0x87 [15/Jul/2009:18:44:49 +0200] - => slapi_reslimit_get_integer_limit() conn=0xb1557d68, handle=3 [15/Jul/2009:18:44:49 +0200] - <= slapi_reslimit_get_integer_limit() returning NO VALUE [15/Jul/2009:18:44:49 +0200] - => slapi_reslimit_get_integer_limit() conn=0xb1557cb8, handle=3 [15/Jul/2009:18:44:49 +0200] - <= slapi_reslimit_get_integer_limit() returning NO VALUE [15/Jul/2009:18:44:49 +0200] - => slapi_reslimit_get_integer_limit() conn=0xb1557c08, handle=3 [15/Jul/2009:18:44:49 +0200] - <= slapi_reslimit_get_integer_limit() returning NO VALUE [15/Jul/2009:18:44:49 +0200] - listener got signaled [15/Jul/2009:18:44:53 +0200] - Event id a19b958 called at 1247676293 (scheduled for 1247676293) [15/Jul/2009:18:44:55 +0200] - ldbm backend flushing [15/Jul/2009:18:44:55 +0200] - ldbm backend done flushing [15/Jul/2009:18:44:55 +0200] - ldbm backend flushing [15/Jul/2009:18:44:55 +0200] - ldbm backend done flushing The problem seems the "ACL preoperation" plugin. Indeed if i disable this plugin, it WORKS. But i cannot disable this plugin. Any ideas to solve the problem?? Thanks and sorry in advance for my bad English //
Rich Megginson
2009-Jul-15 17:02 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
Giovanni Mancuso wrote:> Hi, > > i try to configure 2 Directory Server with db link. > > I have first DS that point to second DS that have DB in filesystem. > > I create a proxy user in second DS: > > # tproxy, config > dn: uid=tproxy,cn=config > uid: tproxy > givenName: test > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetorgperson > sn: proxy > cn: test proxy > userPassword:: ********************************************* > > and i create in first DS the "Dababase link" that use this user to > bind in second DS. > > In second DS i add the following aci:What entry did you add this aci to?> > (targetattr = "*") (target = "ldap:///dc=example,dc=com") (version > 3.0;acl "AciChepermettetutto";allow (all)(userdn = > "ldap:///uid=tproxy,cn=config");)you should not need this aci> > (targetattr = "*") (target = "ldap:///dc=example,dc=com") (version > 3.0;acl "proxy acl";allow (proxy)(userdn = > "ldap:///uid=tproxy,cn=config");)This is the correct aci> > Bu if i try to execute the ldapserach in first directory server i have > the following error:proxy does not currently work with directory manager. Directory manager is considered a "local" user to each directory server. Try a different user.> > dapsearch -h localhost -x -p 20389 -D "cn=Directory Manager" -w > ********* -b "dc=example,dc=com" "(objectclass=*)" > # extended LDIF > # > # LDAPv3 > # base <dc=example,dc=com> with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # search result > search: 2 > result: 53 Server is unwilling to perform > text: Proxy dn should not be rootdn > > # numResponses: 1 > > If i enable verbose logging in my error log i have: > > [15/Jul/2009:18:44:47 +0200] - activity on 65r > [15/Jul/2009:18:44:47 +0200] - => slapi_reslimit_get_integer_limit() > conn=0xb1557d68, handle=3 > [15/Jul/2009:18:44:47 +0200] - <= slapi_reslimit_get_integer_limit() > returning NO VALUE > [15/Jul/2009:18:44:47 +0200] - read activity on > 65 > [15/Jul/2009:18:44:47 +0200] - > add_pb > [15/Jul/2009:18:44:47 +0200] - => slapi_reslimit_get_integer_limit() > conn=0xb1557c08, handle=3 > [15/Jul/2009:18:44:47 +0200] - <= slapi_reslimit_get_integer_limit() > returning NO VALUE > [15/Jul/2009:18:44:47 +0200] - > get_pb > [15/Jul/2009:18:44:47 +0200] - conn 1 activity level = > 2 > [15/Jul/2009:18:44:47 +0200] - conn 1 turbo rank = 2 out of 3 > conns > [15/Jul/2009:18:44:47 +0200] - > do_search > [15/Jul/2009:18:44:47 +0200] - => > get_filter_internal > [15/Jul/2009:18:44:47 +0200] - > PRESENT > [15/Jul/2009:18:44:47 +0200] - <= get_filter_internal > 0 > [15/Jul/2009:18:44:47 +0200] get_filter - before optimize: > (objectClass=*) > [15/Jul/2009:18:44:47 +0200] get_filter - after optimize: > (objectClass=*) > [15/Jul/2009:18:44:47 +0200] - SRCH base="dc=example,dc=com" scope=2 > deref=0 sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=*)" > attrs=ALL > [15/Jul/2009:18:44:47 +0200] - => > get_ldapmessage_controls > > [15/Jul/2009:18:44:47 +0200] - => slapi_control_present (looking for > 2.16.840.1.113730.3.4.2) > > [15/Jul/2009:18:44:47 +0200] - <= slapi_control_present 0 (NOT FOUND) > [15/Jul/2009:18:44:47 +0200] - => slapi_control_present (looking for > 1.3.6.1.4.1.42.2.27.8.5.1) > [15/Jul/2009:18:44:47 +0200] - <= slapi_control_present 0 (NOT FOUND) > [15/Jul/2009:18:44:48 +0200] - <= get_ldapmessage_controls 2 controls > [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for > 2.16.840.1.113730.3.4.3) > [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) > [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for > 2.16.840.1.113730.3.4.20) > [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) > [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for > 2.16.840.1.113730.3.4.14) > [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) > [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for > 1.3.6.1.4.1.42.2.27.9.5.2) > [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) > [15/Jul/2009:18:44:48 +0200] - mapping tree selected backend : example > [15/Jul/2009:18:44:48 +0200] - => slapi_reslimit_get_integer_limit() > conn=0xb1557cb8, handle=2 > [15/Jul/2009:18:44:48 +0200] - <= slapi_reslimit_get_integer_limit() > returning NO VALUE > [15/Jul/2009:18:44:48 +0200] - => slapi_reslimit_get_integer_limit() > conn=0xb1557cb8, handle=1 > [15/Jul/2009:18:44:48 +0200] - <= slapi_reslimit_get_integer_limit() > returning NO VALUE > [15/Jul/2009:18:44:48 +0200] - => compute_limits: sizelimit=2000, > timelimit=3600 > [15/Jul/2009:18:44:48 +0200] - Calling plugin ''ACL preoperation'' #1 > type 403 > [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for > 2.16.840.1.113730.3.4.12) > [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 1 (FOUND) > [15/Jul/2009:18:44:48 +0200] - => send_ldap_result 53::Proxy dn should > not be rootdn > [15/Jul/2009:18:44:48 +0200] - flush_ber() wrote 43 bytes to socket 65 > [15/Jul/2009:18:44:48 +0200] - <= send_ldap_result > [15/Jul/2009:18:44:48 +0200] - mapping tree release backend : example > [15/Jul/2009:18:44:48 +0200] - slapi_filter_free type 0x87 > [15/Jul/2009:18:44:49 +0200] - => slapi_reslimit_get_integer_limit() > conn=0xb1557d68, handle=3 > [15/Jul/2009:18:44:49 +0200] - <= slapi_reslimit_get_integer_limit() > returning NO VALUE > [15/Jul/2009:18:44:49 +0200] - => slapi_reslimit_get_integer_limit() > conn=0xb1557cb8, handle=3 > [15/Jul/2009:18:44:49 +0200] - <= slapi_reslimit_get_integer_limit() > returning NO VALUE > [15/Jul/2009:18:44:49 +0200] - => slapi_reslimit_get_integer_limit() > conn=0xb1557c08, handle=3 > [15/Jul/2009:18:44:49 +0200] - <= slapi_reslimit_get_integer_limit() > returning NO VALUE > [15/Jul/2009:18:44:49 +0200] - listener got signaled > [15/Jul/2009:18:44:53 +0200] - Event id a19b958 called at 1247676293 > (scheduled for 1247676293) > [15/Jul/2009:18:44:55 +0200] - ldbm backend flushing > [15/Jul/2009:18:44:55 +0200] - ldbm backend done flushing > [15/Jul/2009:18:44:55 +0200] - ldbm backend flushing > [15/Jul/2009:18:44:55 +0200] - ldbm backend done flushing > > The problem seems the "ACL preoperation" plugin. Indeed if i disable > this plugin, it WORKS. > But i cannot disable this plugin. > > Any ideas to solve the problem?? > > Thanks and sorry in advance for my bad English > // > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
Giovanni Mancuso
2009-Jul-15 22:36 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
Rich Megginson wrote:> Giovanni Mancuso wrote: >> Hi, >> >> i try to configure 2 Directory Server with db link. >> >> I have first DS that point to second DS that have DB in filesystem. >> >> I create a proxy user in second DS: >> >> # tproxy, config >> dn: uid=tproxy,cn=config >> uid: tproxy >> givenName: test >> objectClass: top >> objectClass: person >> objectClass: organizationalPerson >> objectClass: inetorgperson >> sn: proxy >> cn: test proxy >> userPassword:: ********************************************* >> >> and i create in first DS the "Dababase link" that use this user to >> bind in second DS. >> >> In second DS i add the following aci: > What entry did you add this aci to?I add the aci in root suffix (dc=example,dc=com)>> >> (targetattr = "*") (target = "ldap:///dc=example,dc=com") (version >> 3.0;acl "AciChepermettetutto";allow (all)(userdn >> "ldap:///uid=tproxy,cn=config");) > you should not need this aciOk i delete this aci.> >> >> (targetattr = "*") (target = "ldap:///dc=example,dc=com") (version >> 3.0;acl "proxy acl";allow (proxy)(userdn >> "ldap:///uid=tproxy,cn=config");) > This is the correct aci >> >> Bu if i try to execute the ldapserach in first directory server i >> have the following error: > proxy does not currently work with directory manager. Directory > manager is considered a "local" user to each directory server. Try a > different user.Now, i create a new user in first DS: dn: uid=ttestuser,cn=config uid: testuser givenName: test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson sn: user cn: test user userPassword: ********* And if i try, to run ldapsearch with this user it works: ldapsearch -LLL -s base -h localhost -x -p 20389 -D "uid=ttestuser,cn=config" -w ********* -b "dc=example,dc=com" "(objectclass=*)" dn: dc=example,dc=com dc: example objectClass: top objectClass: domain The problem now is if i try to execute add in first directory server. I create the following ldif: cat /tmp/tempuser.ldif dn: uid=conaltroustente,node=testgio,dc=example,dc=com uid: conaltroustente givenName: conaltroustente objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson sn: dsdsds cn: pippopidddssd dsdsds And i try to run: ldapmodify -a -h localhost -x -p 20389 -D "uid=ttestuser,cn=config" -w *********** -f /tmp/tempuser.ldif adding new entry "uid=conaltroustente,node=testgio,dc=example,dc=com" ldap_add: Insufficient access (50) additional info: Insufficient ''add'' privilege to add the entry ''uid=conaltroustente,node=testgio,dc=example,dc=com''. Any ideas??>> >> dapsearch -h localhost -x -p 20389 -D "cn=Directory Manager" -w >> ********* -b "dc=example,dc=com" "(objectclass=*)" >> # extended LDIF >> # >> # LDAPv3 >> # base <dc=example,dc=com> with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # >> >> # search result >> search: 2 >> result: 53 Server is unwilling to perform >> text: Proxy dn should not be rootdn >> >> # numResponses: 1 >> >> If i enable verbose logging in my error log i have: >> >> [15/Jul/2009:18:44:47 +0200] - activity on 65r >> [15/Jul/2009:18:44:47 +0200] - => slapi_reslimit_get_integer_limit() >> conn=0xb1557d68, handle=3 >> [15/Jul/2009:18:44:47 +0200] - <= slapi_reslimit_get_integer_limit() >> returning NO VALUE [15/Jul/2009:18:44:47 +0200] - read activity >> on 65 [15/Jul/2009:18:44:47 >> +0200] - >> add_pb >> [15/Jul/2009:18:44:47 +0200] - => slapi_reslimit_get_integer_limit() >> conn=0xb1557c08, handle=3 >> [15/Jul/2009:18:44:47 +0200] - <= slapi_reslimit_get_integer_limit() >> returning NO VALUE [15/Jul/2009:18:44:47 +0200] - >> get_pb >> [15/Jul/2009:18:44:47 +0200] - conn 1 activity level >> 2 [15/Jul/2009:18:44:47 +0200] - >> conn 1 turbo rank = 2 out of 3 conns >> [15/Jul/2009:18:44:47 +0200] - >> do_search >> [15/Jul/2009:18:44:47 +0200] - => >> get_filter_internal >> [15/Jul/2009:18:44:47 +0200] - >> PRESENT >> [15/Jul/2009:18:44:47 +0200] - <= get_filter_internal >> 0 [15/Jul/2009:18:44:47 +0200] >> get_filter - before optimize: (objectClass=*) >> [15/Jul/2009:18:44:47 +0200] get_filter - after optimize: >> (objectClass=*) [15/Jul/2009:18:44:47 +0200] - SRCH >> base="dc=example,dc=com" scope=2 deref=0 sizelimit=0 timelimit=0 >> attrsonly=0 filter="(objectClass=*)" attrs=ALL >> [15/Jul/2009:18:44:47 +0200] - => >> get_ldapmessage_controls >> >> [15/Jul/2009:18:44:47 +0200] - => slapi_control_present (looking for >> 2.16.840.1.113730.3.4.2) >> >> [15/Jul/2009:18:44:47 +0200] - <= slapi_control_present 0 (NOT FOUND) >> [15/Jul/2009:18:44:47 +0200] - => slapi_control_present (looking for >> 1.3.6.1.4.1.42.2.27.8.5.1) >> [15/Jul/2009:18:44:47 +0200] - <= slapi_control_present 0 (NOT FOUND) >> [15/Jul/2009:18:44:48 +0200] - <= get_ldapmessage_controls 2 controls >> [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for >> 2.16.840.1.113730.3.4.3) >> [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) >> [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for >> 2.16.840.1.113730.3.4.20) >> [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) >> [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for >> 2.16.840.1.113730.3.4.14) >> [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) >> [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for >> 1.3.6.1.4.1.42.2.27.9.5.2) >> [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) >> [15/Jul/2009:18:44:48 +0200] - mapping tree selected backend : example >> [15/Jul/2009:18:44:48 +0200] - => slapi_reslimit_get_integer_limit() >> conn=0xb1557cb8, handle=2 >> [15/Jul/2009:18:44:48 +0200] - <= slapi_reslimit_get_integer_limit() >> returning NO VALUE >> [15/Jul/2009:18:44:48 +0200] - => slapi_reslimit_get_integer_limit() >> conn=0xb1557cb8, handle=1 >> [15/Jul/2009:18:44:48 +0200] - <= slapi_reslimit_get_integer_limit() >> returning NO VALUE >> [15/Jul/2009:18:44:48 +0200] - => compute_limits: sizelimit=2000, >> timelimit=3600 >> [15/Jul/2009:18:44:48 +0200] - Calling plugin ''ACL preoperation'' #1 >> type 403 >> [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for >> 2.16.840.1.113730.3.4.12) >> [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 1 (FOUND) >> [15/Jul/2009:18:44:48 +0200] - => send_ldap_result 53::Proxy dn >> should not be rootdn >> [15/Jul/2009:18:44:48 +0200] - flush_ber() wrote 43 bytes to socket 65 >> [15/Jul/2009:18:44:48 +0200] - <= send_ldap_result >> [15/Jul/2009:18:44:48 +0200] - mapping tree release backend : example >> [15/Jul/2009:18:44:48 +0200] - slapi_filter_free type 0x87 >> [15/Jul/2009:18:44:49 +0200] - => slapi_reslimit_get_integer_limit() >> conn=0xb1557d68, handle=3 >> [15/Jul/2009:18:44:49 +0200] - <= slapi_reslimit_get_integer_limit() >> returning NO VALUE >> [15/Jul/2009:18:44:49 +0200] - => slapi_reslimit_get_integer_limit() >> conn=0xb1557cb8, handle=3 >> [15/Jul/2009:18:44:49 +0200] - <= slapi_reslimit_get_integer_limit() >> returning NO VALUE >> [15/Jul/2009:18:44:49 +0200] - => slapi_reslimit_get_integer_limit() >> conn=0xb1557c08, handle=3 >> [15/Jul/2009:18:44:49 +0200] - <= slapi_reslimit_get_integer_limit() >> returning NO VALUE >> [15/Jul/2009:18:44:49 +0200] - listener got signaled >> [15/Jul/2009:18:44:53 +0200] - Event id a19b958 called at 1247676293 >> (scheduled for 1247676293) >> [15/Jul/2009:18:44:55 +0200] - ldbm backend flushing >> [15/Jul/2009:18:44:55 +0200] - ldbm backend done flushing >> [15/Jul/2009:18:44:55 +0200] - ldbm backend flushing >> [15/Jul/2009:18:44:55 +0200] - ldbm backend done flushing >> >> The problem seems the "ACL preoperation" plugin. Indeed if i disable >> this plugin, it WORKS. >> But i cannot disable this plugin. >> >> Any ideas to solve the problem?? >> >> Thanks and sorry in advance for my bad English >> // >> >> ------------------------------------------------------------------------ >> >> -- >> 389 users mailing list >> 389-users@redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
Rich Megginson
2009-Jul-15 22:50 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
Giovanni Mancuso wrote:> Rich Megginson wrote: >> Giovanni Mancuso wrote: >>> Hi, >>> >>> i try to configure 2 Directory Server with db link. >>> >>> I have first DS that point to second DS that have DB in filesystem. >>> >>> I create a proxy user in second DS: >>> >>> # tproxy, config >>> dn: uid=tproxy,cn=config >>> uid: tproxy >>> givenName: test >>> objectClass: top >>> objectClass: person >>> objectClass: organizationalPerson >>> objectClass: inetorgperson >>> sn: proxy >>> cn: test proxy >>> userPassword:: ********************************************* >>> >>> and i create in first DS the "Dababase link" that use this user to >>> bind in second DS. >>> >>> In second DS i add the following aci: >> What entry did you add this aci to? > I add the aci in root suffix (dc=example,dc=com)Ok>>> >>> (targetattr = "*") (target = "ldap:///dc=example,dc=com") (version >>> 3.0;acl "AciChepermettetutto";allow (all)(userdn = >>> "ldap:///uid=tproxy,cn=config");) >> you should not need this aci > Ok i delete this aci. >> >>> >>> (targetattr = "*") (target = "ldap:///dc=example,dc=com") (version >>> 3.0;acl "proxy acl";allow (proxy)(userdn = >>> "ldap:///uid=tproxy,cn=config");) >> This is the correct aci >>> >>> Bu if i try to execute the ldapserach in first directory server i >>> have the following error: >> proxy does not currently work with directory manager. Directory >> manager is considered a "local" user to each directory server. Try a >> different user. > Now, i create a new user in first DS:By first DS do you mean the DS with the "real" database or the DS with the database link? We also refer to the DS with the "real" database as the "remote" DS and the DS with the database link as the "local" DS.> > dn: uid=ttestuser,cn=config > uid: testuser > givenName: test > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetorgperson > sn: user > cn: test user > userPassword: ********* > > And if i try, to run ldapsearch with this user it works: > > ldapsearch -LLL -s base -h localhost -x -p 20389 -D > "uid=ttestuser,cn=config" -w ********* -b "dc=example,dc=com" > "(objectclass=*)" > dn: dc=example,dc=com > dc: example > objectClass: top > objectClass: domain > > The problem now is if i try to execute add in first directory server. > > I create the following ldif: > > cat /tmp/tempuser.ldif > dn: uid=conaltroustente,node=testgio,dc=example,dc=com > uid: conaltroustente > givenName: conaltroustente > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetorgperson > sn: dsdsds > cn: pippopidddssd dsdsds > > And i try to run: > > ldapmodify -a -h localhost -x -p 20389 -D "uid=ttestuser,cn=config" -w > *********** -f /tmp/tempuser.ldif > adding new entry "uid=conaltroustente,node=testgio,dc=example,dc=com" > ldap_add: Insufficient access (50) > additional info: Insufficient ''add'' privilege to add the entry > ''uid=conaltroustente,node=testgio,dc=example,dc=com''. > > Any ideas??Did you add an ACI to allow the uid=ttestuser,cn=config to add entries under node=testgio,dc=example,dc=com ?> >>> >>> dapsearch -h localhost -x -p 20389 -D "cn=Directory Manager" -w >>> ********* -b "dc=example,dc=com" "(objectclass=*)" >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base <dc=example,dc=com> with scope subtree >>> # filter: (objectclass=*) >>> # requesting: ALL >>> # >>> >>> # search result >>> search: 2 >>> result: 53 Server is unwilling to perform >>> text: Proxy dn should not be rootdn >>> >>> # numResponses: 1 >>> >>> If i enable verbose logging in my error log i have: >>> >>> [15/Jul/2009:18:44:47 +0200] - activity on 65r >>> [15/Jul/2009:18:44:47 +0200] - => slapi_reslimit_get_integer_limit() >>> conn=0xb1557d68, handle=3 >>> [15/Jul/2009:18:44:47 +0200] - <= slapi_reslimit_get_integer_limit() >>> returning NO VALUE [15/Jul/2009:18:44:47 +0200] - read activity >>> on 65 >>> [15/Jul/2009:18:44:47 +0200] - >>> add_pb >>> [15/Jul/2009:18:44:47 +0200] - => slapi_reslimit_get_integer_limit() >>> conn=0xb1557c08, handle=3 >>> [15/Jul/2009:18:44:47 +0200] - <= slapi_reslimit_get_integer_limit() >>> returning NO VALUE [15/Jul/2009:18:44:47 +0200] - >>> get_pb >>> [15/Jul/2009:18:44:47 +0200] - conn 1 activity level = >>> 2 [15/Jul/2009:18:44:47 +0200] - >>> conn 1 turbo rank = 2 out of 3 conns >>> [15/Jul/2009:18:44:47 +0200] - >>> do_search >>> [15/Jul/2009:18:44:47 +0200] - => >>> get_filter_internal >>> [15/Jul/2009:18:44:47 +0200] - >>> PRESENT >>> [15/Jul/2009:18:44:47 +0200] - <= get_filter_internal >>> 0 [15/Jul/2009:18:44:47 +0200] >>> get_filter - before optimize: (objectClass=*) >>> [15/Jul/2009:18:44:47 +0200] get_filter - after optimize: >>> (objectClass=*) [15/Jul/2009:18:44:47 +0200] - >>> SRCH base="dc=example,dc=com" scope=2 deref=0 sizelimit=0 >>> timelimit=0 attrsonly=0 filter="(objectClass=*)" attrs=ALL >>> [15/Jul/2009:18:44:47 +0200] - => >>> get_ldapmessage_controls >>> >>> [15/Jul/2009:18:44:47 +0200] - => slapi_control_present (looking for >>> 2.16.840.1.113730.3.4.2) >>> >>> [15/Jul/2009:18:44:47 +0200] - <= slapi_control_present 0 (NOT FOUND) >>> [15/Jul/2009:18:44:47 +0200] - => slapi_control_present (looking for >>> 1.3.6.1.4.1.42.2.27.8.5.1) >>> [15/Jul/2009:18:44:47 +0200] - <= slapi_control_present 0 (NOT FOUND) >>> [15/Jul/2009:18:44:48 +0200] - <= get_ldapmessage_controls 2 controls >>> [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for >>> 2.16.840.1.113730.3.4.3) >>> [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) >>> [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for >>> 2.16.840.1.113730.3.4.20) >>> [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) >>> [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for >>> 2.16.840.1.113730.3.4.14) >>> [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) >>> [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for >>> 1.3.6.1.4.1.42.2.27.9.5.2) >>> [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 0 (NOT FOUND) >>> [15/Jul/2009:18:44:48 +0200] - mapping tree selected backend : example >>> [15/Jul/2009:18:44:48 +0200] - => slapi_reslimit_get_integer_limit() >>> conn=0xb1557cb8, handle=2 >>> [15/Jul/2009:18:44:48 +0200] - <= slapi_reslimit_get_integer_limit() >>> returning NO VALUE >>> [15/Jul/2009:18:44:48 +0200] - => slapi_reslimit_get_integer_limit() >>> conn=0xb1557cb8, handle=1 >>> [15/Jul/2009:18:44:48 +0200] - <= slapi_reslimit_get_integer_limit() >>> returning NO VALUE >>> [15/Jul/2009:18:44:48 +0200] - => compute_limits: sizelimit=2000, >>> timelimit=3600 >>> [15/Jul/2009:18:44:48 +0200] - Calling plugin ''ACL preoperation'' #1 >>> type 403 >>> [15/Jul/2009:18:44:48 +0200] - => slapi_control_present (looking for >>> 2.16.840.1.113730.3.4.12) >>> [15/Jul/2009:18:44:48 +0200] - <= slapi_control_present 1 (FOUND) >>> [15/Jul/2009:18:44:48 +0200] - => send_ldap_result 53::Proxy dn >>> should not be rootdn >>> [15/Jul/2009:18:44:48 +0200] - flush_ber() wrote 43 bytes to socket 65 >>> [15/Jul/2009:18:44:48 +0200] - <= send_ldap_result >>> [15/Jul/2009:18:44:48 +0200] - mapping tree release backend : example >>> [15/Jul/2009:18:44:48 +0200] - slapi_filter_free type 0x87 >>> [15/Jul/2009:18:44:49 +0200] - => slapi_reslimit_get_integer_limit() >>> conn=0xb1557d68, handle=3 >>> [15/Jul/2009:18:44:49 +0200] - <= slapi_reslimit_get_integer_limit() >>> returning NO VALUE >>> [15/Jul/2009:18:44:49 +0200] - => slapi_reslimit_get_integer_limit() >>> conn=0xb1557cb8, handle=3 >>> [15/Jul/2009:18:44:49 +0200] - <= slapi_reslimit_get_integer_limit() >>> returning NO VALUE >>> [15/Jul/2009:18:44:49 +0200] - => slapi_reslimit_get_integer_limit() >>> conn=0xb1557c08, handle=3 >>> [15/Jul/2009:18:44:49 +0200] - <= slapi_reslimit_get_integer_limit() >>> returning NO VALUE >>> [15/Jul/2009:18:44:49 +0200] - listener got signaled >>> [15/Jul/2009:18:44:53 +0200] - Event id a19b958 called at 1247676293 >>> (scheduled for 1247676293) >>> [15/Jul/2009:18:44:55 +0200] - ldbm backend flushing >>> [15/Jul/2009:18:44:55 +0200] - ldbm backend done flushing >>> [15/Jul/2009:18:44:55 +0200] - ldbm backend flushing >>> [15/Jul/2009:18:44:55 +0200] - ldbm backend done flushing >>> >>> The problem seems the "ACL preoperation" plugin. Indeed if i disable >>> this plugin, it WORKS. >>> But i cannot disable this plugin. >>> >>> Any ideas to solve the problem?? >>> >>> Thanks and sorry in advance for my bad English >>> // >>> >>> ------------------------------------------------------------------------ >>> >>> >>> -- >>> 389 users mailing list >>> 389-users@redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >> >> ------------------------------------------------------------------------ >> >> -- >> 389 users mailing list >> 389-users@redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
Roberto Polli
2009-Jul-23 14:53 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
hi all, I got similar problem with: dblink+proxyuser.>Rich Megginson wrote: >>Giovanni Mancuso wrote: >>Bu if i try to execute the ldapserach in first directory server i have the >> following error: proxy does not currently work with directory manager. >> Directory manager is considered a "local" user to each directory server. >> Try a different user. Now, i create a new user in first DS:>By first DS do you mean the DS with the "real" database or the DS with the > database link? We also refer to the DS with the "real" database as the > "remote" DS and the DS with the database link as the "local" DS.case1) * I bind with uid=admin to the local DS tree to modify the "givenName" of a user on the remote server * the modify is successful, as the uid=admin is proxied and the "uid=admin" is replicated on the remote server case2) * same as case1 but I try to modify "userPassword" * the modify fails as the remote server won''t evaluate aci on "uid=admin" but on "dn:proxyuser">Did you add an ACI to allow the uid=ttestuser,cn=config to add entries under > node=testgio,dc=example,dc=com ?to solve that issue it seems by this thread that you suggest giving (proxy+all) access to proxyuser instead of the proxied one (uid=admin) imho this won''t fit, as every proxied user will be granted write access; while the desired behaviour is to have the aci checked against uid=admin Am I wrong? Peace, R. -- Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 Tel. cel +39.340.6522736 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto della legge in materia di protezione dei dati personali."
Rich Megginson
2009-Jul-23 15:49 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
Roberto Polli wrote:> hi all, > > I got similar problem with: dblink+proxyuser. > > >> Rich Megginson wrote: >> >>> Giovanni Mancuso wrote: >>> Bu if i try to execute the ldapserach in first directory server i have the >>> following error: proxy does not currently work with directory manager. >>> Directory manager is considered a "local" user to each directory server. >>> Try a different user. Now, i create a new user in first DS: >>> > > >> By first DS do you mean the DS with the "real" database or the DS with the >> database link? We also refer to the DS with the "real" database as the >> "remote" DS and the DS with the database link as the "local" DS. >> > > case1) > * I bind with uid=admin to the local DS tree to modify the "givenName" of a > user on the remote server > * the modify is successful, as the uid=admin is proxied and the "uid=admin" is > replicated on the remote server > > case2) > * same as case1 but I try to modify "userPassword" > * the modify fails as the remote server won''t evaluate aci on "uid=admin" but > on "dn:proxyuser" >Is there an aci on the remote server that explicitly denies access to userPassword? How about on the local server?> >> Did you add an ACI to allow the uid=ttestuser,cn=config to add entries under >> node=testgio,dc=example,dc=com ? >> > to solve that issue it seems by this thread that you suggest giving > (proxy+all) access to proxyuser instead of the proxied one (uid=admin) > > imho this won''t fit, as every proxied user will be granted write access; while > the desired behaviour is to have the aci checked against uid=admin > > Am I wrong? >You should not have to allow the proxy user "all" access, only "proxy" access. The proxy user is not a "superuser". The access control should apply to the actual user.> Peace, > R. > > > > >
Roberto Polli
2009-Jul-23 16:59 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
On Thursday 23 July 2009 17:49:43 Rich Megginson wrote:> Roberto Polli wrote: > > hi all, > > > > I got similar problem with: dblink+proxyuser. > > > >> Rich Megginson wrote: > >>> Giovanni Mancuso wrote: > >>> Bu if i try to execute the ldapserach in first directory server i have > >>> the following error: proxy does not currently work with directory > >>> manager. Directory manager is considered a "local" user to each > >>> directory server. Try a different user. Now, i create a new user in > >>> first DS: > >> > >> By first DS do you mean the DS with the "real" database or the DS with > >> the database link? We also refer to the DS with the "real" database as > >> the "remote" DS and the DS with the database link as the "local" DS. > > > > case1) > > * I bind with uid=admin to the local DS tree to modify the "givenName" of > > a user on the remote server > > * the modify is successful, as the uid=admin is proxied and the > > "uid=admin" is replicated on the remote server > > > > case2) > > * same as case1 but I try to modify "userPassword" > > * the modify fails as the remote server won''t evaluate aci on "uid=admin" > > but on "dn:proxyuser" > > Is there an aci on the remote server that explicitly denies access to > userPassword? How about on the local server?nope: "deny" is never mentioned. nor in local and remote server # for i in "" "uid=pluto,node=isola3," "node=isola3,"; do ldapsearch .. -b "${i}dc=babel,dc=it" -s base aci done |grep -ci deny 0 acis on remote aci: (targetattr!="userPassword")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";) //INHERITED FROM BASEDN aci: (targetattr = "*") (version 3.0;acl "SA administration";allow (all)(roled n = "ldap:///cn=SA role,dc=babel,dc=it");) //INHERITED FROM BASEDN aci: (targetattr = "*") (target = "ldap:///node=isola3,dc=babel,dc=it") (versi on 3.0;acl "proxy3proxy";allow (proxy)(userdn = "ldap:///uid=proxyuser3,cn=co nfig");) // INHERITED FROM node=isola3 acis on remote are the same: aci: (targetattr!="userPassword")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";) //INHERITED FROM BASEDN aci: (targetattr = "*") (version 3.0;acl "SA administration";allow (all)(roled n = "ldap:///cn=SA role,dc=babel,dc=it");) //INHERITED FROM BASEDN> You should not have to allow the proxy user "all" access, only "proxy" > access. The proxy user is not a "superuser". The access control should > apply to the actual user.so proxy access should be able to change userPassword... do I have to set some custom settings in config (eg. plugins & co) Peace, R. -- Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 Tel. cel +39.340.6522736 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto della legge in materia di protezione dei dati personali."
Rich Megginson
2009-Jul-23 17:10 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
Roberto Polli wrote:> On Thursday 23 July 2009 17:49:43 Rich Megginson wrote: > >> Roberto Polli wrote: >> >>> hi all, >>> >>> I got similar problem with: dblink+proxyuser. >>> >>> >>>> Rich Megginson wrote: >>>> >>>>> Giovanni Mancuso wrote: >>>>> Bu if i try to execute the ldapserach in first directory server i have >>>>> the following error: proxy does not currently work with directory >>>>> manager. Directory manager is considered a "local" user to each >>>>> directory server. Try a different user. Now, i create a new user in >>>>> first DS: >>>>> >>>> By first DS do you mean the DS with the "real" database or the DS with >>>> the database link? We also refer to the DS with the "real" database as >>>> the "remote" DS and the DS with the database link as the "local" DS. >>>> >>> case1) >>> * I bind with uid=admin to the local DS tree to modify the "givenName" of >>> a user on the remote server >>> * the modify is successful, as the uid=admin is proxied and the >>> "uid=admin" is replicated on the remote server >>> >>> case2) >>> * same as case1 but I try to modify "userPassword" >>> * the modify fails as the remote server won''t evaluate aci on "uid=admin" >>> but on "dn:proxyuser" >>> >> Is there an aci on the remote server that explicitly denies access to >> userPassword? How about on the local server? >> > nope: "deny" is never mentioned. nor in local and remote server > > # for i in "" "uid=pluto,node=isola3," "node=isola3,"; do > ldapsearch .. -b "${i}dc=babel,dc=it" -s base aci > done |grep -ci deny > 0 > > acis on remote > > aci: (targetattr!="userPassword")(version 3.0; acl "Enable anonymous access"; > allow (read, search, compare) userdn="ldap:///anyone";) //INHERITED FROM > BASEDN > > aci: (targetattr = "*") (version 3.0;acl "SA administration";allow (all)(roled > n = "ldap:///cn=SA role,dc=babel,dc=it");) //INHERITED FROM BASEDN > > aci: (targetattr = "*") (target = "ldap:///node=isola3,dc=babel,dc=it") (versi > on 3.0;acl "proxy3proxy";allow (proxy)(userdn = "ldap:///uid=proxyuser3,cn=co > nfig");) // INHERITED FROM node=isola3 > > > > acis on remote are the same: > > aci: (targetattr!="userPassword")(version 3.0; acl "Enable anonymous access"; > allow (read, search, compare) userdn="ldap:///anyone";) //INHERITED FROM > BASEDN > > aci: (targetattr = "*") (version 3.0;acl "SA administration";allow (all)(roled > n = "ldap:///cn=SA role,dc=babel,dc=it");) //INHERITED FROM BASEDN > > > >> You should not have to allow the proxy user "all" access, only "proxy" >> access. The proxy user is not a "superuser". The access control should >> apply to the actual user. >> > so proxy access should be able to change userPassword... >Yes.> do I have to set some custom settings in config (eg. plugins & co) >So the user uid=admin - is that the Directory Manager (rootdn)? If not, is it a member of roledn = "ldap:///cn=SA role,dc=babel,dc=it"? Does roledn = "ldap:///cn=SA role,dc=babel,dc=it" exist on both the local and remote servers?> Peace, > R. > >
Roberto Polli
2009-Jul-23 17:28 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
On Thursday 23 July 2009 19:10:26 Rich Megginson wrote:> >>> case1)> >>> * I bind with uid=admin to the local DS tree to modify the "givenName" > >>> of a user on the remote server > >>> * the modify is successful, as the uid=admin is proxied and the > >>> "uid=admin" is replicated on the remote server > >>> > >>> case2) > >>> * same as case1 but I try to modify "userPassword" > >>> * the modify fails as the remote server won''t evaluate aci on > >>> "uid=admin" but on "dn:proxyuser" > >>> So the user uid=admin - is that the Directory Manager (rootdn)?no> If not, > is it a member of roledn = "ldap:///cn=SA role,dc=babel,dc=it"?yes, and it can modify users'' attribute, but password> Does roledn = "ldap:///cn=SA role,dc=babel,dc=it" exist on both the > local and remote servers?yes it seems that when I try to modify userPassword, the reference to uid=admin is not forwarded and only the proxyuser rights are used.. Peace, R. -- Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 Tel. cel +39.340.6522736 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto della legge in materia di protezione dei dati personali."
Rich Megginson
2009-Jul-23 18:02 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
Roberto Polli wrote:> On Thursday 23 July 2009 19:10:26 Rich Megginson wrote:> >>> case1) > >>>>> * I bind with uid=admin to the local DS tree to modify the "givenName" >>>>> of a user on the remote server >>>>> * the modify is successful, as the uid=admin is proxied and the >>>>> "uid=admin" is replicated on the remote server >>>>> >>>>> case2) >>>>> * same as case1 but I try to modify "userPassword" >>>>> * the modify fails as the remote server won''t evaluate aci on >>>>> "uid=admin" but on "dn:proxyuser" >>>>> > > >> So the user uid=admin - is that the Directory Manager (rootdn)? >> > no > > >> If not, >> is it a member of roledn = "ldap:///cn=SA role,dc=babel,dc=it"? >> > yes, and it can modify users'' attribute, but password > > >> Does roledn = "ldap:///cn=SA role,dc=babel,dc=it" exist on both the >> local and remote servers? >> > yes > > it seems that when I try to modify userPassword, the reference to uid=admin is > not forwarded and only the proxyuser rights are used.. >I suppose you could turn on ACL summary logging to see what''s going on. http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting> > Peace, > R. >
Roberto Polli
2009-Jul-29 14:11 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
Hi Rich, On Thursday 23 July 2009 20:02:37 Rich Megginson wrote:> > it seems that when I try to modify userPassword, the reference to > > uid=admin is not forwarded and only the proxyuser rights are used.. > > I suppose you could turn on ACL summary logging to see what''s going on. > http://directory.fedoraproject.org/wiki/FAQ#TroubleshootingI followed your suggestion, and I found that: 1) when I modify the givenName, the local server made a proxy auth using the local binddn. log states: NSACLPlugin - proxied authorization dn is (uid=u1,ou=serv ice administrators,dc=babel,dc=it) 2) when I modify the userPassword, the remote server states: NSACLPlugin - proxied authorization dn is () now I''m tcpdumping, but really strange old details down. Peace, R.> Roberto Polli wrote: > > On Thursday 23 July 2009 19:10:26 Rich Megginson wrote:> >>> case1) > > > >>>>> * I bind with uid=admin to the local DS tree to modify the > >>>>> "givenName" of a user on the remote server > >>>>> * the modify is successful, as the uid=admin is proxied and the > >>>>> "uid=admin" is replicated on the remote server > >>>>> > >>>>> case2) > >>>>> * same as case1 but I try to modify "userPassword" > >>>>> * the modify fails as the remote server won''t evaluate aci on > >>>>> "uid=admin" but on "dn:proxyuser" > >> > >> So the user uid=admin - is that the Directory Manager (rootdn)? > > no > >> is it a member of roledn = "ldap:///cn=SA role,dc=babel,dc=it"? > > yes, and it can modify users'' attribute, but password> >> Does roledn = "ldap:///cn=SA role,dc=babel,dc=it" exist on both the > >> local and remote servers? > > yes> > > > it seems that when I try to modify userPassword, the reference to > > uid=admin is not forwarded and only the proxyuser rights are used.. > > I suppose you could turn on ACL summary logging to see what''s going on. > http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting > > > Peace, > > R.-- Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 Tel. cel +39.340.6522736 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto della legge in materia di protezione dei dati personali."
Roberto Polli
2009-Jul-29 16:04 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
On Wednesday 29 July 2009 16:11:02 Roberto Polli wrote:> now I''m tcpdumping, but really strangetcpdump says the requests made by the local to the remote are almost identical both contains the user proxied (uid=admin) both contains the controls (proxy and loop detection) 2.16.840.1.113730.3.4.12 1.3.6.1.4.1.1466.29539.12 packages are: fedora-ds-1.1.2-1.fc6 fedora-ds-base-1.1.3-2.fc6 Peace, R.> > old details down. > Peace, > R. > > > Roberto Polli wrote: > > > On Thursday 23 July 2009 19:10:26 Rich Megginson wrote:> >>> case1) > > > > > >>>>> * I bind with uid=admin to the local DS tree to modify the > > >>>>> "givenName" of a user on the remote server > > >>>>> * the modify is successful, as the uid=admin is proxied and the > > >>>>> "uid=admin" is replicated on the remote server > > >>>>> > > >>>>> case2) > > >>>>> * same as case1 but I try to modify "userPassword" > > >>>>> * the modify fails as the remote server won''t evaluate aci on > > >>>>> "uid=admin" but on "dn:proxyuser" > > >> > > >> So the user uid=admin - is that the Directory Manager (rootdn)? > > > > > > no > > > > > >> is it a member of roledn = "ldap:///cn=SA role,dc=babel,dc=it"? > > > > > > yes, and it can modify users'' attribute, but password > > > > > >> Does roledn = "ldap:///cn=SA role,dc=babel,dc=it" exist on both the > > >> local and remote servers? > > > > > > yes > > > > > > > > > it seems that when I try to modify userPassword, the reference to > > > uid=admin is not forwarded and only the proxyuser rights are used.. > > > > I suppose you could turn on ACL summary logging to see what''s going on. > > http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting > > > > > Peace, > > > R.-- Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 Tel. cel +39.340.6522736 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto della legge in materia di protezione dei dati personali."
Rich Megginson
2009-Jul-29 16:09 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
Roberto Polli wrote:> On Wednesday 29 July 2009 16:11:02 Roberto Polli wrote: > >> now I''m tcpdumping, but really strange >> > tcpdump says the requests made by the local to the remote are almost identical > > both contains the user proxied (uid=admin) > both contains the controls (proxy and loop detection) > 2.16.840.1.113730.3.4.12 > 1.3.6.1.4.1.1466.29539.12 > > packages are: > fedora-ds-1.1.2-1.fc6 > fedora-ds-base-1.1.3-2.fc6 >Does this give any useful information? http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Configuring_Directory_Databases-Creating_and_Maintaining_Database_Links.html#Creating_and_Maintaining_Database_Links-Database_Links_and_Access_Control_Evaluation> > Peace, > R. > > >> old details down. >> Peace, >> R. >> >> >>> Roberto Polli wrote: >>> >>>> On Thursday 23 July 2009 19:10:26 Rich Megginson wrote:> >>> case1) >>>> >>>> >>>>>>>> * I bind with uid=admin to the local DS tree to modify the >>>>>>>> "givenName" of a user on the remote server >>>>>>>> * the modify is successful, as the uid=admin is proxied and the >>>>>>>> "uid=admin" is replicated on the remote server >>>>>>>> >>>>>>>> case2) >>>>>>>> * same as case1 but I try to modify "userPassword" >>>>>>>> * the modify fails as the remote server won''t evaluate aci on >>>>>>>> "uid=admin" but on "dn:proxyuser" >>>>>>>> >>>>> So the user uid=admin - is that the Directory Manager (rootdn)? >>>>> >>>> no >>>> >>>> >>>>> is it a member of roledn = "ldap:///cn=SA role,dc=babel,dc=it"? >>>>> >>>> yes, and it can modify users'' attribute, but password >>>> >>>> >>>>> Does roledn = "ldap:///cn=SA role,dc=babel,dc=it" exist on both the >>>>> local and remote servers? >>>>> >>>> yes >>>> >>>> >>>> it seems that when I try to modify userPassword, the reference to >>>> uid=admin is not forwarded and only the proxyuser rights are used.. >>>> >>> I suppose you could turn on ACL summary logging to see what''s going on. >>> http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting >>> >>> >>>> Peace, >>>> R. >>>> > >
Roberto Polli
2009-Jul-29 23:06 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
On Wednesday 29 July 2009 18:35:56 you wrote:> Roberto Polli wrote: > > On Wednesday 29 July 2009 18:09:17 Rich Megginson wrote: > >> Does this give any useful information? > >> http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Configuring_Directo > >>ry_ > >> Databases-Creating_and_Maintaining_Database_Links.html#Creating_and_Main > >>tain ing_Database_Links-Database_Links_and_Access_Control_Evaluation > > > > I read it more than once..made some slides too > > http://docs.google.com/present/view?id=dd4mpk7p_10366hxdsmn > > > > nonethless I may have made some mistake. > > > > what I didn''t understood is why - when updating userPassword - the remote > > server states that > > > >> NSACLPlugin - proxied authorization dn is () > > > > instead of > > > >> NSACLPlugin - proxied authorization dn is (uid=u1,ou=serv > >> ice administrators,dc=babel,dc=it) > > > > hope this could clarify a bit my problem.. >> Are you using the ldappasswd command to update the password?ldapmodify: dn: uid=pippo,dc=example,dc=com changetype: modify replace: userPassword userPassword: pippo1242102d32d322d8321p8enxnc093212190cx321> You may have to allow that component to chain. > http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Configuring_Directo >ry_Databases-Creating_and_Maintaining_Database_Links.html#Configuring_the_Ch >aining_Policy-Chaining_Component_OperationsEven if I don''t use SASL, anyway I enabled chaining of PasswordPolicy controls, but nothing changes. .. but..is it right that in aclplugin.c the function acl_get_proxyauth_dn( pb, &proxy_dn, &errtext ) returns proxy_dn = "" ? Peace, R. -- Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 Tel. cel +39.340.6522736 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto della legge in materia di protezione dei dati personali."
Rich Megginson
2009-Jul-29 23:15 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
Roberto Polli wrote:> On Wednesday 29 July 2009 18:35:56 you wrote: > >> Roberto Polli wrote: >> >>> On Wednesday 29 July 2009 18:09:17 Rich Megginson wrote: >>> >>>> Does this give any useful information? >>>> http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Configuring_Directo >>>> ry_ >>>> Databases-Creating_and_Maintaining_Database_Links.html#Creating_and_Main >>>> tain ing_Database_Links-Database_Links_and_Access_Control_Evaluation >>>> >>> I read it more than once..made some slides too >>> http://docs.google.com/present/view?id=dd4mpk7p_10366hxdsmn >>> >>> nonethless I may have made some mistake. >>> >>> what I didn''t understood is why - when updating userPassword - the remote >>> server states that >>> >>> >>>> NSACLPlugin - proxied authorization dn is () >>>> >>> instead of >>> >>> >>>> NSACLPlugin - proxied authorization dn is (uid=u1,ou=serv >>>> ice administrators,dc=babel,dc=it) >>>> >>> hope this could clarify a bit my problem.. >>> > > >> Are you using the ldappasswd command to update the password? >> > ldapmodify: > dn: uid=pippo,dc=example,dc=com > changetype: modify > replace: userPassword > userPassword: pippo1242102d32d322d8321p8enxnc093212190cx321 > > > >> You may have to allow that component to chain. >> http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Configuring_Directo >> ry_Databases-Creating_and_Maintaining_Database_Links.html#Configuring_the_Ch >> aining_Policy-Chaining_Component_Operations >> > > Even if I don''t use SASL, anyway I enabled chaining of PasswordPolicy > controls, but nothing changes. > .. > > but..is it right that in aclplugin.c the function > acl_get_proxyauth_dn( pb, &proxy_dn, &errtext ) > returns proxy_dn = "" ? >It is if there is no proxy auth control being sent.> Peace, > R. >
Roberto Polli
2009-Jul-29 23:28 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
On Thursday 30 July 2009 01:15:00 Rich Megginson wrote:> > but..is it right that in aclplugin.c the function > > acl_get_proxyauth_dn( pb, &proxy_dn, &errtext ) > > returns proxy_dn = "" ? > > It is if there is no proxy auth control being sent.but tcpdump states it''s sent... Peace, R. -- Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 Tel. cel +39.340.6522736 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto della legge in materia di protezione dei dati personali."
Rich Megginson
2009-Jul-29 23:36 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
Roberto Polli wrote:> On Thursday 30 July 2009 01:15:00 Rich Megginson wrote: > >>> but..is it right that in aclplugin.c the function >>> acl_get_proxyauth_dn( pb, &proxy_dn, &errtext ) >>> returns proxy_dn = "" ? >>> >> It is if there is no proxy auth control being sent. >> > but tcpdump states it''s sent... >Without walking through the server with the debugger, it''s going to be difficult to tell what''s going on. The function acl_get_proxyauth_dn() is pretty straightforward - look at the request controls, see if version 1 or version 2 of the proxy auth control was sent, if so, grab the DN from the control value. There is no obvious place in the code where acl_get_proxyauth_dn() would be called conditionally (that is, not called due to some condition). So I''m at a loss to explain how acl_get_proxyauth_dn() could be called at all, with a valid proxy auth control containing a non-empty DN value, and return a NULL or empty DN.> Peace, > R. >
Roberto Polli
2009-Jul-29 23:41 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
On Thursday 30 July 2009 01:36:15 Rich Megginson wrote:> Roberto Polli wrote: > > On Thursday 30 July 2009 01:15:00 Rich Megginson wrote: > >>> but..is it right that in aclplugin.c the function > >>> acl_get_proxyauth_dn( pb, &proxy_dn, &errtext ) > >>> returns proxy_dn = "" ? > >> > >> It is if there is no proxy auth control being sent. > > > > but tcpdump states it''s sent... > > Without walking through the server with the debugger, it''s going to be > difficult to tell what''s going on.it''s the whole day I''m trying that way ;) hope to discover something.. I should set thread to 1 to use gdb against slapd> The function acl_get_proxyauth_dn() > is pretty straightforward - look at the request controls, see if version > 1 or version 2 of the proxy auth control was sent,ok> if so, grab the DN > from the control value. There is no obvious place in the code where > acl_get_proxyauth_dn() would be called conditionally (that is, not > called due to some condition).ok> So I''m at a loss to explain how > acl_get_proxyauth_dn() could be called at all, with a valid proxy auth > control containing a non-empty DN value, and return a NULL or empty DN.Thats a nice answer :P I''ll continue to play with it..just hope not to be silly enough to have some mistake in configs. Maybe it''s worth an rpm -U of the server... Rich, thank you very much for all your prompt replies. I''ll let you know. Thanks again + Peace, R. -- Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 Tel. cel +39.340.6522736 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto della legge in materia di protezione dei dati personali."
Roberto Polli
2009-Jul-31 15:44 UTC
Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem
just another failing test, to be sure it''s a remote server issue: #ldapmodify -D "uid=tproxy,cn=config" -w -Y "dn:uid=u1..." -f /root/pippo.password.ldif ldap_modify: Insufficient access # dapmodify -D "uid=tproxy,cn=config" -w -Y "dn:uid=u1..." -f /root/pippo.givenName.ldif modifying entry uid=pippo,dc=example,dc=com logs state: NSACLPlugin - #### conn=11 op=1 binddn="uid=tproxy,cn=config" instead of: NSACLPlugin - proxied authorization dn is (uid=u1,ou=Service Administrators,dc=babel,dc=it) NSACLPlugin - #### conn=12 op=1 binddn="uid=tproxy,cn=config" Peace, R -- Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 Tel. cel +39.340.6522736 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto della legge in materia di protezione dei dati personali."