openldap-bugs February 2011

openldap-bugs@openldap.org

35 participants
158 discussions

Re: (ITS#6823) unknown attrs in pcache attrsets may be useful
by hyc＠symas.com 02 Feb '11

02 Feb '11

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2.40.14.92) > Submitted by: ando > > > Currently attributes in pcache attrsets must be defined. As far as I recall > this was introduced to catch misconfigurations (e.g. a typo would have silently > resulted in erroneous caching). However, one may wish to cache attrs whose > schema is not known. I've modified pcache to allow undef:attrname in attrsets, > so the administrator needs to know what he's doing. The "undef:" is stripped > during parsing, but slapd will not complain and the administrator. I think this is a mistake. Anything slapd handles must have a defined schema. Probably the recent patches for back-ldap to support undefined filters are also a mistake. We have already documented that schema must be provided in order to get proper functioning of e.g. back-ldap. There is no reason to relax this requirement since one can always obtain the relevant schema from the target server. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6823) unknown attrs in pcache attrsets may be useful
by masarati＠aero.polimi.it 02 Feb '11

02 Feb '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.14.92) Submitted by: ando Currently attributes in pcache attrsets must be defined. As far as I recall this was introduced to catch misconfigurations (e.g. a typo would have silently resulted in erroneous caching). However, one may wish to cache attrs whose schema is not known. I've modified pcache to allow undef:attrname in attrsets, so the administrator needs to know what he's doing. The "undef:" is stripped during parsing, but slapd will not complain and the administrator. p.

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 02 Feb '11

02 Feb '11

hyc(a)symas.com wrote: > masarati(a)aero.polimi.it wrote: >>>>> The way I read this, it seems to imply that if acl-bind is not set, the >>>>> identity specified by idassert-bind will be used -- which is clearly >>>>> not >>>>> happening here. Am I misreading this, or do you think the wording >>>>> should >>>>> be changed here? >>>> >>>> As far as I remember, the above is (or was) true in some cases (which I >>>> do >>>> not remember); in any case, the above statement is in contradiction with >>>> Howard's statement. Either the behavior stated above should be >>>> generalized (if desirable, in order to avoid the need to configure >>>> things >>>> twice when the same identity is going to be used), or the two should be >>>> decoupled everywhere in the code. >>> >>> The current code in ldap_back_prepare_conn: >>> >>> >>>> >>> #ifdef HAVE_TLS >>> if ( LDAP_BACK_CONN_ISPRIV( lc ) ) { >>> sb =&li->li_acl; >>> >>> } else if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { >>> sb =&li->li_idassert.si_bc; >>> >>> } else { >>> sb =&li->li_tls; >>> } >>> >>> if ( sb->sb_tls_do_init ) { >>> bindconf_tls_set( sb, ld ); >>> } else if ( sb->sb_tls_ctx ) { >>> ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); >>> } >>> >>> /* if required by the bindconf configuration, force TLS */ >>> if ( ( sb ==&li->li_acl || sb ==&li->li_idassert.si_bc )&& >>> sb->sb_tls_ctx ) >>> { >>> flags |= LDAP_BACK_F_USE_TLS; >>> } >>> <<<< >>> >>> It seems the initial if/else belongs outside the #ifdef, first of all. Not >>> sure how to handle the fallback to li->li_tls. >> >> Uh, no, that's fine: sb is only used to decide whether and how to start >> TLS, as far as I understand, so the #ifdef is fine. li_tls is only about >> configuring TLS for regular connections, which could be different from >> that of li_acl and li_idassert (and in any case one may want to configure >> TLS without configuring li_acl nor li_idassert. > > OK. The error I saw before was that TLS was started without the CA cert being > configured, and that's because at this point, li->li_acl was used but only > li->li_idassert had any TLS configuration. I've patched this now to also use > li->li_idassert if li_acl was not configured. > >> Later, in ldap_back_getconn(), there's some code that either uses li_acl >> or li_idassert; however, in ldap_back_dobind_int(), private connections >> only use li_acl for private connections when SASL is configured. Probably >> here we should use either li_acl or li_idassert if defined. > > Yeah, that sounds right. OK, will look into this. Corresponding changes made, but the entire body of code here needs some review. There's quite a bit of duplication of effort, compared to slap_client_connect(). Can we strip most of this out? Why does the privileged connection code not use the sb_authzID on the SASL bind, it always uses NULL instead? There are a lot more parameters supported by the bindconf mechanism, which the config parser will accept here (e.g. related to timeouts) that will not get used because slap_client_connect() is not being used. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 02 Feb '11

