Re: Account Lockout Policies



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.

Bogwitch.

--
Posted via a free Usenet account from http://www.teranews.com

.



Relevant Pages

  • Re: Account Lockout Policies
    ... a good safety against human error in the identity management / human ... resources account control processes. ... login types; ok if one wants to require an interactive login within ... I suspect the OP would only be looking at interactive accounts rather than ...
    (microsoft.public.security)
  • Re: Enable non-admin users to access member servers or client PC
    ... the accounts are in the OU where i've delegated the control. ... I delegate the control to the group created and those Helpdesk users were ... I've given FULL right via delegation for Helpdesk to modify user ...
    (microsoft.public.windows.server.active_directory)
  • Re: restricting user
    ... There are a user rights that control logon, ... and/or accounts granted that user right. ... domain to allow only users to login which i wants. ...
    (microsoft.public.windows.server.security)
  • Re: AD Delegation Fails - Permissions Disappear
    ... the Windows domain controller that holds the primary domain ... ACL on all security principals (users, groups, and machine accounts) present ... AdminSDHolder Object Affects Delegation of Control for Past Administrator ...
    (microsoft.public.windows.server.active_directory)
  • Re: Computers joining customers domain - how to best configure
    ... At this stage I think I'm talking about allowing control of the local ... I have a client/server product that is sold to a number of customers. ... The server runs Windows 2003 Std and is in it's own workgroup. ... and are in the same workgroup and have the same local user accounts. ...
    (microsoft.public.windows.server.general)