Subject: RE: [ldapext] Returning the Password Policy Control

From: John McMeeking <[email-masked]>
Date: Thu, 4 Sep 2003 07:21:39 -0500

I've never thought of the password policy control response as being a
mechanism for informing the client that a password policy applied to any
given request.  Rather, I view the purpose of the control to be to carry
additional error / warning information so that a password policy aware
client could react to it.

I don't think the typical application is concerned with whether a password
policy is in effect, any more than I would expect logon to a system to tell
me that.  I just want to know that I have logged in successfully, or
changed my password successfully, and if there is an error (or my password
is about to expire), then I want to know that it is because passwords
expire every 186 days (for example).

I do think that an administrator or auditor has an interest in knowing that
password policy applies to a given entry and / or password attribute.  I
don't think that returning a password policy response control is the best
way to satisfy such a requirement.  One way to accomplish this is to define
an operational attribute, say passwordPolicySubentry, that names the
password policy subentry(ies?) that governs the entry.  The administrator /
auditor should have authority to read the password policy entry.

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.  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'" <[email-masked]>                          
                      <[email-masked]        cc:       "Ldapext \(E-mail\)" <[email-masked]>                         
                      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:[email-masked]]
Sent: Thursday, 4 September 2003  7:52
To: [email-masked]; [email-masked]
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" <[email-masked]>  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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Andrew Sciberras" <[email-masked]>
Date: Fri, 5 Sep 2003 08:02:16 +1000

Hi John!

>One way to accomplish this is to define
>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.

The password policy does define an operational attribute called
pwdPolicySubentry which points to the pwdPolicy subentry in effect for the
given entry.
And your absolutely right, anyone could use this attribute to identify the
exact details of the passsword policy being applied to the various
attributes within the entry.

I guess my question now is, if the intention of the password policy response
control is purely to convey error and warning information, what is the point
of returning a response control without any information?
After a quick glace at the draft, this apears to occur in the Bind and
Compare operations.

>John  McMeeking

Cheers,
Andrew Sciberras

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 5 Sep 2003 11:01:00 +1100

John,

John McMeeking wrote:
> 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
>                       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,
>