To actually check you need to use the ldap attributes [of the user object] logingraceremaining and logingracelimit when logingraceremaining is less than logingracelimit the password has expired and the user needs to be redirected to the "Your password has expired, please change it" page Be aware though that these two attrbutes only exist if the user password is set to expire and grace logins is enabled.
Have not yet been required to do this, but there were a couple of old development projects that sounded like they would provide a good start. I think [IIRC] that auth_info was one - all though external_auth_acl may cover requirements now.. I was going to make changes to a ldap auth program to give extra info on failure e.g OK / ERR / EXPIRED, then do a redirect to a info/change password page on the EXPIRED result. I hope this helps.... John Blance Technical Architect Canterbury District Health Board Direct Dial: 03 3378794 [EMAIL PROTECTED] >>> "Justin Hennessy" <[EMAIL PROTECTED]> 06/16/03 12:18 PM >>> I think what Frank is talking about is "grace" logins (a number of chances after your password has expired). Any ideas on how to check for this? I am running NDS as well with a view to implementing the same system so I am interested to see if there is a fix. >>> Christoph Haas <[EMAIL PROTECTED]> 16/06/2003 1:51:47 am >>> On Sun, Jun 15, 2003 at 05:54:06PM +0200, Frank Fegert wrote: > we're using squid with the squid-ldap-auth helper to authenticate users & > groups against NDS. The NDS uses password aging with three "goodwill" > (whats the word in english?) logins after password expiration. We use basically the same setup. The "goodwill" is called "intruder lockout" in Novell slang. > The problem right now is that the squid-auth helper consumes all "goodwill" > logins after a password has expired, without informing the user about > that fact. Thus the next logon to the OS is denied and the user has no > chance to change his password. > Is there a way to circumvent this problem? The authentication cache in Squid distinguishes between positive authentication (username and password matched) and negative authentication (username/password mismatch). So the only case that a user accidentally gets locked out is when he really tries to enter the same (wrong) password three times. We are running LDAP authentication against an NDS, too. During normal operation there are no users locked out. But maybe you talk about something else. Christoph -- ~ ~ ".signature" [Modified] 3 lines --100%-- 3,41 All ********************************************************************** ** This email and attachments have been scanned for content and viruses and is believed to be clean ** This email or attachments may contain confidential or legally privileged information intended for the sole use of the addressee(s). Any use, redistribution, disclosure, or reproduction of this message, except as intended, is prohibited. If you received this email in error, please notify the sender and remove all copies of the message, including any attachments. Any views or opinions expressed in this email (unless otherwise stated) may not represent those of Canterbury District Health Board **********************************************************************
