This is an old post but wanted to follow up on it because what Guido said is important to understand....
Some clients authenticating in various ways WILL generate multiple authentication attempts when they fail. Win95 would regularly send 3 bad requests for every single bad password entered. 2 bad attempts sent on the first real attempt at least is extremely common with all clients. Having a small number of bads for a lockout policy is not a good way to do things unless you expect users to be perfect in typing in their passwords and want to punish them when they aren't. You have to ask yourself and your security people, what are they attempting to do with the lockout policy. If it is simply to do what it was built for, to slow down automated hacking attempts, a policy of 15 or 20 is just as useful as 5. More useful for the number of helpdesk calls that will be reduced by using a policy of 15/20. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Friday, September 24, 2004 12:51 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Account Lockout resets in large companies "security department requires that we set accounts to lockout after 5 bad attempts" - which is VERY low in a distributed environment, specifically if you consider how authentication and the protocoll fallback works. You should be able to argue, that your security department wants you to lock the accounts after 5 "real" bad attempts: a single false logon attempt from a Win2k/XP client can get the false-logon count to be increased by more than one count (e.g. by first trying to authenticate via Kerberos, then falling back to NTLM and trying again). It is not uncommon to reach the limit of 5 bad logon attempts after trying to logon TWICE. While it is generally arguable how to handle the unlock (automatic vs. manual), you do want to give your users at least the chance to try 5 times to get their password right (i.e. at least twice or three times by memory, before they look at the piece of paper under their keyboard...). Thus you should discuss with your security department the need to increase the nr. of bad logon attempts to 10-15 to meet their requirements (only for AD - you can keep it to 5 for other systems). This has significantly limited user-related PW lockouts for our own company and for many of our customers. I'm not sure about our own numbers, but for one of my customers it decreased the incidents by 80% (!!!). Naturally, this also reduced the pain related to unlocking the accounts on a DC remote to the user's site (which we usually handle by allowing the helpdesk to choose the closest DC when performing the unlock) /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Snyder, Robert W. Sent: Wednesday, September 22, 2004 7:11 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Account Lockout resets in large companies I don't disagree with the policy suggestions but unfortunately our corporate information security department requires that we set accounts to lockout after 5 bad attempts and accounts to remain locked out until manually reset, so we don't have much choice there. We are using Tivoli Identity Manager (I think that's the name.) and there are plans to put in a web based password reset self-service facility, but the problem is it only communicates with a local domain controller in the corporate data center. It doesn't have the "smarts" to make a change on a remote DC for a remote user. I did do some testing on password changes and account lockouts with the help of a remote user here. Based on my testing it appeared password changes were immediate as it replicated immediately to the PDC emulator and it looks like if the client failed when checking the local DC it then checked the password against the PDC emulator. Account lockouts on the other hand seemed to depend on replication. Both directions actually. When he locked his account out remotely, I didn't see it as locked out until the change had replicated back to the corporate office, and likewise when I then unlocked it, he couldn't logon until the change had replicated to his DC. We are using Windows 2003 for all our DC's. Are you saying that Lockouts don't necessarily always follow the replication schedule? Bob Snyder Sr. Technical Programmer/Analyst Global Software Support [EMAIL PROTECTED] -----Original Message----- From: joe [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 11:56 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Account Lockout resets in large companies First off, you should look at using intelligent lockout policies that slow down "bad guys" and mostly leave normal users alone. Policies such as lockout forever or lockout within 5 bad aren't very intelligent because you are pretty much guaranteed to hit normal people on a regular basis and you have to beef up support to compensate. Though consider a self-unlock self-password reset kiosk functionality like MTEC has in PSYNCH. Combine that with a custom GINA that lets you go to the web page to do the reset or unlock. It then asks you some profile questions or asks for a securid and then it unlocks/resets. Consider a 15 or 30 minute lockout with like 15/20 bad passwords. Most normal users will not get caught with that kind of number and if they do, the lockout time is such that they can get a cup of coffee and be off and running again. Though it will substantially slow down someone trying to hack. You do want to make sure though that you have a decent password policy in terms of how often they expire (say 63 or 91 days) and have a decent length and maybe even complexity enabled. You will also do well to have achieved single signon. Of course if you have security requirements, you may not have a choice but to lockout forever or whatever. At that point, your users are going to have understand there is pain associated with entering bad passwords and you should be investigating in detail every occurrence of that happening any way. One point of note, even if you have the machine name, you aren't guaranteed to be able to find the DC doing the authentication. You can query the machine and ask it for its preferred DC for a given domain, but you never know for sure. Finally, I believe you should find with W2K3 that the remote DC will occasionally go back and doublecheck with the PDC to see if an account is still locked. I just did a quick test on my home test environment and it appeared to work just fine that way. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Snyder, Robert W. Sent: Wednesday, September 22, 2004 10:03 AM To: [EMAIL PROTECTED] Subject: [ActiveDir] Account Lockout resets in large companies We are in the midst of rolling out our AD implementation world-wide with about 90 DC's globally. One of the issues we are wrestling with is how to ensure that Account unlocks happen on the users local DC so that they aren't forced to wait on replication. We've looked at the Acctinfo.DLL but it doesn't seem to give the correct site info unless you know the machine name and most users probably don't know this nor can they find it if they are currently locked out. We also tried Lockoutstatus.exe tool. Account unlocks seemed to work here, but the password changes aren't working. We'd like one method for doing both. Obviously, we can try to train our help desk to try to determine what the correct DC is and then point their ADUC to the right DC when making the change. We'd like to find a simpler solution though. We were wondering how other large international companies with central help desks may have resolved this problem. Anyone have any suggestions. Thanks in advance for your help. Bob Snyder Sr. Technical Programmer/Analyst Global Software Support [EMAIL PROTECTED] ----------------------------------------- ********************************************************************** PLEASE NOTE: The above email address has recently changed from a previous naming standard -- if this does not match your records, please update them to use this new name in future email addressed to this individual. This message and any attachments are intended for the individual or entity named above. If you are not the intended recipient, please do not forward, copy, print, use or disclose this communication to others; also please notify the sender by replying to this message, and then delete it from your system. The Timken Company ********************************************************************** List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ ----------------------------------------- ********************************************************************** PLEASE NOTE: The above email address has recently changed from a previous naming standard -- if this does not match your records, please update them to use this new name in future email addressed to this individual. This message and any attachments are intended for the individual or entity named above. If you are not the intended recipient, please do not forward, copy, print, use or disclose this communication to others; also please notify the sender by replying to this message, and then delete it from your system. The Timken Company ********************************************************************** List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
