Account Lockout Policies

[bm]

My apologies if I'm not posting in the correct newsgroup. My question is if
there's a way to set up a security policy on Windows 2003 DC which is lockout
or disable a user that dosn't log into the domain for a specified amount of
time. For example a user that hasn't logged into the domain for 30 days will
be locked out???

Thanks

 

[Florian Frommherz [MVP]]

Howdie!

bm schrieb:
> My apologies if I'm not posting in the correct newsgroup. My question is if
> there's a way to set up a security policy on Windows 2003 DC which is lockout
> or disable a user that dosn't log into the domain for a specified amount of
> time. For example a user that hasn't logged into the domain for 30 days will
> be locked out???

Not that I knew of. There is no builtin functionality for this.

You could write yourself a script and run it on a daily basis. That
would check all user accounts and their last logon date and time.

See:
http://www.rlmueller.net/freecode4.htm - that could start you off.

cheers,

Florian
--
Microsoft MVP - Windows Server - Group Policy.
eMail: prename [at] frickelsoft [dot] net.
blog: http://www.frickelsoft.net/blog.

 

[Roger Abell [MVP]]

"bm" <bm@discussions.microsoft.com> wrote in message
news:5AA9CDD1-8EDC-4D52-A9DD-062C9E3B25F6@microsoft.com...
> My apologies if I'm not posting in the correct newsgroup. My question is
> if
> there's a way to set up a security policy on Windows 2003 DC which is
> lockout
> or disable a user that dosn't log into the domain for a specified amount
> of
> time. For example a user that hasn't logged into the domain for 30 days
> will
> be locked out???
>

Not built-in, however something close would not be impossible to implement.

One point however, lockout is usually a temporary account state triggered
by invalid login attempt, and lockout duration (or its being non-temporary)
may only be set the same of all accounts of the domain.

I think you were perhaps meaning disable the account after non-use for
so long. You would need to determine, such as in a script or your in-use
enterprise mgmt suite, which accounts have not logged in for 30 days.

This might not be as simple as it sounds as the last login timestamps do
not reflect all valid authenticated uses of an account. Attempting to use
event logs to fill this gap would imply logging of successful domain logins
(which is often not enabled due to the huge volume of events generated)
and would mean monitoring/reading the security logs on all DCs.

That said, if you can define a satisfactory determination logic, disabling
the so determined account is trivial/simple such as run in a nightly task.

Perhaps your more direct option would be to adjust the days of nonuse
and password change intervals so they are the same, and then nightly
read accounts with expired passwords and verify they are disabled.

Roger

 

[bm]

Thank you both so much! I really thought there was a built-in way of doing
this -- I guess not. I'll have to revert to doing a little scripting.

Thanks again!



"Roger Abell [MVP]" wrote:

> "bm" <bm@discussions.microsoft.com> wrote in message
> news:5AA9CDD1-8EDC-4D52-A9DD-062C9E3B25F6@microsoft.com...
> > My apologies if I'm not posting in the correct newsgroup. My question is
> > if
> > there's a way to set up a security policy on Windows 2003 DC which is
> > lockout
> > or disable a user that dosn't log into the domain for a specified amount
> > of
> > time. For example a user that hasn't logged into the domain for 30 days
> > will
> > be locked out???
> >
>
> Not built-in, however something close would not be impossible to implement.
>
> One point however, lockout is usually a temporary account state triggered
> by invalid login attempt, and lockout duration (or its being non-temporary)
> may only be set the same of all accounts of the domain.
>
> I think you were perhaps meaning disable the account after non-use for
> so long. You would need to determine, such as in a script or your in-use
> enterprise mgmt suite, which accounts have not logged in for 30 days.
>
> This might not be as simple as it sounds as the last login timestamps do
> not reflect all valid authenticated uses of an account. Attempting to use
> event logs to fill this gap would imply logging of successful domain logins
> (which is often not enabled due to the huge volume of events generated)
> and would mean monitoring/reading the security logs on all DCs.
>
> That said, if you can define a satisfactory determination logic, disabling
> the so determined account is trivial/simple such as run in a nightly task.
>
> Perhaps your more direct option would be to adjust the days of nonuse
> and password change intervals so they are the same, and then nightly
> read accounts with expired passwords and verify they are disabled.
>
> Roger
>
>
>

 

[Bogwitch]

Roger Abell [MVP] wrote:

[snip]

> Perhaps your more direct option would be to adjust the days of nonuse
> and password change intervals so they are the same, and then nightly
> read accounts with expired passwords and verify they are disabled.

Roger,

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

Bogwitch.

 

[Roger Abell [MVP]]

"Bogwitch" <Bogwitch@reply.to.group.fake> wrote in message
news:J7DBi.47020$1G1.30781@newsfe2-win.ntli.net...
> Roger Abell [MVP] wrote:
>
> [snip]
>
>> Perhaps your more direct option would be to adjust the days of nonuse
>> and password change intervals so they are the same, and then nightly
>> read accounts with expired passwords and verify they are disabled.
>
> Roger,
>
> 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....
>
> Bogwitch.

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 ?

Roger

 

[Bogwitch]

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

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.

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.

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.

Bogwitch.

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

 

[Anteaus]

Not a solution, but I 've always thought Windows' default security policies
were daft, what with having faddist password-change requirements, yet NO
protection against dictionary attack, and NO way of identifying or closing
disused accounts.

It stands to reason that any system which permits remote access MUST have a
limit to the number of password-entry attempts in a given period, otherwise a
correct guess is inevitable given enough time. Yet, while windows has this
capability it's (inexplicably) turned off by default. Even though turning it
on has no significant impact on system useability. Why not, for heavens sake?

Disused accounts represent a serious security problem, especially with many
sites now granting remote access, thus there may be any number of
remotely-accessible accounts lying open for which the user has long-since
left the company, but for which the personnel dept just plumb forgot to tell
I.T. about. Yet, Windows provides NO way of closing accounts which have not
been used for a substantial time, which would seem to be one of the most
sensible and basic precautions to take against this occurrence.

The other side of this is that despite its laxness in other respects,
Windows sets a 42-day password-expiry policy, and worse, does so 'silently'
without telling anyone it's done so. This is extremely bad.

I've had cases where laptops in overseas locations have unexpectedly
demanded a password-change in situations where there was no way to rejoin the
domain within the time limit. This effectively 'bricks' the laptop until it
can be shipped back to base. Highly embarrassing for me, and could have cost
the company an international deal.

It's time someone persuaded MS to see sense over these poorly thought-out
security policies.

1. Ditch password-expiry, or at least WARN the user that it exists, right
from first logon. (timebomb icon in sytem tray?)

2. Set password-lockout (dictionary-attack protection) ON by default.

3. Provide a means to identify/close disused accoutns.


Just my two cents worth.

 

[Steve Riley [MSFT]]

{...reposting...I think I might have triggered a word filter on the
Microsoft servers, never saw it arrive there...}

Account lockout is a poor substitute for good passwords -- and is one of the
most expensive security features you can use. Let's think about this by
considering the threat. What threat does account lockout (attempt to)
mitigate? Password guessing. How can you make password guessing attacks
become useless for an attacker? Two ways: implement lockouts or use good
(meaning long) passwords.

Consider the first choice, account lockouts. The typical cost to an
organization to reset locked accounts is US$75 per help desk call. In a
medium or large organization, this can become a very high monthly
maintenance cost. In nearly all instances, the call results from users
locking themselves out, not users encountering locked out accounts because
some bad guy was trying to guess passwords. Account lockouts have one
more -- very bad -- problem: they *create* opportunities for bad guys to
conduct denial-of-service attacks against accounts or entire domains! Even
if you use a timed unlock of, say, 15 minutes, then the attacker can write
his script to churn through thousands of bogus logon attempts every 15
minutes 2 seconds. So, contrary to your claim, enabling this setting
actually can have significant impact on usability.

Account lockout is there for people who absolutely need it. But I can't
think of any instance where this is true. Instead, have a policy that
requires simple passwords at least 15 characters long. Forget about
complexity rules that force people to write down passwords. A simple
15-character passphrase (think short sentence) is easy to remember, quick to
type, and far stronger than any short complex password. A passphrase like
this will withstand any kind of automated password attack, including those
based on rainbow tables. And you can even use a method that helps you
remember unique phrases for each site, if you wish:

* web mail: "my dog and i got the mail"
* shopping: "my dog and i bought some stuff"
* office: "my dog and i went to work"
* photo site: "my dog and i admired some art"

This is why we disable account lockout by default. There are much better --
and much less expensive -- ways to mitigate the threat.