02 Feb '11

masarati(a)aero.polimi.it wrote: >>>> The way I read this, it seems to imply that if acl-bind is not set, the >>>> identity specified by idassert-bind will be used -- which is clearly >>>> not >>>> happening here. Am I misreading this, or do you think the wording >>>> should >>>> be changed here? >>> >>> As far as I remember, the above is (or was) true in some cases (which I >>> do >>> not remember); in any case, the above statement is in contradiction with >>> Howard's statement. Either the behavior stated above should be >>> generalized (if desirable, in order to avoid the need to configure >>> things >>> twice when the same identity is going to be used), or the two should be >>> decoupled everywhere in the code. >> >> The current code in ldap_back_prepare_conn: >> >> >>>> >> #ifdef HAVE_TLS >> if ( LDAP_BACK_CONN_ISPRIV( lc ) ) { >> sb =&li->li_acl; >> >> } else if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { >> sb =&li->li_idassert.si_bc; >> >> } else { >> sb =&li->li_tls; >> } >> >> if ( sb->sb_tls_do_init ) { >> bindconf_tls_set( sb, ld ); >> } else if ( sb->sb_tls_ctx ) { >> ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); >> } >> >> /* if required by the bindconf configuration, force TLS */ >> if ( ( sb ==&li->li_acl || sb ==&li->li_idassert.si_bc )&& >> sb->sb_tls_ctx ) >> { >> flags |= LDAP_BACK_F_USE_TLS; >> } >> <<<< >> >> It seems the initial if/else belongs outside the #ifdef, first of all. Not >> sure how to handle the fallback to li->li_tls. > > Uh, no, that's fine: sb is only used to decide whether and how to start > TLS, as far as I understand, so the #ifdef is fine. li_tls is only about > configuring TLS for regular connections, which could be different from > that of li_acl and li_idassert (and in any case one may want to configure > TLS without configuring li_acl nor li_idassert. OK. The error I saw before was that TLS was started without the CA cert being configured, and that's because at this point, li->li_acl was used but only li->li_idassert had any TLS configuration. I've patched this now to also use li->li_idassert if li_acl was not configured. > Later, in ldap_back_getconn(), there's some code that either uses li_acl > or li_idassert; however, in ldap_back_dobind_int(), private connections > only use li_acl for private connections when SASL is configured. Probably > here we should use either li_acl or li_idassert if defined. Yeah, that sounds right. OK, will look into this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6822) overlays on cn=config break back-config's default acl
by Ralf Haferkamp 02 Feb '11

02 Feb '11

Fix is in servers/slapd/bconfig.c r1.423

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by masarati＠aero.polimi.it 02 Feb '11

02 Feb '11

>>> The way I read this, it seems to imply that if acl-bind is not set, the >>> identity specified by idassert-bind will be used -- which is clearly >>> not >>> happening here. Am I misreading this, or do you think the wording >>> should >>> be changed here? >> >> As far as I remember, the above is (or was) true in some cases (which I >> do >> not remember); in any case, the above statement is in contradiction with >> Howard's statement. Either the behavior stated above should be >> generalized (if desirable, in order to avoid the need to configure >> things >> twice when the same identity is going to be used), or the two should be >> decoupled everywhere in the code. > > The current code in ldap_back_prepare_conn: > > >>>> > #ifdef HAVE_TLS > if ( LDAP_BACK_CONN_ISPRIV( lc ) ) { > sb = &li->li_acl; > > } else if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { > sb = &li->li_idassert.si_bc; > > } else { > sb = &li->li_tls; > } > > if ( sb->sb_tls_do_init ) { > bindconf_tls_set( sb, ld ); > } else if ( sb->sb_tls_ctx ) { > ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); > } > > /* if required by the bindconf configuration, force TLS */ > if ( ( sb == &li->li_acl || sb == &li->li_idassert.si_bc ) && > sb->sb_tls_ctx ) > { > flags |= LDAP_BACK_F_USE_TLS; > } > <<<< > > It seems the initial if/else belongs outside the #ifdef, first of all. Not > sure how to handle the fallback to li->li_tls. Uh, no, that's fine: sb is only used to decide whether and how to start TLS, as far as I understand, so the #ifdef is fine. li_tls is only about configuring TLS for regular connections, which could be different from that of li_acl and li_idassert (and in any case one may want to configure TLS without configuring li_acl nor li_idassert. Later, in ldap_back_getconn(), there's some code that either uses li_acl or li_idassert; however, in ldap_back_dobind_int(), private connections only use li_acl for private connections when SASL is configured. Probably here we should use either li_acl or li_idassert if defined. p.

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 02 Feb '11

