Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth

[subbarao@computer.org]

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