Re: ppolicy in back_ldap?

[Tyler Gates <tjgates@castlebranch.com>]

On 04/22/2010 11:38 AM, masarati@aero.polimi.it wrote:
>> Hey guys,
>>     
> Hi.  What version?  Also, I's not clear (to me) whether you're configuring
> slapo-ppolicy also on the proxy.  If this is the case, I think you're not
> doing the right thing.
>   
2.4.18
I have ppolicy setup on both masters as well as the proxy (as an overlay
to back_ldap) because it was the only way I could see the values from
the masters when queries where made to proxy (which I need to be able to
do).
>   
>>        I currently have a multi-master system setup with a back_ldap
>> proxying frontend. We are using ppolicy and it is loaded fine and
>> works on the two masters but I'm experiencing a little weirdness on
>> the proxy side. It works fine but when I implemented password
>> expirations the other day I keep seeing messages on the proxy like:
>> ppolicy_bind: Setting warning for password expiry for .... = 0 seconds
>> These entries should not be receiving any warning messages and I know
>> my settings are correct because if I redirect to one of the masters
>> the log output is what I expect. Also, if I run a perl script that
>> uses password policy controls and look for time_before_expiration, the
>> value is always 0 on the proxy while it is not even set if
>> pwdExpireWarning is not met or a sane value if it is on the masters.
>>
>> After reading slapo-ppolicy it looks like maybe I should be setting
>> olcPPolicyForwardUpdates to TRUE (?) and set a olcupdateRef in
>> olcDatabase={1}ldap,cn=config to both masters but it spits at me every
>> time I try it.
>>     
> olcUpdateRef only makes sense when the database is shadow - i.e. it also
> contains a olcSyncrepl directive.  The indications above make sense when
> slapo-ppolicy is on a shadow database; you're trying to use them on a
> proxy, which is usually not a shadow.
>
>   
>> It also says a chain overlay should be set as well but
>> when I read slapo-chain its says: "It is useless in conjunction with
>> the slapd-ldap and slapd-meta backends because they already exploit
>> the libldap specific referral chase feature."
>>     
> This indication makes sense: slapo-chain uses libldap calls, which can be
> configured to automatically handle referrals.  However, in general,
> slapo-chain can be used instead of the built-in referral chase
> capabilities, because it allows finer grain control on what identity is
> used/propagated during referral chasing.  But this should be outside the
> scope of your issue.
>
>   
>> If I remove ppolicy overlay I don't see any of the values.
>>     
> Please clarify: what do you mean by "I don't see any of the values"?  I0ve
> checked with HEAD code, and I've noticed that indeed ppolicy control
> responses don't get propagated from a remote DSA through the proxy.  Is
> this what you mean?  I'm filing an ITS about this.  Actually, I think the
> reason is related to ITS#6166 (Followup 1); however, we need to fix it now
> rather than wait for that fix.
>   
That is exactly what I mean - pwd* and friends attributes from ppolicy 
do not get propegated to the proxy utilitzing back_ldap. The only way I
could get them was by adding the overlay to back_ldap on the proxy
itself but as I explained earlier its not processing pwdExpireWarning
times correctly.
Thank you for filing the ITS. Would you mind letting us know the number
on that once you create it? I cannot find anything currently. Also, I
cannot find ITS#6166 either. Can you double check that number?
>   
>> I need the proxy to be able to see these attributes (as in those
>> making queries to it) and not hammer my logs with incorrect messages.
>> Is it possible to make this work, am I doing some wrong?
>>     
> I know I didn't answer your question, but I need a clearer description of
> what you're trying to accomplish.  And there seems to be an issue related
> to slapd-ldap behavior when control responses are to be returned during a
> bind.
>
> p.
>
>   
Hopefully my previous responses above clarified that. Thank you for
filing the ITS.
  Tyler

-- 

Tyler Gates
Systems Administrator
Castle Branch Inc.
910-815-3880 ext 7230
tjgates@castlebranch.com

This e-mail message, including any attachments, may contain private,
confidential, and privileged information for the restricted use of the
intended recipient(s). If you are not the intended recipient(s), you
may NOT use, disclose, copy, or disseminate this information. Please
notify the sender by return e-mail of this misdirected correspondence
and destroy all copies of the original message including all attachments.
Your cooperation is appreciated.