|
Posted by Roger Abell [MVP] on September 4, 2007, 6:20 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> Roger Abell [MVP] wrote:
>
>>> The problem is the OP is looking for a technical solution that should be
>>> addressed by policy.
>>
>> I pretty much agree. However, I also see such a techincal routine as
>> a good safety against human error in the identity management / human
>> resources account control processes.
>
> Absolutely. An audit is essential to ensure all account are removed in a
> timely manner. Results of the audit should be fed back into the management
> chain to ensure orphan accounts do not re-occur.
>
>>> 1. Extract login details from the security logs. Ascertain from those
>>> logs when users last logged in and add 30 days. This would be messy and
>>> combersome. ADGP will have to be configured to recod the logins and it
>>> may be necessary to collect the security event log from multiple
>>> servers/ workstations. It will also introduce a risk of DOS if the
>>> device that has the latest logons is missed for any reason.
>>>
>> yes, but this is likely unworkable in a larger environment where
>> login success auditing is prohibitively resource expensive
>
> Agreed. The network I am currently using is configured for HEAVY logging
> and sweeping the event logs up takes several hours per week.
>
>>> 2. From the users logon script, touch a unique (to the user) file in a
>>> common area. If the file becomes older than 30 days, delete the account.
>>> Correct permissions will need to be set on the common area to prevent
>>> anyone from modifying the data contained therein.
>>> There are utilities available that can identify files that are more than
>>> 30 days old.
>>>
>> interesting alternative
>
> But prone to errors as I highlighted below. It may be useful to produce a
> list that the admin will then manually parse but risky for an automated
> delete that the OP wanted.
>
>>
>>> 3. Florian suggested using the last logon date from AD. While there are
>>> several utilities that will extract the relevant information I have had
>>> some issues with the scripts I have found that report some erroneous
>>> information back.
>>>
>> as mentioned in my initial post, this timestamp does not reflect all
>> login types; ok if one wants to require an interactive login within
>> some number of days as the criterion
>
> I suspect the OP would only be looking at interactive accounts rather than
> service logons. It is possible that they would be in a seperate OU and
> therefore easily distinguishable from the service accounts. But I'm second
> guessing the OP now....
>
>>> One flaw with the above examples: These will only detect a logon within
>>> tha last 30 days. It is possible for a user to log on and lock their
>>> workstation every night. (Some won't even do that!) If they continue to
>>> do this for 30 days, the login will become 'stale' and will be listed by
>>> each of the above methods as ready for deletion.
>>
>> yep
>>
>>> Personally, I would try to get the administratove control in place
>>> first. If necessary, one of the other solutions could be implemented as
>>> a detective control.
>>
>> Yes, but I still see the techincal cleaner/alerter/pruner as a good
>> thing.
>> How many environments have you been called in to work on where you
>> notice a string of (no longer used, forgotten) test accounts some admin
>> defined once on a time ?
>
> Worse still, test accounts with full admin privs. I suspect the proper
> solution would be a combination of policy controls with an alerter rather
> than the pruner for all the reasons you have stated above.
>
Given my preference we could put a forest into "Kerberos only"
authentication mode, and we would have hooks at the KDC such
as one to let us "extinguish" the ticket grants for a principal without
regard to their having a then unexpired TGT. Similarly we would
have a Kerberos log (not the current or the events admixed in the
security log) with fairly fine grained control over what is logged
(in this case we would just watch for new/renewed TGTs issued,
and if none in 30 days + lifespan of TGT then the account is deemed
unused per poster's scenario).
Roger
| 
XML site map