locked
Interactive logon: Machine account lockout threshold RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Using Win10 1511 Ent with the TH2 Baselines applied.  One of these baselines sets the following:

    Interactive logon: Machine account lockout threshold 10 invalid logon attempts


    This is fine but we are occasionally seeing users come back to the their locked computer, entering their password incorrectly once and then it immediately reboots and locks out.

    It doesn't seem to be reproducible easily.  Any ideas out there as to what may cause this?  Is there anyway to view the bad logon counts? 

    Tuesday, July 12, 2016 12:38 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Alan,

    think this is the wrong place for your question. Here we discuss Bitlocker and MBAM stuff ;-)

    /Oliver

    Tuesday, July 12, 2016 1:02 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Alan,

    think this is the wrong place for your question. Here we discuss Bitlocker and MBAM stuff ;-)

    /Oliver

    Hi Oliver,

    Machine account lockout threshold is a Bitlocker setting which locks you out of the machine after a number a unsuccessful logon attempts so I beg to differ!

    Beginning with Windows Server 2012 and Windows 8, the Interactive logon: Machine account threshold security policy setting enforces the lockout policy on those computers that have BitLocker enabled to protect operating system volumes.

    The security setting allows you to set a threshold for the number of failed logon attempts that causes the computer or device to be locked by using BitLocker. This means, if the specified maximum number of failed logon attempts is exceeded, the device will invalidate the Trusted Platform Module (TPM) protector and any other protector except the 48-digit recovery password, and then reboot. During Device Lockout mode, the computer or device only boots into the touch-enabled Windows Recovery Environment (WinRE) until an authorized user enters the recovery password to restore full access.

    Failed password attempts on workstations or member servers that have been locked by using either Ctrl+Alt+Delete or password-protected screen savers count as failed logon attempts.

     


    Tuesday, July 12, 2016 1:22 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Alan, I considered to use that in our company and all tests (on win10 1511 as well) went just as you'd expect. Never did the two test machines lock too early.

    That said, could it be that fellow workers are playing a trick on others by entering the password incorrectly 9 times while the computer is left locked but unattended? I am not sure how long it will take to reset that lockout threshold.

    Also please consider: what would you gain using that setting? Attackers don't hammer passwords into the logon mask. At least no attackers that one should fear. The measure is more of the "wow, look what our almighty admin has configured"-kind. Just lock the user account, that is perfectly enough.

    Wednesday, July 13, 2016 11:12 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I've checked the security event log and there are no failed logon requests for the user who has the machine locked prior to Bitlocker kicking it and locking out.  If you manually reproduce it by entering the wrong password on the lock screen it also warns you when you get close to 10 that it will lock the system.

    It is a very valid setting to use when you have sensitive data stored on workstations/laptops which are using TPM only for BitLocker.  If you lose a laptop which is only protected by TPM then it is possible to attempt to brute force the account on the CTRL-ALT-DEL screen.  With this setting in place after 10 attempts you can no longer even boot to logon screen without a BitLocker recovery key.  This is why it is part of the BitLocker baseline.

    Thursday, July 14, 2016 8:37 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Alan,

    what security event log did you look at? For domain accounts it needs to be the one at the domain controllers.

    As for doing it/not doing it at all: brute forcing at the logon prompt is impossible. Try to enter 1000 passwords and take the time. That will be almost one day because every few attempts windows waits for some time to prevent pw hammering. If your passwords are complex and reasonably long, there is no way for brute forcing them this way.

    Thursday, July 14, 2016 9:00 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Alan,

    what security event log did you look at? For domain accounts it needs to be the one at the domain controllers.

    As for doing it/not doing it at all: brute forcing at the logon prompt is impossible. Try to enter 1000 passwords and take the time. That will be almost one day because every few attempts windows waits for some time to prevent pw hammering. If your passwords are complex and reasonably long, there is no way for brute forcing them this way.

    Hi, yes I appreciate that but if you work in an environment which requires high levels of compliance you will find that you have no option but to enable that GPO setting to lockout after 10...

    Unlocking of a machine does not require a DC (unless you have configured that) so incorrect password attempts are logged locally.

    Thursday, July 14, 2016 9:03 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I work as sysadmin for a company working in the defence sector and here, we have many things to fulfill, but that was not one of them, but it was considered.

    Incorrect password attempts of domain accounts are not logged locally, no matter if connected to the domain or not - just tried. Or does that change when your policy is set? I guess it does not, let me try.

    Anyway: what I could give you is only my experience and here, it worked as expected (thoroughly tested on 2 machines).

    Thursday, July 14, 2016 9:10 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Set the policy, retried, no, password mistakes are not logged locally for my domain account and yes, it works as expected. Set it to 5, entered the pw wrongly 3 times, saw a warning on the logon screen, but no lockout before 5 times.
    Thursday, July 14, 2016 9:18 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Set the policy, retried, no, password mistakes are not logged locally for my domain account and yes, it works as expected. Set it to 5, entered the pw wrongly 3 times, saw a warning on the logon screen, but no lockout before 5 times.

    I guess it will depend on your policy for event logging.  Simple test on my workstation:

    Lock machine

    Go to unlock

    Enter password incorrectly

    Event ID 4625 logged in the local security log.

    Thursday, July 14, 2016 9:56 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    The audit policy was configured. Nothing logged. Only logs local account logon mistakes.
    Thursday, July 14, 2016 10:01 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi together,

    we have the same problem in our environment.

    - Windows 10 1511

    - MBAM 2.5

    - Machine account lockout threshold = 10

    - TPM 1.2

    Our tests have shown the following behavior:

    - 5 wrong Passwords -> AD-User lockout -> reset Account

    - 1 successful  Login -> logoff

    - 3 wrong passwords -> Bitlocker Warning

    - 1 successful  Login -> logoff

    - 1 wrong passwords -> Bitlocker Warning

    - 1 wrong passwords -> reboot and recovery page

    But not all Clients have this behaviour. The other Clients working fine, after a successful  Login it is possible to try again 10 times. But so far we are not able to find the different.

    Anyone have any idea?

    Regards

    Marcus

    Friday, July 29, 2016 2:17 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    To diagnose, please use procmon to monitor where this bad logon counter is kept, so we can see if the counter is being reset (as expected) when a successful logon happens.
    Monday, August 1, 2016 7:11 AM
  • Question
    Sign in to vote
    2
    Sign in to vote

    Hi together,

    we fixed the issue with Bitlocker and Windows 10 1511. The problem was an entry in our security policy:

    "Windows Settings" - "Security Settings" - "Local Policies/User Rights Assigment"

    "Access this computer from the network" - "BUILTIN\Administrators"

    After insert the "NT AUTHORITY\Authenticated Users" again, Bitlocker works correctly.

    Best Regards Marcus

    • Proposed as answer by Bisco05 Friday, August 5, 2016 6:00 AM
    Friday, August 5, 2016 6:00 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi together,

    we fixed the issue with Bitlocker and Windows 10 1511. The problem was an entry in our security policy:

    "Windows Settings" - "Security Settings" - "Local Policies/User Rights Assigment"

    "Access this computer from the network" - "BUILTIN\Administrators"

    After insert the "NT AUTHORITY\Authenticated Users" again, Bitlocker works correctly.

    Best Regards Marcus


    Interesting.  My standard user account is already in a group which is part of the "Access this computer from the network" setting, so in my case I wouldn't think that this is the issue... 
    Wednesday, August 10, 2016 1:48 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Marcus & Alan,.

    Thank you for your comments on this thread.  I believe Marcus' solution is valid, and has resolved my issue.  My policy for 'Access this computer from the network' was in line with the secuity baseline for TH2 (MSFT 10 setting).  Adding Authenticated Users (in line with prior MSFT 8.1 recommendation) fixed immediately.  The machine account lockout counter now resets correctly after a successful user logon.

    As a secondary observation, the text displayed in Event ID 1103 and 1102 relating to the bitlocker warnings and lockout are incorrect, specifically the output for UserName and UserDomain are swapped (this was acknowledged during premier support ticket as a known issue).  Also with these events, I found that before I added Authenticated Users to the policy, the UserSid field showed as SYSTEM, not the domain\username.  This initially threw me off course as it suggested the Local System was possibly incrementing the machien account lockout counter, not an actual bad password attempt by a user.

    Regards,

    Brett

    • Edited by Brett Q Wednesday, August 31, 2016 4:54 AM issue resolved
    Tuesday, August 30, 2016 6:05 AM