thr3ads.net - Fedora directory users - [389-users] Chaining and LDAP_UNWILLING_TO

If this information is useful, please help other people find it:
Share via:

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

head link

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

head link

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 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:

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

head link

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

head link

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

head link

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

head link

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

head link

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

head link

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

head link

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

head link

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

head link

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

head link

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

head link

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_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 = "" ?

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

head link

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

head link

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

head link

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

head link

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

head link

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."

Fedora directory users - Jul 2009 - [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

[389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem

Re: [389-users] Chaining and LDAP_UNWILLING_TO_PERFORM problem