Re: bad logon attempts against the Unlock dialog box don't count

From: JuanMedia (juanmedia_at_eresmas.com)
Date: 06/03/04


Date: Thu, 3 Jun 2004 01:16:10 -0700


     Hi all,
now we have reproduce the behaviour in a Windows 2003 Server. Here are the steps:

WINDOWS SERVER 2003

1º Create a domain : blas.com
2º Create a new user in the domain with name "usersample"
3º Add the new user to Administrators group in order to let her login to the domain controler computer.
4º Add an account policy to lock the users acount after three bad logon attemts.
   Press button Start-> Programs-> Administrative Tools-> Domain Controller Security Policy
   -> Windows Settings-> Security Settings-> Acount Policies-> Acount Lockout Policy: Set the "Reset account lockout counter
   After" to three.
5º Logout as Administrator
6º Start a new session as usersample
7º Press Ctrl + Alt + Supr and lock computer
8º Press Ctrl + Alt + Supr and type three incorrect passwords
9º The user account is now locked.

Umit, did you reproduce the problem with W2K?
Do you know how do we have to configure our server to avoid this behaviour?

Thank you very much.

     ----- JuanMedia wrote: -----
     
     Hi all,
     thankyou Umit for your interest, here is the complete procedure taken from my notes:
     1.- Install a W2K Server, all default settings.
     2.- Once installed, login as administrator and start Active Directory Wizard.
     3.- Select "Domain Controler", "Create New domain tree", "Create new forest of domains trees", DNS: "blas.com", previous windows version domain name: "BLAS", default location for database & sysvol, DNS is not configured. Would you...?: No I will configure it by my self. Permisions compatible with prewindows 2k servers, "wizard is configuring...etc", Finish (user administrator password typed somewhere in the process, I can't remember exactly where). Ok, so, let's reboot!
     4.- Now we have our AD, we create a user. Start->Programs->AdministrativeTools->ActiveDir Users and computers. Folder Users -> New user, I named her "secondadmin", once correctly created we asign administrative rights, adding her to "Administrators" group. This last step is necesary because the "Only administrator users can login..." security policy (see below).
     5.- Let's go now with the security account policy. Ok, Start->Programs->Admin Tools->Domain Security Policy, Security Settings ->AccountLockoutPolicy->AcountLockThreshold = 3.
     6.- Logoff from the administrator session.
     7.- Login as "secondadmin". This is the reason for the extra step in point 4.
     8.- Lock the computer.
     9.- Type incorrect passwords: one, two, three times... and... weheeee! "Your account is disabled" message box appeard. Ok, ok, I'm not happy about this, but I was worried since you answered, because I would have post a wrong message in a MS group... ;-D
     10.- So, now, we have our domain controler locked, but we have the administrator username and password, so we unlock the computer and we login as the administrator (our "secondadmin" user is still locked).
     11.- Start->Progrms->AdminTools->Users and Comp. Folder Users, secondadmin... and yes, "Account locked out" is checked.
     
     Here it is.
     
     Ok, ok, but this is not a very good test, because we have done this from the AD controler. Let's do it from another wksta joined to our new "blas.com" domain.
     
     12.- We join a W2kProf named "littleblas" to the domain (right click on "my computer", "properties", new domain "BLAS", restart).
     13.- Once littleblas is here again, we login as "secondadmin". I have unchecked previously the "account locked" checkbox in the domain controler.
     14.- We are logged in, so, we lock the computer. Let's see.
     15.- Ok, ok, here we go... crtl+alt+del..., one, two..., two and a half..., and three! Yes, the message is again here! The account is locked. Ok, lets come back to the ADControler... Yes. Yes. The "account locked" checkbox is again checked.
     
     And, yes. I repeat. I agree that this should be the correct behaviour, because if not, I can try another user password, and try, try, try, until I will get the correct one. I think this is the sense of the "account lock threshold" policy, that if a user password is tried X times, the user account will be locked, and so, the attacker will not have the posibility to continue gessing. So, from a security point of view, it's prefectly correct! But then, what is that note about? Am I doing something wrong?
     
     Ok, just now I have tried from a XP joined to the "BLAS" domain, again with secondadmin user, and the user account it has been locked.
     I'm sorry Umit, I don't have a Windows 2003 to test with. Could be a behaviour only for 2003 AD servers?
     
     Thankyou very much.
          
          ----- Umit AKKUS [MSFT] wrote: -----
          
          Are you trying to unlock the machine with a different user than who has
          locked the machine? If so, then the behavior is expected. Otherwise I'm
          unable to reproduce the problem (on XP in WS03 domain) you're talking about
          below. Can you please send precise steps to reproduce the problem?
          
          Thanks
          
          --
          This posting is provided "AS IS" with no warranties, and confers no rights.
          
          Umit AKKUS [MSFT]
          
          
          "JuanMedia" <juanmedia@eresmas.com> wrote in message
          news:15F8CB59-CF39-4474-A3E1-CA4EDA5FCA6A@microsoft.com...
> Hi all,
> I have a quite weird question to ask about the lock user lockout account
> threshold. We have found in the Windows NT, 2K and XP documentation at the
> Technet; and also at the msdn websites, this note:
> "Note: Bad logon attempts to a workstation against a password-protected
> screen saver don't increase the lockout threshold. Similarly, if you lock
> a server or workstation using Ctrl+Alt+Delete, bad logon attempts against
> the Unlock dialog box don't count."
> ...but, oh surprise!, we have tested this against three diferent domains
> (including an old WNT), and the behaviour is exactly the oposite, all
> failed password attempts count as failed logon. In my opinion this is the
> correct way to do the unlocking of a workstation, because if not, it would
> be a higly security risk for the users passwords, obiously. The curious
> thing is that we have found the above note in several places, but we are
> not capable of reproduce that behaviour. In all of our tests we allways
> get the user acount locked.
> Do you know if this is a documentation "mistake"?
> If don't, does someone know how to configure the AD or users workstations,
> to achieve the behaviour the above note says?
>> The note above is at the Technet here (for XP):
> http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/08w2kada.mspx
> The msdn note is here:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gp/507.asp
>> Thankyou very much.