[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
> ---------------------------------------
>
>