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

From: John McMeeking <[email-masked]>
Date: Mon, 17 Nov 2003 16:24:00 -0600

Andrew,

Here's the situation that was described to me:

A web application is configured to authenticate to LDAP.  Somewhere under
the covers this translates into a bind request to the LDAP server.  I
believe it is quite common for many "accounts" on LDAP servers to be used
in binds for only this purpose.

The administrator has enabled password policy on the LDAP server with the
"password must be changed after [re]set" feature and creates a new account
-- or resets the password of an existing account.  At this point the
account is now in a state where the user must change the password.

The web application, not knowing about password policy, issues a bind
request and gets a "success" result.  If this is the only way that a bind
is done to this account, the user can authenticate to the web application
over and over without changing their password.  This seems to violate the
intent of the "password must be changed after reset" setting.  If the
connection were used for some other operation other than bind - or changing
the client's password - the client would get failures.

Thus my suggestion that the bind request ought to fail.  I don't believe
that authentication using a password that must be reset should succeed from
the perspective of the web application.  If the web application was
password policy aware, I'd expect it to tell the user that his password
must be changed, provide an interface to change the password, and not allow
any other actions.

In an environment where password policy has been set up in this way some
set of tools would be provided to enable the user to change their password,
most likely through an application that does know about password policy
controls.  Alternately, I suppose the server could send a failure response
to the client, but leave the connection in an authenticated state
sufficient to perform the change password request.  That would require the
client to recognize the failure and allow password changes -- still a
change, but possibly one that is easier to handle than installing a new
client.  And there's probably nothing inherently wrong with an anonymously
bound password change request, as long as it contains the old password and
is treated by server similar to a bind request and modify request (i.e.
audit attempts to change the password with wrong old password).  These seem
like policy decisions that can be left to the implementation.

Certainly, if the applications used to change passwords cannot be changed
to deal with these accounts, you're in trouble.  But you shouldn't be using
this password policy then.

John  McMeeking

                      "Andrew                                                                                       
                      Sciberras"               To:       "Ldapext \(E-mail\)" <[email-masked]>                    
                      <[email-masked]        cc:       "'Michael Ströder'" <[email-masked]>, John           
                      om.au>                    McMeeking/Rochester/IBM@IBMUS, "'Ludovic Poitou'"                   
                                                <[email-masked]>                                            
                      11/17/2003 03:38         Subject:  RE: [ldapext] draft-behera-ldap-password-policy - bind     
                      PM                        behavior when pwd must be changed                                   
                      Please respond to                                                                             
                      andrews                                                                                       

G'Day!

Purhaps i've misunderstood something, but I have a little trouble agreeing
with the arguments that have been made in this discussion.

I do agree that in the current state of the draft, the 'change after reset'
feature does not accomidate for LDAP Server's being used for authentication
into other systems.
However, failing bind operations is certainly not the solution.

Imagine all the LDAP server's which use the bind operation to authenticate
user's for the purpose of accessing the directory information.

Lets say a new user joins an organization and their password is
automatically set to their Date Of Birth by the administrator.
At the moment, the user would be able to bind to the directory and be
severly restricted in what they can do, until they change their password.
If the bind operation returned a failure, how do you propose that the user
is ever going to be able to change their password?

As far as I can tell, there are two ways that the password is ever going to
be changed.
1. By the user,
2. By someone else.

If we fail binds, the user can never be able to change the password
themselves since they would not be able to authenticate themselves to the
directory.
It would be entirely possible for someone else to change the password,
however this would be pointless. In the Adacel View500 implementation of
this draft, we have made the assumption that if a A's password is modified
by B, and B has sufficient access rights to modify A's password, then B is
an administrator.
This being the case, if B modified A's password for her, then the directory
would automatically reset the pwdReset value to TRUE.

On a different note, the description of pwdReset states the following:
"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."

I think this should be reworded to get rid of the 'first authentication'
part.
There is nothing in the draft that restricts a user from binding a million
times before changing their passwrod.

Regards,
Andrew Sciberras
Software Engineer
Adacel Technologies

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

---

From: Michael Ströder <[email-masked]>
Date: Tue, 18 Nov 2003 12:48:21 +0100

I fully agree with John's analysis.

Ciao, Michael.

---

From: "Andrew Sciberras" <[email-masked]>
Date: Wed, 19 Nov 2003 08:25:41 +1100

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

---

From: Ludovic Poitou <[email-masked]>
Date: Wed, 19 Nov 2003 09:52:03 +0100

Hi Andrew,

Your assumptions are reasonable and similar to mines.
I will add text to the ID to remove the ambiguities.

Ludovic.

-- 
Ludovic Poitou
Directory Architect.
Directory Server Group, Grenoble, France
Sun Microsystems Inc.

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy
all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Dejan Muhamedagic <[email-masked]>
Date: Wed, 19 Nov 2003 09:57:39 +0100

Hello,

Perhaps I'm missing something, but this discussion doesn't make
much sense to me.

As Andrew pointed out several times: in order to change the
password user _must_ first bind to the LDAP server.  If an LDAP
authentication client doesn't support password policy controls
that's another matter and I don't see what can the LDAP server do
about it.  That is, unless we first change semantics of the
password change operation and introduce the "password must be
changed first" return code.  Right?

Cheers,

Dejan