Re: ppolicy in back_ldap?

[masarati@aero.polimi.it]

>
>
> 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).

Not sure what you mean by "see"; do you mean they be returned in search
requests?  This, from a proxy standpoint, should not be an issue, as they
are treated much like any other attribute.  Did you load ppolicy.schema on
the proxy server?  Do ACLs allow to return them?  Are you explicitly
requesting operational attributes?

>>
>>>        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?

<http://www.openldap.org/its/?findid=6530>; fixed in HEAD; you should be
able to pull out back-ldap/bind.c 1.258 -> 1.259; I'm not sure it applies
straightforward to 2.4.18, though.

> I cannot find anything currently. Also, I
> cannot find ITS#6166 either. Can you double check that number?

<http://www.openldap.org/its/?findid=6166>

>>> 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.

p.