02 Feb '11

>> The way I read this, it seems to imply that if acl-bind is not set, the >> identity specified by idassert-bind will be used -- which is clearly not >> happening here. Am I misreading this, or do you think the wording should >> be changed here? > > As far as I remember, the above is (or was) true in some cases (which I do > not remember); in any case, the above statement is in contradiction with > Howard's statement. Either the behavior stated above should be > generalized (if desirable, in order to avoid the need to configure things > twice when the same identity is going to be used), or the two should be > decoupled everywhere in the code. The current code in ldap_back_prepare_conn: >>>> #ifdef HAVE_TLS if ( LDAP_BACK_CONN_ISPRIV( lc ) ) { sb = &li->li_acl; } else if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { sb = &li->li_idassert.si_bc; } else { sb = &li->li_tls; } if ( sb->sb_tls_do_init ) { bindconf_tls_set( sb, ld ); } else if ( sb->sb_tls_ctx ) { ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); } /* if required by the bindconf configuration, force TLS */ if ( ( sb == &li->li_acl || sb == &li->li_idassert.si_bc ) && sb->sb_tls_ctx ) { flags |= LDAP_BACK_F_USE_TLS; } <<<< It seems the initial if/else belongs outside the #ifdef, first of all. Not sure how to handle the fallback to li->li_tls. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org 02 Feb '11

02 Feb '11

