[Date Prev][Date Next]
Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
- From: firstname.lastname@example.org
- Date: Wed, 2 Feb 2011 16:36:15 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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
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.