[Date Prev][Date Next] [Chronological] [Thread] [Top]

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




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\)" <ldapext@ietf.org>                    
                      <andrews@adacel.c        cc:       "'Michael Ströder'" <michael@stroeder.com>, John           
                      om.au>                    McMeeking/Rochester/IBM@IBMUS, "'Ludovic Poitou'"                   
                                                <ludovic.poitou@Sun.COM>                                            
                      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
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext