Re: Last bind timestamp?

[Pat Riehecky <prieheck@iwu.edu>]

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