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