At the university we have massive account creep. Alumni keep their accounts and terminated employees would never do anything bad so I generally don't get informed when the leave, drop outs aren't even tracked so who knows... Right now I estimate about 700 accounts that should not even exist. That being said, I would like to reclaim some sanity in my account system. For political reasons I can only ask for one account to be checked for validity at a time... could take a few years to filter through them all.... Thus was a plan hatched....
If there was a way I could store the timestamp of the last successful bind by this user in their entry (similarly to lastmod or create date) then after a year or three anyone who has no entry would be a candidate for further investigation....
Is there a way to make openldap store this data for me? Or must I write some C for an overlay (direct integration into the bind code seems a bad idea since if you don't need this why let it slow you down, and my C is more than a bit rough around the edges)?
Pat
OpenLDAP 2.4.10 on Linux for what it is worth.
Pat Riehecky writes:
For political reasons I can only ask for one account to be checked for validity at a time... could take a few years to filter through them all....
OMG - I hope you are talking about checking old accounts, not new ones as well.
If there was a way I could store the timestamp of the last successful bind by this user in their entry (similarly to lastmod or create date) then after a year or three anyone who has no entry would be a candidate for further investigation....
The accesslog (record Binds) and ppolicy overlays (record changes, and expire old passwords).
In the long run, see if you can ensure future accounts get tied to an person ID from your personnel/student systems if you haven't already. This lets you push formalities of tracking who people are and who are responsible for knowing that, from IT staff who commonly have no clue, to student/employee admin staff who do.
For accounts whose owners can easily prove they are the owner, you can have a password expiry policy. Passwords get stolen and cracked, computers get hacked... you should limit the lifetime of a stolen password. Such unused accounts will stand out as a side effect of password expiry.
On the ldap side, the ppolicy overlay can help. You need a simple way for the users set new passwords, and a procedure for users whose accounts have been locked to get new passwords. Ask the local sysadmin and show ID, maybe. (And have mercy on the people who'll be asked for new passwords - don't expire 1000 password on the same day.)
I wrote:
For accounts whose owners can easily prove they are the owner, you can have a password expiry policy. (...)
Or rather, you can have it for others too but that makes it part of an *account* expiry policy - maybe the final axe in your plan to tidy up. When you are ready to tell the remaining unknown account claimants "We don't know who could tell us you should keep access to that account, or even if they still work here. Maybe you know? If not, too bad."
On Mon, 2008-06-30 at 23:30 +0200, Hallvard B Furuseth wrote:
Pat Riehecky writes:
For political reasons I can only ask for one account to be checked for validity at a time... could take a few years to filter through them all....
OMG - I hope you are talking about checking old accounts, not new ones as well.
If there was a way I could store the timestamp of the last successful bind by this user in their entry (similarly to lastmod or create date) then after a year or three anyone who has no entry would be a candidate for further investigation....
The accesslog (record Binds) and ppolicy overlays (record changes, and expire old passwords).
In the long run, see if you can ensure future accounts get tied to an person ID from your personnel/student systems if you haven't already. This lets you push formalities of tracking who people are and who are responsible for knowing that, from IT staff who commonly have no clue, to student/employee admin staff who do.
For accounts whose owners can easily prove they are the owner, you can have a password expiry policy. Passwords get stolen and cracked, computers get hacked... you should limit the lifetime of a stolen password. Such unused accounts will stand out as a side effect of password expiry.
On the ldap side, the ppolicy overlay can help. You need a simple way for the users set new passwords, and a procedure for users whose accounts have been locked to get new passwords. Ask the local sysadmin and show ID, maybe. (And have mercy on the people who'll be asked for new passwords - don't expire 1000 password on the same day.)
In the long run I would love to use ppolicy for this, but alas for the next period-of-time-A I need to keep multiple hashes of user passwords in our LDAP server until all the systems being lumped together have had time to change their passwords. Hurray for infrastructure overhaul! Right now I have some MD5 some CRYPT and some SSHA floating about. For reasons beyond my control, at this time, anyone who changes their password gets all three. Eventually I hope to move everyone to SSHA, but until then ppolicy cannot work for me. It doesn't support the crazy multiple password entries per user thing I have going on. Realistically I don't expect to have to keep the multi-password hashes for long, but like any place... just because we should doesn't mean we wont wander off in the wrong direction.
Pat
Pat Riehecky writes:
In the long run I would love to use ppolicy for this, but (...)
OK, overlay accesslog for both Bind and updates then. Then regularly pull updates out from the accesslog database. Or accesslog for Bind and auditlog for updates. Or if you want an overlay which does this, auditlog + accesslog's Bind recognition should provide a good template.
Unless ppolicy does support just recording multi-value changes, as long as expiry and so on is turned off so it doesn't have to modify anything itself. Haven't tried.
Right now I have some MD5 some CRYPT and some SSHA floating about. For reasons beyond my control, at this time, anyone who changes their password gets all three. Eventually I hope to move everyone to SSHA, but until then ppolicy cannot work for me. It doesn't support the crazy multiple password entries per user thing I have going on.
Sounds like it would be useful for ppolicy to support that. Would need a ppolicy config option saying "assume multiple userPassword values are different hashes of the same password".
Realistically I don't expect to have to keep the multi-password hashes for long, but like any place... just because we should doesn't mean we wont wander off in the wrong direction.
So true:-(
openldap-software@openldap.org
-
Hallvard B Furuseth -
Pat Riehecky