Re: Accounts gettng locked out

From: Karl Levinson [x y] mvp (levinson_k@excite.com)
Date: 01/03/03 

From: "Karl Levinson [x y] mvp" <levinson_k@excite.com>
Date: Fri, 3 Jan 2003 14:25:42 -0500

"Steve Cobb" <stevec@computer-geeks.com> wrote in message
news:052c01c2b344$92330380$cef82ecf@TK2MSFTNGXA08...
> I have a 2000 Domain Controller with mostly XP
> workstations. I have some accounts that get continually
> locked out. How can I track where this is coming from?
> There are no services logging on as users. The event log
> is somewhat cryptic to follow.

I think the best way to detect what is locking out an account is to enable
"Logon - Failure" auditing on all the Windows Domain Controllers, then check
the Windows Security event logs on the DCs [or maybe it's already enabled?].
If it isn't already enabled, then this might require a reboot of the domain
controllers [especially if the controllers are Windows NT].

Doing this won't capture the IP address of the machine doing the logging in,
but it should hopefully capture the Netbios name of that computer, and then
the command NBTSTAT -a COMPUTERNAME will sometimes give up the current IP
address.

You may not want to enable auditing of "Logon - Success" since some Success
events can fill up your Security log quickly.

Personally I think the most common cause for this happening is usually
something less sinister:

- being logged in at two machines at once and changing your password on one
of them;
- having a drive manually mapped within Windows [e.g. using Explorer instead
of a login script to map drives] and then changing your password;
- having a Windows service on a computer or server that is set to use your
login ID and an old password in the service properties.
- someone trying to log into a machine where Jason was the previous one to
log in, without that person noticing that the cached login ID is not their
own.

If auditing isn't a possibility, some sniffers such as the Network Monitor
program that comes with Windows might understand NetBIOS enough to give you
information about where this is coming from, but I still think auditing is
the best and most typical way to go.
http://securityadmin.info/faq.htm#sniffer for more info, if you want to
pursue this route.

Articles on enabling auditing are at:

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q157238> [NT]
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q300958> [2000,
monitoring for unauthorized user access]
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q300549> [2000]
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q248260> [2000]
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q310399> [XP]

http://www.microsoft.com/technet/security/bestprac/bpent/sec3/monito.asp
http://www.microsoft.com/technet/security/prodtech/windows/windows2000/stays
ecure/secops06.asp>
http://www.labmice.net/troubleshooting/EventLog.htm>
http://nsa1.www.conxion.com/win2k/download.htm> a.k.a. <http://www.nsa.gov>
[e.g. the NSA Security Recommendation Guides for Windows 2000 and also Group
Policy]
http://csrc.nist.gov/itsec/guidance_W2Kpro.html>
http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/
13w2kadc.asp>
http://www.microsoft.com/technet/columns/security/askus/aus1101.asp>

Relevant Pages