This is a multi-part message in MIME format. --------------060105070408050605050000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> Another problem is that bind operations to the consumer server start to >> return two result messages -- one with the error code of the chained >> operation, and one with the error code of the bind operation. I'm continuing to see this problem, even after I fix the acl-bind and the 'manage' ACL configuration. See the attached for an updated test script that illustrates the problem -- I've added a bind with an incorrect password which should return 49, but instead is returning 0 to the client. The last line of output from the test script is: ldap bind operation returned 0, expected 49 For the relevant operation in slapd.2.log, I see the following: conn=1003 op=0 RESULT tag=103 err=0 text= [...] conn=1003 op=0 RESULT tag=97 err=49 text= slapd is returning two RESULT messages for the BIND operation. Error 0 seems to be from the successful chained modification of the pwdFailureTime attribute, and Error 49 seems to be for the incorrect password. -Kartik --------------060105070408050605050000 Content-Type: text/plain; name="test099-ppolicy-update" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="test099-ppolicy-update" #! /bin/sh # $OpenLDAP: pkg/ldap/tests/scripts/test022-ppolicy,v 1.17.2.9 2010/04/13 20:24:03 kurt Exp $ ## This work is part of OpenLDAP Software <http://www.openldap.org/>. ## ## Copyright 1998-2010 The OpenLDAP Foundation. ## All rights reserved. ## ## Redistribution and use in source and binary forms, with or without ## modification, are permitted only as authorized by the OpenLDAP ## Public License. ## ## A copy of this license is available in the file LICENSE in the ## top-level directory of the distribution or, alternatively, at ## <http://www.OpenLDAP.org/license.html>. echo "running defines.sh" . $SRCDIR/scripts/defines.sh if test $PPOLICY = ppolicyno; then echo "Password policy overlay not available, test skipped" exit 0 fi mkdir -p $TESTDIR $DBDIR1 $SLAPPASSWD -g -n >$CONFIGPWF echo "rootpw `$SLAPPASSWD -T $CONFIGPWF`" >$TESTDIR/configpw.conf echo "Starting slapd on TCP/IP port $PORT1..." . $CONFFILTER $BACKEND $MONITORDB < $PPOLICYCONF > $CONF1 $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 & PID=$! if test $WAIT != 0 ; then echo PID $PID read foo fi KILLPIDS="$PID" USER="uid=nd, ou=People, dc=example, dc=com" PASS=testpassword sleep 1 echo "Using ldapsearch to check that slapd is running..." for i in 0 1 2 3 4 5; do $LDAPSEARCH -s base -b "$MONITOR" -h $LOCALHOST -p $PORT1 \ 'objectclass=*' > /dev/null 2>&1 RC=$? if test $RC = 0 ; then break fi echo "Waiting 5 seconds for slapd to start..." sleep 5 done if test $RC != 0 ; then echo "ldapsearch failed ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi echo /dev/null > $TESTOUT echo "Using ldapadd to populate the database..." # may need "-e relax" for draft 09, but not yet. $LDAPADD -D "$MANAGERDN" -h $LOCALHOST -p $PORT1 -w $PASSWD < \ $LDIFPPOLICY >> $TESTOUT 2>&1 RC=$? if test $RC != 0 ; then echo "ldapadd failed ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi if test "$BACKLDAP" != "ldapno" && test "$SYNCPROV" != "syncprovno" ; then echo "" echo "Setting up policy state forwarding test..." mkdir $DBDIR2 sed -e "s,$DBDIR1,$DBDIR2," < $CONF1 > $CONF2 echo "Starting slapd consumer on TCP/IP port $PORT2..." $SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING > $LOG2 2>&1 & PID=$! if test $WAIT != 0 ; then echo PID $PID read foo fi KILLPIDS="$KILLPIDS $PID" echo "Configuring syncprov on provider..." if [ "$SYNCPROV" = syncprovmod ]; then $LDAPADD -D cn=config -H $URI1 -y $CONFIGPWF <<EOF >> $TESTOUT 2>&1 dn: cn=module,cn=config objectclass: olcModuleList cn: module olcModulePath: $TESTWD/../servers/slapd/overlays olcModuleLoad: syncprov.la EOF RC=$? if test $RC != 0 ; then echo "ldapadd failed for moduleLoad ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi fi $LDAPADD -D cn=config -H $URI1 -y $CONFIGPWF <<EOF >> $TESTOUT 2>&1 dn: olcOverlay={1}syncprov,olcDatabase={1}$BACKEND,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov EOF RC=$? if test $RC != 0 ; then echo "ldapadd failed for provider database config ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi echo "Using ldapsearch to check that slapd is running..." for i in 0 1 2 3 4 5; do $LDAPSEARCH -s base -b "$MONITOR" -H $URI2 \ 'objectclass=*' > /dev/null 2>&1 RC=$? if test $RC = 0 ; then break fi echo "Waiting 5 seconds for slapd to start..." sleep 5 done if test $RC != 0 ; then echo "ldapsearch failed ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi echo "Configuring syncrepl on consumer..." if [ "$BACKLDAP" = ldapmod ]; then $LDAPADD -D cn=config -H $URI2 -y $CONFIGPWF <<EOF >> $TESTOUT 2>&1 dn: cn=module,cn=config objectclass: olcModuleList cn: module olcModulePath: $TESTWD/../servers/slapd/back-ldap olcModuleLoad: back_ldap.la EOF RC=$? if test $RC != 0 ; then echo "ldapadd failed for moduleLoad ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi fi $LDAPMODIFY -D cn=config -H $URI2 -y $CONFIGPWF <<EOF >> $TESTOUT 2>&1 dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainReturnError: TRUE dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDBURI: $URI1 olcDBStartTLS: start olcDBIDAssertBind: mode=none bindmethod=sasl saslmech=EXTERNAL tls_cert=$DATADIR/localhost.crt tls_key=$DATADIR/localhost.key tls_cacert=$DATADIR/localhost.crt tls_reqcert=never olcDBIDAssertAuthzFrom: * olcDBACLBind: bindmethod=sasl saslmech=EXTERNAL tls_cert=$DATADIR/localhost.crt tls_key=$DATADIR/localhost.key tls_cacert=$DATADIR/localhost.crt tls_reqcert=never dn: olcDatabase={1}$BACKEND,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=1 provider=$URI1 starttls=yes bindmethod=sasl saslmech=EXTERNAL tls_key=$DATADIR/localhost.key tls_cert=$DATADIR/localhost.crt tls_cacert=$DATADIR/localhost.crt tls_reqcert=never tls_crlcheck=none searchbase="dc=example,dc=com" type=refreshAndPersist retry="3 5 300 5" - add: olcUpdateref olcUpdateref: $URI1 - dn: olcOverlay={0}ppolicy,olcDatabase={1}$BACKEND,cn=config changetype: modify replace: olcPPolicyForwardUpdates olcPPolicyForwardUpdates: TRUE - EOF RC=$? if test $RC != 0 ; then echo "ldapmodify failed ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi echo "Waiting for consumer to sync..." sleep $SLEEP1 echo "Testing policy state forwarding..." $LDAPSEARCH -H $URI2 -D "$USER" -w wrongpw >$SEARCHOUT 2>&1 if test $? != 49; then echo "ldap bind operation returned $?, expected 49" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit 1 fi $LDAPSEARCH -H $URI1 -D "$MANAGERDN" -w $PASSWD -b "$USER" \* \+ >> $SEARCHOUT 2>&1 COUNT=`grep "pwdFailureTime" $SEARCHOUT | wc -l` if test $COUNT != 1 ; then echo "Policy state forwarding failed" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit 1 fi # End of chaining test fi test $KILLSERVERS != no && kill -HUP $KILLPIDS echo ">>>>> Test succeeded" test $KILLSERVERS != no && wait exit 0 --------------060105070408050605050000--

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by masarati＠aero.polimi.it 02 Feb '11

