[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Automatic Account Deactivation?



Oh, now that is interesting. What is the name of that overlay?

Anyway, another option is to use your central logging host (you do have
one, right? ;-) to monitor logins and update a table somewhere with that
information. You can then do a nightly batch update against your expired
accounts in LDAP and set a value such as accountActive to No. If you
don't support an extended attribute like accountActive (or whatever you
name it), then you can also scramble the password.

So, yes, a central logging host would be helpful here. :)

--
Puryear IT, LLC
Identity Management, Directory Services, Systems Integration
Baton Rouge, LA * 225-706-8414 * http://www.puryear-it.com

"Best Practices for Managing Linux and UNIX Servers"
  http://www.puryear-it.com/pubs/linux-unix-best-practices


Pierangelo Masarati wrote:
> Aharon Verno wrote:
>> Thanks for the reply.  That's exactly what we're trying to do, disable
>> rather than delete.  The plan is to have some sort of check for the
>> number of days since last login and then send out an email to our
>> Operators when it's hit 60 and then 90 days without a login.  At that
>> point it should either be disabled automatically, or an Operator
>> should do it manually.  This is mainly due to security risks with
>> email accounts.  Our email system is tied into the LDAP so I want to
>> check the last LDAP authentication.  The part I'm getting stuck on is
>> exactly how to keep track of the last login for a user.  Do you have
>> any tips about this?
> 
> we developed an overlay that adds an operational attribute that keeps
> count of the last (successful/unsuccessful) login attempt of a user. The
> key issue is (loose) replication; the value is logged separately by the
> provider and by the consumers, and a batch process syncs it
> periodically.  In case of a sync error (e.g. one logs during a sync),
> the worst case is that the counter gets out of date by a sync period,
> which is usually much shorter than any critical time (in your case,
> 60/90 days).  This algorithm hasn't been specified yet for syncrepl,
> although it shouldn't be an issue.
> 
> p.
> 
> 
> 
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
> 
> SysNet s.r.l.
> via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> ---------------------------------------
> Office:  +39 02 23998309
> Mobile:  +39 333 4963172
> Email:   pierangelo.masarati@sys-net.it
> ---------------------------------------
> 
>