Re: Account Lockout Policies


"Bogwitch" <bogwitch@xxxxxxxxxxxxxxxxxxx> wrote in message
news:46dbf951$0$7525$88260bb3@xxxxxxxxxxxxxxxxxxxx
Roger Abell [MVP] wrote:

[snip]

Slight flaw there. Imagine a user who last used the system just before
the password change reminder. Let's assume 14 days. Now, that user will
have an expired password in 14 days, not 30 days. Now remember that most
users (IMO) won't change their password until they absolutely positively
have to....

Well observed Bogwitch, and stated.
The solution to poster's is either being overlooked
or it is even more deeply messy, as you show.

One's nightly process would need to track the age
of first expiry of the pwd, disabling only upon an
uninterrupted 16 days (per your example) in expired
pwd state, so it is soluble. The use of this delay
counter might even work with the need to adjust the
"lockout" threshold and the pwd aging settings
(age and prewarn) toward each other. But still,
needing to persist info, being no longer a stateless
simple script, raises the bar for the nightly's code.

Good catch; thanks.

Is there really no direct, reliable, way to determine
accounts qualifying for the poster's scenario ?

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.

Deleting user accounts after 30 days of inactivity allows a windows of
opportunity of 30 days for an ex-user to re-use the network. The ex-user
could have left the organisation in question and could have left under
unfavourable circumstances. Allowing accounts to remain dormat for 30 days
is simply not good business practice.

If a technical solution is unavoidable due to a lack of management buy-in,
there are a few ways that it can be achieved.

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


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


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

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 ?

Roger


.

Relevant Pages

  • Re: Account Lockout Policies
    ... Deleting user accounts after 30 days of inactivity allows a windows of opportunity of 30 days for an ex-user to re-use the network. ... If a technical solution is unavoidable due to a lack of management buy-in, there are a few ways that it can be achieved. ... Ascertain from those logs when users last logged in and add 30 days. ... From the users logon script, touch a unique file in a common area. ...
    (microsoft.public.security)
  • Re: Repost: Local logon and Network Access settings
    ... think require network login since they are over the wire do in fact ... In the default situation, Authenticated Users ... is a member of User on a member machine, and, Users are granted ... user accounts that should be allowed to log into the machines in SomeOU. ...
    (microsoft.public.windows.group_policy)
  • Re: Repost: Local logon and Network Access settings
    ... > think require network login since they are over the wire do in fact ... In the default situation, Authenticated Users ... > is a member of User on a member machine, and, Users are granted ... > user accounts that should be allowed to log into the machines in SomeOU. ...
    (microsoft.public.windows.group_policy)
  • =?ISO-8859-1?Q?Re:_RE:_Prob:_failed_to_verify_krb5_credentials:_Server_not_?= =?ISO-8859
    ... Every user shall login with its already existing AD accounts. ... These are the logins, which I try to enter in the login prompt when I visit http://wiki.test.lan:8080. ... I did a nslookup on the unix system and it showed me the server as ... AD, thats also in the keytab file, is TWikiUser. ...
    (comp.protocols.kerberos)
  • AIX password enumeration possible
    ... BPR personnel can neither confirm or deny this behaviour exists in any OS other than AIX of versions mentioned below. ... In the case that the correct password is provided, the response is as follows: ... believed to be in the response from the login program after authentication ... Give accounts that have been restricted from remote logins strong passwords. ...
    (Bugtraq)