Security – Lock Workstation Glitch? (AD/Windows XP)

accountspassword-managementSecuritywindows-server-2003

I was playing with a lab setup recently (Windows 2003 R2 x32 SP2, Windows XP SP3, Active Directory) and noticed that if I locked the workstation, the following strange behaviour appeared:

I have a lockout policy that says
that an account is locked after three
invalid attempts. When trying this
when unlocking the workstation, the
workstation correctly says the
account is locked after three invalid
attempts, but it lets me continue
trying passwords. If I eventually
type in the correct password, it
unlocks the workstation.
If I change the user's password while
the workstation is locked, both
the old and new password will unlock
the workstation.
If I disable the user's account while
the workstation is locked, they can
still log in and continue to access
resources.

Is this behaviour correct or just a bug in my setup? Any pointers on how to mitigate this problem?

The attack vector to exploit #1 would be if the hacker has a set list of maybe 200 or so possible passwords based on combinations of the user's birthday, kids names, whatever. They then try each of these passwords, in turn, to see if they are right (maybe using a USB keyboard wedge to automate it).

Because they are not locked out after three attempts, they can keep trying until they get the password. Once they have the password, they just wait for the user to get their account unlocked by the admin, then they can login as the user.

The issue with #2 and #3 would be if, say, someone just got fired and you wanted to prevent them from taking files with them, and disabled their account/changed their password, they could still access the files if their workstation was locked (or I assume if they were already logged into their computer).

Best Answer

I don't believe this is a bug.

The difference is that the account lock out policy applies to new sessions with new auth and login under default circumstances.

In the case of a locked workstation, there's already an active, logged-in session on the box.

This can apparently be changed by the "ForceUnlockLogon" registry setting. Toggling this requires a workstation unlocking to get re-auth from the DC and thereby avoids the use of old, cached credentials.

In the case of a locked LOCAL account in the workstation, you can add the following registry value into HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\policies:

DisablePasswordCaching DWORD 00000001

Quick googling turned up this paper by MS over at sysoptools: http://www.sysoptools.com/support/files/Account%20Passwords%20and%20Policies%20In-Depth.doc

It has details relating to logons, account lockout policy, and discussions of settings that can come into play.

Additional Note re: #3 (also covered in the linked paper): a locked-out user may still gain access if their still-valid kerberos ticket has not expired.

Related Solutions

Security – Is account lockout a denial of service attack waiting to happen

I wasn't aware that this is default behavior, and it is definitely a denial of service waiting to happen. Temporary lockout (or simple slow-down) is usually sufficient to fend off brute force attacks (There's a lot of discussion on this topic, I can remember a few StackOverflow questions dealing with this, more in the area of website logins though). Yes, they're also a potential denial of service, but only for the duration of the attack.

I don't agree completely with Dave Cheney, while you should be concerned with physical security, a disgruntled employee (more often an issue at larger companies than at smaller) and a borrowed (trusted hardware) login-screen is all it takes to lock down vital functions of the company, so I don't believe it to be sufficient.

LDAP Account Locked Out Sporadically after Password change – Finding the source of invalid attempts

Unfortunately there are numerous circumstances where the security event log will event id 680 that look like this and the workstation name will be blank.

680,AUDIT FAILURE,Security,Fri Feb 25 14:29:37 2011,NT AUTHORITY\SYSTEM,Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0    Logon account:  jdoe    Source Workstation:     Error Code: 0xC0000064

One way to expose more information is to enable netlogon verbose logging. On a domain controller(s) where the events are recorded, create the following registry value:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"DBFlag"=dword:24401F04

Restart the netlogon service for this to take effect. The verbose information will be recorded in: %systemroot%\debug\netlogon.log and netlogon.bak. The log file rolls over and is renamed to .bak at around 19 MB. After one of the events, make a copy of the two files from the dc where the event occurred, and open them in a text editor and search for the user's name.

If you're lucky, it will have something like this:

02/12 10:54:39 [LOGON] ACMI: SamLogon: Transitive Network logon of (null)\jdoe from  (via EXCHANGE2) Entered
02/12 10:54:39 [LOGON] ACMI: NlPickDomainWithAccount: jdoe: Algorithm entered. UPN:0 Sam:1 Exp:0 Cross: 0 Root:0 DC:0
02/12 10:54:39 [LOGON] ACMI: NlPickDomainWithAccount: Username jdoe is hq.acme.com\jdoe (found On GC)

Note that if you have multiple domain controllers, when you restart the netlogon service on one, the machine that is making the logon attempts may switch to another dc, so be prepared to enable this on more than one dc. If you have a multi-domain environment with child domains, you may have to track this from a child domain to the root domain and another child domain before the offending machine is located. The offending machine could be anything, it doesn't necessarily have to be a windows workstation. It could be a multifunction network printer/copier, or an email client that is attempting an authenticated SMTP connection with your Exchange server.

Best Answer

Related Solutions

Security – Is account lockout a denial of service attack waiting to happen

LDAP Account Locked Out Sporadically after Password change – Finding the source of invalid attempts

Related Topic