Re: Account Lockout Policies
- From: Bogwitch <bogwitch@xxxxxxxxxxxxxxxxxxx>
- Date: Tue, 04 Sep 2007 16:35:38 +0100
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.interesting alternative
There are utilities available that can identify files that are more than 30 days old.
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.
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.
Posted via a free Usenet account from http://www.teranews.com
- Re: Account Lockout Policies
- From: Roger Abell [MVP]
- Re: Account Lockout Policies
- Prev by Date: Re: Account Lockout Policies
- Next by Date: Re: How does MBSA collect it's data?
- Previous by thread: Re: Account Lockout Policies
- Next by thread: Re: Account Lockout Policies