You're right, there's no built-in method to automatically disable unused
accounts. A variety of third-party products can provide you with this
functionality. I suspect some of them might be free, perhaps simple scripts
even. I tried searching on "automatically disable unused accounts" and saw a
few hits that looked promising. This particular function, however, rightly
belongs in the HR process. A number of customers I've spoken with have
automated the account creation/disablement/deletion process, incorporating
it into HR systems. When a new user is hired, the account is created when
the user departs, the account is disabled some time later, it's deleted.
The HR systems take care of this, not domain or enterprise administrators. I
wrote more about this subject here:
http://blogs.technet.com/steriley/archive/2007/05/31/when-you-say-goodbye-to-an-employee.aspx


Password expiration is an important setting for everyone. It mitigates two
threats: employees sharing passwords and bad guys discovering passwords.
Because we can eliminate the second threat using long simple passphrases as
I described above, then we have only one remaining threat: password sharing.
Your estimation of how prevalent this threat is in your environment will
guide you toward choosing an expiration time that works for you. 42 days is
a reasonable default our own corpnet uses 70 days. My experience with most
customers shows that password sharing isn't a problem. So for those who do
enforce long simple passphrases, I suggest that a reasonable default for
expiration is 120 days.

Windows begins notifying you 14 days before your password expires. You can
change this time period through group policy. I was in a similar situation
recently. Last month my domain password expired while I was in Australia for
TechEd there. I could continue to log on to my laptop with cached
credentials (so I'm not sure why you say your laptops become bricked?), but
couldn't use Outlook Web Access or RPC+HTTP of course. So I connected to a
Terminal Server computer we have on the Internet, logged on there, and
changed my password.

--
Steve Riley
steve.riley@microsoft.com
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com


"Anteaus" <Anteaus@discussions.microsoft.com> wrote in message
news:8303A854-B8AC-4AA9-9B4C-CA68C2374739@microsoft.com...
> Not a solution, but I 've always thought Windows' default security
> policies
> were daft, what with having faddist password-change requirements, yet NO
> protection against dictionary attack, and NO way of identifying or closing
> disused accounts.
>
> It stands to reason that any system which permits remote access MUST have
> a
> limit to the number of password-entry attempts in a given period,
> otherwise a
> correct guess is inevitable given enough time. Yet, while windows has
> this
> capability it's (inexplicably) turned off by default. Even though turning
> it
> on has no significant impact on system useability. Why not, for heavens
> sake?
>
> Disused accounts represent a serious security problem, especially with
> many
> sites now granting remote access, thus there may be any number of
> remotely-accessible accounts lying open for which the user has long-since
> left the company, but for which the personnel dept just plumb forgot to
> tell
> I.T. about. Yet, Windows provides NO way of closing accounts which have
> not
> been used for a substantial time, which would seem to be one of the most
> sensible and basic precautions to take against this occurrence.
>
> The other side of this is that despite its laxness in other respects,
> Windows sets a 42-day password-expiry policy, and worse, does so
> 'silently'
> without telling anyone it's done so. This is extremely bad.
>
> I've had cases where laptops in overseas locations have unexpectedly
> demanded a password-change in situations where there was no way to rejoin
> the
> domain within the time limit. This effectively 'bricks' the laptop until
> it
> can be shipped back to base. Highly embarrassing for me, and could have
> cost
> the company an international deal.
>
> It's time someone persuaded MS to see sense over these poorly thought-out
> security policies.
>
> 1. Ditch password-expiry, or at least WARN the user that it exists, right
> from first logon. (timebomb icon in sytem tray?)
>
> 2. Set password-lockout (dictionary-attack protection) ON by default.
>
> 3. Provide a means to identify/close disused accoutns.
>
>
> Just my two cents worth.
>

 

[Roger Abell [MVP]]

"Bogwitch" <bogwitch@reply.to.group.fake> wrote in message
news:46dbf951$0$7525$88260bb3@free.teranews.com...
> 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

 

[Roger Abell [MVP]]

"Anteaus" <Anteaus@discussions.microsoft.com> wrote in message
news:8303A854-B8AC-4AA9-9B4C-CA68C2374739@microsoft.com...
> Not a solution, but I 've always thought Windows' default security
> policies
> were daft, what with having faddist password-change requirements, yet NO

faddist ?

> protection against dictionary attack, and NO way of identifying or closing
> disused accounts.
>

Thinks about it. What Windows implements needs to work in all the
environments where Windows is deployed. Think of implementing
"protection against dictionary attack" (whatever you may have in mind
there other than tracking the rate of failed login attempts) or determining
what is "unused" in a large, global AD deployment.
Combine the result from that sofware design thought experiment with
the need to pivot results via a central, FSMO if you will, clearinghouse
(i.e. one in the world for that global AD).
Finally, look at the cost of such and compare that with the movement of
environments toward two-factor authentication methods (i.e. the cost of
providing compared to the believed inherent problems in the authN creds
it is designed to safeguard).


> It stands to reason that any system which permits remote access MUST have
> a
> limit to the number of password-entry attempts in a given period,
> otherwise a
> correct guess is inevitable given enough time. Yet, while windows has
> this
> capability it's (inexplicably) turned off by default. Even though turning
> it

"inexplicably" ?? MS mentions many times that usability studies have
shown it is not used due to the high cost that results at the helpdesk.

> on has no significant impact on system useability. Why not, for heavens
> sake?
>

Actually, turning it on has an impact on system overheads, particularly for
a globally dispersed AD deployment. The lockout is handled by the PDC
FSMO and relies on the lesser known feature, urgent replication.

> Disused accounts represent a serious security problem, especially with
> many
> sites now granting remote access, thus there may be any number of
> remotely-accessible accounts lying open for which the user has long-since
> left the company, but for which the personnel dept just plumb forgot to
> tell
> I.T. about. Yet, Windows provides NO way of closing accounts which have
> not
> been used for a substantial time, which would seem to be one of the most
> sensible and basic precautions to take against this occurrence.
>

I find that compromised accounts are at least as big of a problem, that is,
accounts that have "fallen into" the wrong hands. Password change is the
built-in mechanism to periodically invalidate these accesses. The accounts
are seen as in use and very possibly in an expected use pattern, so
disabling
due to login failures, due to non-use, due to use attempting to access areas
unauthorized for the account, etc. all would not see a problem yet the
account
may be in use for info theft for extended periods.

> The other side of this is that despite its laxness in other respects,
> Windows sets a 42-day password-expiry policy, and worse, does so
> 'silently'
> without telling anyone it's done so. This is extremely bad.
>

?? Most admins I know go over these settings adjusting to their shop's
standards and users are provided with pwd change notices for a time
period that is configurable. What are you wanting to see happen?

> I've had cases where laptops in overseas locations have unexpectedly
> demanded a password-change in situations where there was no way to rejoin
> the
> domain within the time limit. This effectively 'bricks' the laptop until
> it
> can be shipped back to base. Highly embarrassing for me, and could have
> cost
> the company an international deal.
>

I really do not follow the scenario. The cached login would not be
demanding a password change.

> It's time someone persuaded MS to see sense over these poorly thought-out
> security policies.
>

AFAIK they have for a long, long time been advising people to
move away from password based authentication.

> 1. Ditch password-expiry, or at least WARN the user that it exists, right
> from first logon. (timebomb icon in sytem tray?)
>
> 2. Set password-lockout (dictionary-attack protection) ON by default.
>

1+2 ditch passwords

> 3. Provide a means to identify/close disused accoutns.
>

look into two-factor identity credentials forms and their mgmt capabilities

 

[Bogwitch]

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

 

[Roger Abell [MVP]]

"Bogwitch" <bogwitch@reply.to.group.fake> wrote in message
news:46dd6e14$0$16408$88260bb3@free.teranews.com...
> 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

 

[John Brown]

This is certainly very interesting topic here. We developed a product
OUrganizeIT ( www.synergix.com ) to address a different operational issue
(managing computer and user objects in AD), however, over the course of time
added a feature to update the account expiration attribute of the user
object. You can not set the value to 1 or 7 days and be assured that that
account will be secured if there is not activity on that user object. No
software is installed on DCs

Other issue is when dealing with VPN users who log in with cached
credentials. We can still manage the computer object and user object much
like they were LAN connected and also have tackled the password change issue
which is a major problem managing for VPN users (unless you use VPN software
GINA)

J


"bm" <bm@discussions.microsoft.com> wrote in message
news:5AA9CDD1-8EDC-4D52-A9DD-062C9E3B25F6@microsoft.com...
> My apologies if I'm not posting in the correct newsgroup. My question is
> if
> there's a way to set up a security policy on Windows 2003 DC which is
> lockout
> or disable a user that dosn't log into the domain for a specified amount
> of
> time. For example a user that hasn't logged into the domain for 30 days
> will
> be locked out???
>
> Thanks