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

From: John McMeeking <[email-masked]>
Date: Fri, 14 Nov 2003 15:07:08 -0600

As I read this draft, if the password must be changed (after reset), the
bind is successful, even if the client does not include the password policy
request control.  This seems like a problem when the LDAP server is used
only for authentication.  I would think that a bind in that case should
fail -- on the assumption that there is a password policy aware application
that can be used to change the password.  Otherwise, the user can continue
to authenticate successfully, which seems to be in violation of the intent
of the policy.

Should the bind procedure be changed to fail if the password must be
changed because of being reset when there is no password policy control?
And succeed, with the warning, if the control is present?  I'd be tempted
to say even then it should fail, but I'm not sure if clients like JNDI
would be able to handle a control on a failure.  Or at least this concern
discussed, possibly with the recommendation that servers should provide a
means to chose this behavior?

John  McMeeking

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

---

From: Ludovic Poitou <[email-masked]>
Date: Sat, 15 Nov 2003 00:12:28 +0100

>to authenticate successfully, which seems to be in violation of the intent
Good remark.

>And succeed, with the warning, if the control is present? 
>
I'd be tempted to say yes.
I also concur that this should be a SHOULD.
I believe that it will take a while before all clients use the password 
policy controls on all bind operations.

I will update the draft to discuss this issue and provide some 
recommandations.

Thanks for your comments,

Ludovic.

> I'd be tempted

-- 
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: Michael Ströder <[email-masked]>
Date: Mon, 17 Nov 2003 09:37:33 +0100

> changed because of being reset when there is no password policy control?

Yes.

> And succeed, with the warning, if the control is present?

No.

> I'd be tempted to say even then it should fail,

I agree.

> but I'm not sure if clients like JNDI
> would be able to handle a control on a failure.

I wouldn't care.

>  Or at least this concern

I would not leave this open to server configuation. There should be exactly 
one way to do it.

Ciao, Michael.

---

From: "Andrew Sciberras" <[email-masked]>
Date: Tue, 18 Nov 2003 08:38:30 +1100

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