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

RE: [ldapext] Grace logins and password policy


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

"Ramsay, Ron" <Ron.Ramsay@ca.com> wrote on 05/08/2006 03:29:01 AM:

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

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.

> 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?
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.
>
> Ron
>
> -----Original Message-----
> From: Ludovic Poitou [mailto:Ludovic.Poitou@Sun.COM]
> Sent: Friday, 5 May 2006 9:19 PM
> To: Ramsay, Ron
> Cc: ldapext@ietf.org
> Subject: Re: [ldapext] Grace logins and password policy
>
>
>
> Ramsay, Ron wrote:
> > 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.
> 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 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?
> >  
> 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.
>
>
>
>
> > Ron
> >
> > _______________________________________________
> > Ldapext mailing list
> > Ldapext@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ldapext
> >  
>
> --
> 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.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
John  McMeeking
 
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext