RE: [ldapext] Returning the Password Policy Control

["Steven Legg" <steven.legg@adacel.com.au>]

John,

John McMeeking wrote:
> If there is a subtreespecification associated with the password policy
> [sub]entry, it could be challenging determining whether a given policy
> applies to a specific entry.  For example, an entry could
> fall within a
> governed subtree, but not match the filter or other component of the
> subtree specification.  The question of whether a subtree
> specification
> applies to an entry is a general problem.

I have been using subtree specifications for a long time and haven't
found them to be challenging. Given an entry's DN and object class it
is a straightforward test to decide if the entry is within the specified
subtree.

Regards,
Steven

> It might be
> appropriate to have
> password policy define the passwordPolicySubentry attribute, and have
> something like the subentry draft define an extended
> operation to determine
> if a given subentry applies to a given entry.
>
>
> John  McMeeking
>
>
>
>
>
>                       "Andrew
>
>                       Sciberras"               To:
> "'Jim Sermersheim'" <jimse@novell.com>
>                       <andrews@adacel.c        cc:
> "Ldapext \(E-mail\)" <ldapext@ietf.org>
>                       om.au>                   Subject:  RE:
> [ldapext] Returning the Password Policy Control
>                       Sent by:
>
>                       ldapext-admin@iet
>
>                       f.org
>
>
>
>
>
>                       09/03/2003 07:15
>
>                       PM
>
>                       Please respond to
>
>                       andrews
>
>
>
>
>
>
>
>
>
>
> G'Day,
>
> Take a look at the scenario of a bound entity  changing their own
> userPassword and including a passwordPolicyRequest control in  the
> LDAPMessage. (Where a passwordPolicy is in place for the userPassword
> attribute).
> By following the steps described in 6.2, if  the operation
> succeeds, the
> user will simply get an LDAPMessage back with a  LDAPResult
> of `success'
> and no passwordPolicyResponse control.
> At this point in time the entity would have  no idea as to whether a
> password policy is being applied to their  userPassword.
> Receiving  the successful response without a
> passwordPolicyResponse control
> could  mean:
>     * The DSA knows nothing  about the Password Policy
> control, and since
> it was not marked as being  critical, has just ignored it,
>     * The DSA does support  Password Policy controls, but no password
> policy was applied to this  `userPassword' attribute,
>     * The DSA does support the  Password Policy control, and
> a policy does
> apply to the userPassword  attribute.
>
> If the  intention of the Password Policy Specification is to
> suppress returning controls on successful operations, then I
> think we need
> some way to indicate to the client that a password policy is
> being applied
> to their password.
> I think an ideal time to do this is when the  entity is using their
> password to authenticate themselves in a bind or compare
> operation. By
> returning the password policy control, even on a successful
> compare or
> bind, it makes the entity aware that their password has a
> policy  applied
> to it and that subsequent operations performed on this
> password  attribute
> will result in the policy being enforced.
>
> Regards,
> Andrew Sciberras
>
> -----Original  Message-----
> From: Jim Sermersheim  [mailto:jimse@novell.com]
> Sent: Thursday, 4 September 2003  7:52
> To: andrews@adacel.com.au; ldapext@ietf.org
> Subject:  Re: [ldapext] Returning the Password Policy Control
>
>
> You're right, it needs to be clarified.
>
> The original intent was that the control is only returned
> when needed (as
> specified), and not needed when operations suceed (and no
> extra information
> needs to be returned).
>
> We need to consider your reasons for returning the control
> for every bind
> and compare.
>
> Jim
>
> >>> "Andrew Sciberras" <andrews@adacel.com.au>  9/1/03 6:44:59 PM >>>
> Hi,
>
>  <snip>
>
> I think that it is  important to include the
> passwordPolicyResponse control
> in every bind and  compare response (when the request control
> is supplied)
> to
> provide a strong  indication to the client that the server is
> enforcing the
> password  policy.
>
> </snip>
>
>  Thanks.
> Andrew  Sciberras
>
>
> _______________________________________________
> Ldapext  mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
>
>
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
>


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext