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

RE: [ldapext] Grace logins and password policy

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