Okay, it says:
"If pwdChangedTime does not exist, the user's password will not expire."
How have you guys dealt with this? I suspect that just asking people to please change
their passwords so we can make sure they expire will result in a low turn-out rate. :p
I also don't want people to just end-up locked out either, if at all possible.
Chris Jacobs, Jr. Unix System Administrator
Apollo Group | Apollo Marketing | Aptimus
2001 6th Ave Ste 3200 | Seattle, WA 98121
phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661
----- Original Message -----
From: Howard Chu <hyc(a)symas.com>
To: Chris Jacobs
Cc: 'tgates81(a)gmail.com' <tgates81(a)gmail.com>;
Sent: Tue Mar 23 19:27:53 2010
Subject: Re: Tips when implementing password policies
Chris Jacobs wrote:
I've a few accounts that I was testing with - after I set the
/after/ ppolicy was in place, things work as expected. Password history, #
grace auths, etc.
However, for those accounts existing before the ppolicy was in place, no
enforcement - there's no password change date set, nor any other policy items
added - other than the pwdpolicysubentry.
Please read the slapo-ppolicy(5) manpage. In particular, read the description
of the pwdChangedTime attribute.
One note: early on in the old ldap installations use, inetorgperson
class on accounts. Is that necessary for pwdpolicy? Would that make everything
else work for the legacy accounts?
I'll send an example LDIF of a test account and a legacy account later.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
This message is private and confidential. If you have received it in error, please notify
the sender and remove it from your system.