Hello list.
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:
- this is an operational account, thus a bit difficult to retrieve/edit (additional search options needed) - its locking value seems to be quite cryptic (but I maybe missed the semantic description somewhere) - it seems to be a binary field only (locked/unlocked), by opposition to shadowMax which allows to set an expiration date in advance. Even a purely cosmetic contract expiration date would be helpful here, but i didn't found anything similar in standard schemas - it doesn't handle easily use case where you just need to extract valid account list (such as scan-to-emails features from copiers), excepted by filtering on this attribute value, which isn't always possible (broken copiers firmware, for instance)
Last issue could be workarounded by filtering on ldap side using dynamic group I think.
So, does anyone have suggestion on how to handle this better ?
Guillaume Rousse skrev, on 04-12-2007 10:27:
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 no more.
--Tonni
On Tue, 2007-12-04 at 18:13 +0100, Tony Earnshaw wrote:
Guillaume Rousse skrev, on 04-12-2007 10:27:
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 no more.
Not true, if it is set to nopop the user can still receive mail ...
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 be convenient.
Regards, Buchan
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 no more.
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 be convenient.
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".
Best,
--Tonni
Guillaume Rousse schrieb:
- it doesn't handle easily use case where you just need to extract valid
account list (such as scan-to-emails features from copiers), excepted by filtering on this attribute value, which isn't always possible (broken copiers firmware, for instance)
This just came to me mind (never tried or checked it out): You maybe could use a replica slave which only contains active accounts (by replication filter) and let the copiers search this server and not the master with active and passive accounts. You have to "mark" the accounts so you can filter them for replication of course, but the copier's application does not have to know about this.
Hans
openldap-software@openldap.org
-
Buchan Milne -
Guillaume Rousse -
Hans Moser -
Tony Earnshaw