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.
Thoughts?
Thanks! - chris
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 email: chris.jacobs@apollogrp.edu
----- Original Message ----- From: Howard Chu hyc@symas.com To: Chris Jacobs Cc: 'tgates81@gmail.com' tgates81@gmail.com; 'openldap-technical@openldap.org' openldap-technical@openldap.org 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 password
/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 wasn't a
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.
- chris
-- -- 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.