Dear Pat,
Thank you for your update and I apologize for the delay.
Could you let me know the following information?
Note: Please check the possible reasons in my last post and ensure that it
is not the cause of this Account Lockout issue.
1. From your last post, I understand that there are two domain controllers
in your network, am I correct? It is better to troubleshoot account lockout
issues in a simple environment. Is it possible that you schedule an
off-peak time, take one DC offline, and then perform tests with the single
DC (PDC Emulator)?
2. I remembered that the problem occurs with a newly-created account. So
does this problem occur with every account there? Does it occur during the
first bad logon attempts of a new account?
3. How did you notice that it took 10 minutes to unlock the account? When
an account is locked, please open the account's properties window in the
"Active Directory Users and Computers" snap-in, and check the status of the
"Account is locked out" every minute. Let me know the results.
Thanks you!
Regards,
Joe Wu
Product Support Services
Microsoft Corporation
Get Secure! -
www.microsoft.com/security
====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
|From: Pat <
[email protected]>
|Subject: Re: Account Lockout Policy
|Date: Fri, 24 Oct 2003 11:45:52 -0400
|Message-ID: <
[email protected]>
|References: <
[email protected]>
<
[email protected]>
<
[email protected]>
<
[email protected]>
<
[email protected]>
<Rs#
[email protected]>
|X-Newsreader: Forte Agent 1.93/32.576 English (American)
|MIME-Version: 1.0
|Content-Type: text/plain; charset=ISO-8859-1
|Content-Transfer-Encoding: 8bit
|Newsgroups: microsoft.public.win2000.group_policy
|NNTP-Posting-Host: mail.htechnology.com 198.65.193.67
|Lines: 1
|Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl
|Xref: cpmsftngxa06.phx.gbl microsoft.public.win2000.group_policy:15641
|X-Tomcat-NG: microsoft.public.win2000.group_policy
|
|Joe,
|I have SP4 on both my DC's , I changed the lockout duration to 1
|minute and locked myself out with a test account(it took only 3 tries)
|waited a one, then five then 10 minutes for it to unlock itself and it
|never does.
|
|I unlocked the account and loggon . when I checked my effective rights
|they are 1,10,1.
|
|On Thu, 23 Oct 2003 17:02:41 GMT, (e-mail address removed) (Joe Wu
|[MSFT]) wrote:
|
|>Dear Pat,
|>
|>Thank you for your update.
|>
|>How many domain controllers are in your network? Have you install Service
|>Pack 4 on them? Windows 2000 Service Pack 4 contains updates for the
|>account lockout component. After applying Service Pack 4 on all the
domain
|>controllers, please check if the problem has been resolved.
|>
|>By the way, please check the experience I have summarized below. If
|>possible, please consider using "Strong Password Policy" or changing the
|>Account Lockout duration to 1 minute as workaround for this problem.
|>
|>What's the Microsoft recommendation on the Account lockout policy?
|>=================================================================
|>
|>In order to prevent attackers from guessing users' passwords and decrease
|>the likelihood of successful attacks on your network, you can use the
|>following methods to secure your system:
|>
|> 1: Enable the "Account Lockout Policy"
|> 2: Enable the "Strong Password Policy"
|>
|>I list both advantage and disadvantage of these policies:
|>
|>Advantage of the "Account lockout policy"
|>---------------------------------------------------
|>After the user is locked out, the DC doesn¡¯t authenticate the user¡¯s
|>logon request any more even if he inputs the correct password.
Therefore,
|>the hacker has no chance to guess the password.
|>
|>Disadvantage of the "Account lockout policy"
|>---------------------------------------------------
|>There is a risk of unintentionally locking the users. Such a result can
be
|>quite costly for your organization, because locked-out users cannot
access
|>their user accounts until the account unlocks automatically after a
|>specified amount of time or until you unlock the accounts for them.
|>
|>Advantage of the "Strong Password Policy"
|>--------------------------------------------------
|>The odds that someone will be able to gain access by hacking a password
are
|>very low.
|>Assume the following:
|>26 - Lowercase characters
|>26 - Uppercase characters
|>32 - Special characters
|>10 - Numbers
|>Password length policy = 6
|>Max password age policy = 60 days
|>26 + 26 + 32 + 10 = 94
|>94^6 = 689,869,781,056 unique password combinations.
|>
|>Some of these password possibilities are not going to be valid, that is,
by
|>default we do not allow any part of a user¡¯s logon name or all the same
|>characters as a password so these possibilities will have to be deducted
|>from the number above. Because that number is so small we will leave the
|>number above alone for our calculations.
|>
|>Given a 60 day password expiry, 133,076 password attempts within a second
|>would have to be attempted to run through all the possibilities before
the
|>password is required to be changed again. Now unless you are the most
|>unlucky hacker in the world you will not have to run through all the
|>possibilities. The probability is very low that you would not have to run
|>through at lest 60% of these before you break the password. If true that
|>means about 79,845 (133,076 * .60) logon attempts a second must be
|>attempted.
|>
|>If the minimum password length is set to 7 the possible password
|>combinations top 64 trillion. Now redo the calculations we just did on
that
|>number and compare them to the numbers we just did on ~690 billion and
you
|>will find that to run through 60% of the possible password combinations
for
|>each second of the time period the password is valid you would have to
|>logon about 7,407,407 times.
|>
|>Disadvantage of the "Strong Password Policy"
|>-----------------------------------------------------
|>The hacker can continuously guess the user's password before the user
|>changes it.
|>
|>So regarding the above theory, we recommend you
|>--------------------------------------------------------------------------
--
|>1. Enable the strong password policy.
|>2. Disable the ¡°Account Lockout Policy¡±.
|>
|>If you have to enable the account lockout policy, you can try to set the
|>Account Lockout duration to 1 minute. With such settings, the hacker can
do
|>60(minutes)*24(hours)*60(days)*10(attempts)=864,000 attempts. It is
|>impossible to guess the password from 689,869,781,056 samples.
Meanwhile,
|>the end user will only be affected when he locked out within 1 minute.
|>After 1 minute, he can return to normal.
|>
|>Reference
|>-------------
|>For more information about that, please refer to the following links
|>
|>1. Best practices ---"Be cautious when defining account lockout policy"
|>
|>
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtec
hn
|>ol/windowsserver2003/proddocs/server/windows_password_protect.asp
|>
|>2. Account lockout policy overview
|>
|>
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtec
hn
|>ol/windowsserver2003/proddocs/server/password_lockout_concept.asp
|>
|>Possible Reasons for Account Lockout
|>==============================
|>
|>Also, as a supplement of the recommendation, I would like to list the
|>possible causes of the account lockout.
|>Managing and troubleshooting an environment with account lockout policy
and
|>mass clients will be time consuming and will impact your business.
|>
|>However, use strong password policy can achieve the same security level.
|>
|>The possible reasons are:
|>
|>1. User mis-types his password for several times.
|>
|>2. Many applications will cache credentials and keep active threads in
use,
|>not updating credentials after a change in password.
|>
|>3. Bad Password Threshold set too low. The main reason users may not be
|>able to access their accounts properly the first time is that they forgot
|>their passwords. If this is the case, it may take them several attempts
to
|>log on properly. Users could also have problems accessing a remote system
|>where their current passwords don't match the passwords the remote system
|>expects. If this happens, several bad logon attempts may be recorded by
the
|>remote system before the user ever gets a prompt to enter the correct
|>password. The reason is that Windows NT may attempt to automatically log
on
|>to the remote system. The thresholder accepts values from 1 to 999,
|>however, the higher the value, the higher the risk that a hacker may be
|>able to break into your system. A reasonable value for this field is 15.
|>This is high enough to rule out user error and low enough to deter
hackers.
|>
|>4. A user is concurrently logged onto multiple machines. Threads of
network
|>applications running on those machines may run in the context of that
|>locally logged on user when accessing resources in the domain. If this
user
|>changes his password on one of the machines, applications running on the
|>other machines will still use the original password. As those
applications
|>authenticate when accessing network resources, the bad/old password is
|>still being used and the users account becomes locked.
|>
|>5. Disconnected Terminal Server sessions: This can have the exact same
|>effect as a user with multiple interactive logons (mentioned above 4).
This
|>only difference is the source of the lockout comes from a Terminal Server.
|>
|>6. You are using OWA/IIS/Exchange and falling into the following
situations:
|>
|>
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q173658
|>
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q276541
|>
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q291598
|>
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q321652
|>
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q163576
|>
|>7. By default, most computer services are configured to start using the
|>"Local System" account. However a service logon account can be manually
|>configured to logon using a specific user account/password. If a service
is
|>configured to start with a specific user account and that user later
|>changes their password, the service logon property will need to be
updated
|>with the new password or that service may lock out that users account.
You
|>can use winmsd to detect it.
|>
|>8. XP/Windows 2003 behavior: Stored User Names and Passwords
|>
|>9. If a domain password is changed through outlook and running MSN
|>messenger your clients may run into a lockout.
|>
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q328867
|>
|>Please let me know your thoughts. I look forward to hearing from you.
|>
|>Regards,
|>Joe Wu
|>Product Support Services
|>Microsoft Corporation
|>
|>Get Secure! -
www.microsoft.com/security
|>
|>====================================================
|>When responding to posts, please "Reply to Group" via your newsreader so
|>that others may learn and benefit from your issue.
|>====================================================
|>This posting is provided "AS IS" with no warranties, and confers no
rights.
|>
|>--------------------
|>|From: Pat <
[email protected]>
|>|Subject: Re: Account Lockout Policy
|>|Date: Wed, 22 Oct 2003 15:57:51 -0400
|>|Message-ID: <
[email protected]>
|>|References: <
[email protected]>
|><
[email protected]>
|><
[email protected]>
|><
[email protected]>
|>|X-Newsreader: Forte Agent 1.93/32.576 English (American)
|>|MIME-Version: 1.0
|>|Content-Type: text/plain; charset=us-ascii
|>|Content-Transfer-Encoding: 7bit
|>|Newsgroups: microsoft.public.win2000.group_policy
|>|NNTP-Posting-Host: mail.htechnology.com 198.65.193.67
|>|Lines: 1
|>|Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl
|>|Xref: cpmsftngxa06.phx.gbl microsoft.public.win2000.group_policy:15557
|>|X-Tomcat-NG: microsoft.public.win2000.group_policy
|>|
|>|I"m not using this account on any services, stricly a test account.
|>|not mapping any drives on logon. should the invalid attempts all show
|>|up in my secuity log? if I up my settings to 50, then it should take
|>|40 more attempts to lock me out, right? (just for testing)
|>|
|>|thanks
|>|
|>|On Wed, 22 Oct 2003 19:37:15 GMT, (e-mail address removed) (Joe Wu
|>|[MSFT]) wrote:
|>|
|>|>Hello Pat,
|>|>
|>|>Thank you for your update. It means the security policy settings have
|>been
|>|>applied.
|>|>
|>|>I think the behavior is possible. Theoretically, beside logon, the
|>|>initialization of a certain service/application with incorrect user
|>|>credential may also be counted as an invalid attempt. For example, the
|>|>services/applications loaded during the user logon, and the network
drive
|>|>mapping may cause this kind of problem.
|>|>
|>|>Please check if this is the root cause. Thanks!
|>|>
|>|>Regards,
|>|>Joe Wu
|>|>Product Support Services
|>|>Microsoft Corporation
|>|>
|>|>Get Secure! -
www.microsoft.com/security
|>|>
|>|>====================================================
|>|>When responding to posts, please "Reply to Group" via your newsreader
so
|>|>that others may learn and benefit from your issue.
|>|>====================================================
|>|>This posting is provided "AS IS" with no warranties, and confers no
|>rights.
|>|>
|>|>--------------------
|>|>|From: Pat <
[email protected]>
|>|>|Subject: Re: Account Lockout Policy
|>|>|Date: Tue, 21 Oct 2003 13:51:44 -0400
|>|>|Message-ID: <
[email protected]>
|>|>|References: <
[email protected]>
|>|><
[email protected]>
|>|>|X-Newsreader: Forte Agent 1.93/32.576 English (American)
|>|>|MIME-Version: 1.0
|>|>|Content-Type: text/plain; charset=us-ascii
|>|>|Content-Transfer-Encoding: 7bit
|>|>|Newsgroups: microsoft.public.win2000.group_policy
|>|>|NNTP-Posting-Host: mail.htechnology.com 198.65.193.67
|>|>|Lines: 1
|>|>|Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
|>|>|Xref: cpmsftngxa06.phx.gbl microsoft.public.win2000.group_policy:15465
|>|>|X-Tomcat-NG: microsoft.public.win2000.group_policy
|>|>|
|>|>|the effective settings are 30 , 10 and 30, so I should not lock out
|>|>|until 10 trys but if I logout as this user and try to logon with a bad
|>|>|password, it locks me out after 3 attempts.
|>|>|On Mon, 20 Oct 2003 17:30:47 GMT, (e-mail address removed) (Joe Wu
|>|>|[MSFT]) wrote:
|>|>|
|>|>|>Hello,
|>|>|>
|>|>|>Thank you for your post.
|>|>|>
|>|>|>We can use Security Configuration Editor to check the effective
|>settings
|>|>of
|>|>|>Account Lockout Policy. To do so, please logon as the related user
|>|>account
|>|>|>and run "secpol.msc". Browse to Security Settings\Account
|>|>Policies\Account
|>|>|>Lockout Policy. On the right pane, please check the column of
|>"Effective
|>|>|>Setting".
|>|>|>
|>|>|>We can also run the following command to export all of the effective
|>|>|>security settings to a file (c:\sec.txt):
|>|>|>
|>|>|>secedit /cfg c:\sec.txt /export /mergedpolicy
|>|>|>
|>|>|>In this case, I suspect that the group policy is not applied
correctly.
|>|>|>Therefore, I suggest that you run the following command to manually
|>|>enforce
|>|>|>a system security refresh:
|>|>|>
|>|>|>secedit /refreshpolicy machine_policy /enforce
|>|>|>
|>|>|>Please then check if the problem has been resolved.
|>|>|>
|>|>|>I hope the above information helps. Thanks!
|>|>|>
|>|>|>Regards,
|>|>|>Joe Wu
|>|>|>Product Support Services
|>|>|>Microsoft Corporation
|>|>|>
|>|>|>Get Secure! -
www.microsoft.com/security
|>|>|>
|>|>|>====================================================
|>|>|>When responding to posts, please "Reply to Group" via your newsreader
|>so
|>|>|>that others may learn and benefit from your issue.
|>|>|>====================================================
|>|>|>This posting is provided "AS IS" with no warranties, and confers no
|>|>rights.
|>|>|>
|>|>|>--------------------
|>|>|>|From: Pat <
[email protected]>
|>|>|>|Subject: Account Lockout Policy
|>|>|>|Date: Mon, 20 Oct 2003 10:12:39 -0400
|>|>|>|Message-ID: <
[email protected]>
|>|>|>|X-Newsreader: Forte Agent 1.93/32.576 English (American)
|>|>|>|MIME-Version: 1.0
|>|>|>|Content-Type: text/plain; charset=us-ascii
|>|>|>|Content-Transfer-Encoding: 7bit
|>|>|>|Newsgroups: microsoft.public.win2000.group_policy
|>|>|>|NNTP-Posting-Host: mail.htechnology.com 198.65.193.67
|>|>|>|Lines: 1
|>|>|>|Path:
|>|>|>cpmsftngxa06.phx.gbl!cpmsftngxa09.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFT
NG
|>P1
|>|>2.
|>|>|>phx.gbl
|>|>|>|Xref: cpmsftngxa06.phx.gbl
microsoft.public.win2000.group_policy:15373
|>|>|>|X-Tomcat-NG: microsoft.public.win2000.group_policy
|>|>|>|
|>|>|>|Running W2k with AD, have my account policy setup in my default
domain
|>|>|>|GPO. as
|>|>|>|Account lockout duration=30
|>|>|>|Account lockout threshold=10
|>|>|>|Reset Account lockout counter ater =30
|>|>|>|
|>|>|>|My users are still able to lock them selves out after 3 attempts and
|>|>|>|there is no time limit on unlocking the account, it has to be done
|>|>|>|manually.
|>|>|>|
|>|>|>|how can I ck to see what the users lockout policy actually is?
|>|>|>|Do I need to setup the policy on the DC OU?
|>|>|>|I have no other policies setup.
|>|>|>|
|>|>|>|thanks
|>|>|>|
|>|>|
|>|>|
|>|
|>|
|
|
