Subject: [ldapext] Grace logins and password policy

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 5 May 2006 11:52:32 +1000

Hi LDAPexters,

At the moment the Behera draft
(draft-behera-ldap-password-policy-08.txt) states that, once a password
has expired, it will need to be reset. This reqires administrator
intervention. Some vendors, implementing their own password policy
mechanisms, allow a user to login with an expired password, forcing them
to change it before proceeding.

I believe there is business case for either method of expired password
handling and that the Behera draft should address these.

More specifically:

If a user's password has expired and the number of grace logins has been
exceeded then, at the vendor's discretion (or by configuration), a
server can respond to a BIND request with either:

1) Bind Refuse - setting the LDAP response control error
passwordExpired, requiring the user's password to be reset (current
case);

or

2) Bind Confirm - setting the LDAP response control error
changeAfterReset, requiring the user to change their password before
allowing other operations.

The second option would seem a lot more manageable with a large user
base.

What do you think?

Ron

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

---

From: Ludovic Poitou <[email-masked]>
Date: Fri, 05 May 2006 13:18:47 +0200

Ramsay, Ron wrote:
> intervention.
Once the password has expired, it needs to be changed (or reset). This 
requires administrative rights, not necessarily an administrator 
intervention.

>  Some vendors, implementing their own password policy
I would consider that option 2 is actually defeating the password policy 
and the grace login mechanism.
The main issue for letting user authenticate with an expired password 
but requiring the user to change their password before allowing other 
operations, is that often there are several applications using the 
directory server, some are only doing authentication and nothing more. 
These applications, ignoring the requirement to change the password, can 
continue to authenticate expired users forever.
Users do not directly interact with the LDAP server, they are usually 
interact with applications that are using LDAP. There should be another 
application available to users to allow them to do a self reset of the 
password. This application should first verify the identity of the user 
by other means such as asking secret questions, and then proceed to the 
password change using an application specific identity which has the 
appropriate access rights.

An alternate solution solely based on LDAP could be to allow the use of 
the Password Modify Extended Operation under SSL as an anonymous users, 
only if the old password is provided and matches the expired password.

Regards,

Ludovic.

-- 
Ludovic Poitou                                    Sun Microsystems Inc.
Software Architect                               Directory Server Group
http://blogs.sun.com/Ludo/                             Grenoble, France

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: "Ramsay, Ron" <[email-masked]>
Date: Mon, 8 May 2006 18:29:01 +1000

Thanks for your reply, Ludovic. I have some more comments.

I'm happy that it is possible to set up self service systems (with
administrative privileges) to handle resetting passwords after grace
logins have been exceeded.

I agree that option 2 defeats the purpose of a grace login mechanism.

I'm not sure that applications implementing the password policy control
can authenticate and nothing more. If a password is reset then it would
never need changing as 'changeAfterReset' would be ignored.

The main point I was making is that some vendors, implementing their own
password policy mechanisms, allow a login with an expired password,
forcing a change before proceeding. But you are correct in that these
environments don't support grace logins. Applications built using the
Netscape (expired) control & Microsoft domain logins are examples.

Perhaps, in the absence of 'pwdGraceLoginLimit' (or if it has a value of
zero), the directory could respond exactly as it does for a reset
password? That is, could we make grace logins optional?

Ron

-----Original Message-----
From: Ludovic Poitou [mailto:[email-masked]] 
Sent: Friday, 5 May 2006 9:19 PM
To: Ramsay, Ron
Cc: [email-masked]
Subject: Re: [ldapext] Grace logins and password policy

Ramsay, Ron wrote:
> (draft-behera-ldap-password-policy-08.txt) states that, once a 
> password has expired, it will need to be reset. This reqires 
> administrator intervention.

>  Some vendors, implementing their own password policy mechanisms, 
> allow a user to login with an expired password, forcing them to change

> it before proceeding.

> If a user's password has expired and the number of grace logins has 
> been exceeded then, at the vendor's discretion (or by configuration), 
> a server can respond to a BIND request with either:
>

Regards,

Ludovic.

---

From: John McMeeking <[email-masked]>
Date: Mon, 8 May 2006 07:39:50 -0500

I fear I'm rehashing old arguments,
but...

"Ramsay, Ron" <[email-masked]>

> never need changing as 'changeAfterReset' would be ignored.

Consider use of LDAP authentication to access a web
site.  For the web servers I am familiar with, a logon request results
in something like the following:

- server, under its own identity, searches for user
"john", gets search entry uid=john,cn=users,...

- server, under a separate connection, binds as uid=john,cn=users,...
The bind request may contain a password policy response (or the web
server may not know about password policy at all)

- if the bind request is successful, the server, under
its original connection, retrieves group or or other information about
uid=john,cn=users,... for authorization, personalization, or other purposes.

With this usage, the only operation performed under
the user's identity is the initial bind request.  At least with respect
to operations performed under the user's identity, I think this would meet
the criteria of an application that might use password policy to authenticate
and nothing more.  Password changes might be done under another identity.
I commonly see deployments where users do not change their passwords
directly through LDAP, but through some application that runs under its
own identity.

As Ludovic pointed out, any application which does
not use password policy - and for some directory deployments, the existance
of such applications may be a long-term condition - a bind request that
would have resulted in a password policy warning is only seen as a successful
bind.

> password? That is, could we make grace logins optional?

In the case of "change after reset" error
(or expiration warning, or...), a password-policy aware web server - or
other application - might examine the bind response controls and redirect
the user to a password change form.

In the case of an application that can perform password
changes under an administrative identity, it should suffice for an expired
password to fail with a "password expired" error.  The application
should be able to examine the bind response control and redirect the user
to a password change application.  An application that does not use
password policy, I think, must see a bind failure for expired or reset
passwords.

I have heard arguments for a case where an application
that does not use password policy controls might check for expired or reset
passwords by doing its own searches to retrieve password policy operational
attributes.  In that case, the application needs to be able to determine
that the provided password was correct, which suggests a successful bind
result.  The example given was that of a user developed web application,
where the web server might use LDAP authentication and be password policy
ignorant, and the user application provided the password policy support.
The web server needs the successful bind for reset or expired passwords.
This isn't all that far fetched.  Web server support for password
policy might not be available for some time, while user applications may
be able to adopt password policy more quickly.

This is probably an argument for providing more options
for server behavior than I would care to address in this draft.  It
is also an argument for separating client observable bind/compare request
responses behavior from policy administration.  I am not sure where
I would put password change policy and its responses.  It has never
been clear to me that there was much need for a standard password policy
administration model unless you are interested in a multi-vendor distributed
directory, and that begs for common access control, replication, and other
support.  Certainly there is need for a common client model.

> Ludovic Poitou
Sun
Microsystems Inc.

> Software Architect
Directory Server
Group

> https://www1.ietf.org/mailman/listinfo/ldapext

John  McMeeking