[Date Prev][Date Next]
Re: account locking strategy
Buchan Milne skrev, on 05-12-2007 07:43:
I have to handle account locking on our directory, so as to keep
accounts from people not working here anymore. On Buchan's suggestion, I
used ppolicy sofar, with pwdAccountLockedTime attribute set to
000001010000Z to lock unused account. This is really handy to handle
unix account and web applications account at once. However, they are
also some drawbacks:
Dunno, this is probably all too child-like, but my site has an attribute
'acountStatus' from qmail.schema. This is because my master provider is
also an MTA.
If it isn't set to "active", whoever it is on the MTA can't do nothing
Not true, if it is set to nopop the user can still receive mail ...
No, this is not a boolean match, it's a caseIgnoreIA5Match and my search
filter is '(&(objectClass=posixAccount)(accountStatus=active))'. That
"active" string is necessary for mail to work for the user.
However, this is another example of an application-level control
(objectclass shadowAccount is another example), which means you need to
jump through hoops to try and ensure all your applications use the same
attributes in the same way to have a consistent behaviour.
Thus, having a more conventient "lock this user", or "this entry - not
it's password - expires at this time" method on the directory side would
Here again this might be too specific, but my sites both use ppolicy for
all users. That includes the attribute pwdLockoutDuration. If one has an
alternative policy for locked out users and sets pwdLockoutDuration to
empty or 0 for locked out users (a simple MOD is all that's needed to
change policies), the slapo-ppolicy man page states that "the password
cannot be used to authenticate the user to the directory again until it
is reset by an administrator".
Email: tonni at hetnet dot nl