02 Feb '11

> On 02/01/2011 04:25 PM, Howard Chu wrote: >> 1) since ppolicy uses the database rootdn to perform the pwdFailuretime >> update, this is considered a privileged connection. Note from the >> slapd-ldap(5) manpage that acl-bind is used for root/privileged >> connections. Your idassert-bind directive had no effect here. The TLS >> session failed because the acl-bind context had no CA cert configured. >> Adding an appropriate olcDbACLBind directive got past this issue. > > Ahh, this is a key point that I was missing, thanks for the > explanation!! (I still have a problem, but I'll continue that in a > separate message) > > FYI though, in slapd-ldap(5), the acl-bind section states the following: > > ===== > The default is to use simple bind, with empty binddn and credentials, > which means that the related operations will be performed anonymously. > If not set, and if idassert-bind is defined, this latter identity is > used instead. See idassert-bind for details. > ===== > > The way I read this, it seems to imply that if acl-bind is not set, the > identity specified by idassert-bind will be used -- which is clearly not > happening here. Am I misreading this, or do you think the wording should > be changed here? As far as I remember, the above is (or was) true in some cases (which I do not remember); in any case, the above statement is in contradiction with Howard's statement. Either the behavior stated above should be generalized (if desirable, in order to avoid the need to configure things twice when the same identity is going to be used), or the two should be decoupled everywhere in the code. p. > Also, do you think it might be helpful to add the following kind of > language to the ppolicy_forward_updates section of the slapo-ppolicy man > page. I know others have had the same confusion that I have had on this > general area, so this might save them a lot of time: > > ===== > Make sure to grant the "manage" ACL privilege to the pwdFailureTime and > pwdAccountLockedTime attributes on the master server. Also, since a > privileged connection is used, the acl-bind directive needs to be > properly configured in the chain overlay. > ===== > >> 2) since pwdFailuretime is an operational attribute, you need to have >> manage privilege to update it. With (1) fixed the modify is correctly >> chained to the provider, but the provider rejects it with Insufficient >> Access. Changing the ACL in slapd-ppolicy.conf to grant "manage' instead >> of "write" access fixes that. With both of those corrections, your test >> script succeeds. Closing this ITS as user config error, there is no >> software bug here. > > Yep. I actually had set this properly in my real environment, I just > neglected to include it in the test file. > > Thanks, > > -Kartik > > > >

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org 02 Feb '11

02 Feb '11

On 02/01/2011 04:25 PM, Howard Chu wrote: > 1) since ppolicy uses the database rootdn to perform the pwdFailuretime > update, this is considered a privileged connection. Note from the > slapd-ldap(5) manpage that acl-bind is used for root/privileged > connections. Your idassert-bind directive had no effect here. The TLS > session failed because the acl-bind context had no CA cert configured. > Adding an appropriate olcDbACLBind directive got past this issue. Ahh, this is a key point that I was missing, thanks for the explanation!! (I still have a problem, but I'll continue that in a separate message) FYI though, in slapd-ldap(5), the acl-bind section states the following: ===== The default is to use simple bind, with empty binddn and credentials, which means that the related operations will be performed anonymously. If not set, and if idassert-bind is defined, this latter identity is used instead. See idassert-bind for details. ===== The way I read this, it seems to imply that if acl-bind is not set, the identity specified by idassert-bind will be used -- which is clearly not happening here. Am I misreading this, or do you think the wording should be changed here? Also, do you think it might be helpful to add the following kind of language to the ppolicy_forward_updates section of the slapo-ppolicy man page. I know others have had the same confusion that I have had on this general area, so this might save them a lot of time: ===== Make sure to grant the "manage" ACL privilege to the pwdFailureTime and pwdAccountLockedTime attributes on the master server. Also, since a privileged connection is used, the acl-bind directive needs to be properly configured in the chain overlay. ===== > 2) since pwdFailuretime is an operational attribute, you need to have > manage privilege to update it. With (1) fixed the modify is correctly > chained to the provider, but the provider rejects it with Insufficient > Access. Changing the ACL in slapd-ppolicy.conf to grant "manage' instead > of "write" access fixes that. With both of those corrections, your test > script succeeds. Closing this ITS as user config error, there is no > software bug here. Yep. I actually had set this properly in my real environment, I just neglected to include it in the test file. Thanks, -Kartik

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2011