Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind behavior when pwd must be changed

From: John McMeeking <[email-masked]>
Date: Wed, 19 Nov 2003 08:13:42 -0600

Andrew,

I agree with your analysis up to the point where the user must change his
password.

If the client is password policy aware (i.e. it includes the password
policy request control on bind and other requests), the client can bind to
the server with a password that must be reset.  The bind should be
successful, and the password policy response control will indicate that the
password must be changed.  The client can then issue a modify request or
the "password modify" extended operation (RFC 3062).

This requires that the user have access to a password policy aware
application to change his password after it has been reset.

But your note did get me thinking a bit more.  Many times a password change
is not done by a client authenticated as the user.  In fact, the user may
not even have authority to change his password directly, or any other
information.  Instead, it is done through an application running under some
other identity.  So maybe this flag should be reset by any successful
request to change the password that includes both the user's old password
and the new password.  And I could see a strong desire for an administrator
be able to clear this flag - but maybe that should be left to an
implementation.

What I feel is lacking in the draft is the distinction between a client
that provides the password policy request control and a client that does
not.
- If no password policy control is present, a bind with a reset password
should fail
- If a password policy is present, a bind with a reset password should
succeed with a reponse control returned as is currently stated in the
draft.

And I'll add your desire to see clarification as to when the "password
reset indicator" should be set to FALSE.

John  McMeeking

                      "Andrew                                                                                       
                      Sciberras"               To:       "'Michael Ströder'" <[email-masked]>                 
                      <[email-masked]        cc:       "Ldapext \(E-mail\)" <[email-masked]>                    
                      om.au>                   Subject:  RE: [ldapext] draft-behera-ldap-password-policy - bind     
                      Sent by:                  behavior when pwd must be changed                                   
                      ldapext-admin@iet                                                                             
                      f.org                                                                                         

                      11/18/2003 03:25                                                                              
                      PM                                                                                            
                      Please respond to                                                                             
                      andrews                                                                                       

Hi,

>
>I fully agree with John's analysis.
>

Thats cool, although I think my differing opinion comes from a certain
level
of ambiguity within the draft.

The decription of pwdMustChange is :
"This attribute specifies with a value of "TRUE" that users must change
their passwords when they first bind to the directory after a password is
set or reset by the administrator."

And pwdReset is:
"This attribute holds a flag to indicate (when TRUE) that the password has
been reset and therefore must be changed by the user on first
authentication"

The problems are:
* Administrator is never defined
* The draft never states when the pwdReset value should be set to TRUE
* The draft doesn't account for the scenario of a reset password (ie.
pwdReset == TRUE) being changed by an Administrator again.

The assumptions i've taken from the draft, into my implemntation, is:
* An administrator is anyone with the power to change the user's password,
who isn't the user.
* If a password, which is being governed by a pwdMustChange policy, is
changed by my definition of an administrator then the pwdReset value will
be
set to TRUE.
* If an administrator change dthe password again, the pwdReset value will
still be TRUE.

My implementation was based on my assumptions. And im my implementation,
the
only way your going to get rid of that pwdReset value of TRUE is for the
user to change the password themselves, which requires a bind operation.

The only way that I can see your proposed solution working is if you and
other implementations have made different assumptions as to what an
administrator  is.
If this is the case, then I think we should aim to remove this level of
ambiguity from the draft.

Catch,
Andrew Sciberras.

>Ciao, Michael.

_______________________________________________
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: Dejan Muhamedagic <[email-masked]>
Date: Wed, 19 Nov 2003 16:00:19 +0100

John,

On Wed, Nov 19, 2003 at 08:13:42AM -0600, John McMeeking wrote:
[snip]
> succeed with a reponse control returned as is currently stated in the

How can LDAP server tell if the client supports password policy or
not?  All it knows is that they want to bind.

I agree that the security policy should be enforced at the server
and not at the client, but in this case we have no means to do
that without "breaking" clients which don't know how to read the
policy.

Cheers,

Dejan