the name of the machine that
the user was attempting to logon from at the time of
the
lockout. If those computers
are on your network, you need to find out why they are
trying to logon as your users,
such as a virus infection. If they are not from your
network then how are they
getting access? You said your firewall is configured
correctly? Is your firewall
allowing any access from the internet such as a web
site,
vpn, or Terminal Services?
The event ID displays what user is locked out and from
what machine but if you can
find any failures for logons on any domain machine such
as 681 or 529, that would be
helpful as it will help determine what domain computers
are being targeted for these
failed logon attempts and then you could use a packet
sniffer such as Ethereal to
monitor the traffic from the machine causing the
lockout
to possibly help determine
what is going on.. --- Steve
in
message
Hi Steve and serverguy
Great help!
Yes i did a netdiag and seems ok but dcdiag generated
some
errors: one of which: "[warning] The DNS host
name 'xxx'
valid only on Windows 2000 DNS servers. [DNS_ERROR-
NON-
RFC_NAME], [WARNING] Cannot find a primary
authoriatative
DNS server for the name 'xxxx' may not be registered
in
DNS"
Managed to read up some issues and rerun dcdiag and
cleared all the erros. Still my accounts get locked
out.
The worst is my event log from eventcomp shows that
my
valid users are being locked out by all sorts of
foreign
manchine name, one of which is this:
644,AUDIT SUCCESS,Security,Fri May 21 16:06:46
2004,NT
AUTHORITY\SYSTEM,User Account Locked Out: Target
Account Name: "valid user id" Target Account ID:
%
("numbers") Caller Machine Name: ANGEL Caller
User
Name: "my servername"$
The Caller Machine Name: Angel is a remote machine
name
in
my network. I have no idea what is that! A few others
Caller Machine Name are PROXYSRV, GNSERVER,
SERVIDOR ..??
what are those!?. Am trying to scan all my users for
virus
now.
Thanks for helping !
Regards
Liew
-----Original Message-----
Event ID 642 will be recorded with every Event ID
644 -
-
that is normal. If you want
to modify password/lockout policy you have to do it
at
the domain level which would
be "Domain Security Policy" in a default
installation -
it will NOT work if you do it
in Domain Controller Security Policy.
Have you found any failed logon event ID's on any
domain
computer? That is the place
to start to track down the problem to see if you
have
an
infected machine or what.
The error for ,***StartServiceW Failed!*** would
only
be
pertinent if you found that
on a computer experiencing account lockouts AND the
lockout time corresponded to the
time for that event in the alockout.dll log.
Have you had a chance to run netdiag and dcdiag on
the
domain controller and netdiag
on a domain client? If so did the results look good
or
were there any reported
problems? --- Steve
"Merrick" <anonymous@discussions.microsoft.com>
wrote
in
message
Hi Steve,
You have been a great help! I really appreciated
it.
As
to
my problem:
1.) I have disabled my accounts lockout policy in
my
domain contoller security policy but i still get
accounts
locked out, yes the administrator is always locked
out.
2.) I have included 644 and 642 in my eventcomb
and
for
every 644 i got one 642. MS provide very little
information on 642 and am still trying to gather
information on that. it seems like my secure
channel
is
leaking.
3.) I have also planted alockout.dll in one of my
clients
and one particular line is worrying me:
C:\WINNT\system32
\svchost,***StartServiceW Failed!*** (0), Service:
Service: Background Intelligent Transfer Service
(C:\WINNT\System32\svchost.exe -k BITSgroup), RC
was:
Incorrect function. (1), GLE was: Overlapped I/O
operation is in progress. (997): Any comment?
Hope you can help! Many Thanks in advance!
-----Original Message-----
Hi again Merrick.
If you have not done such, set your account
lockout
threshhold for number of
bad attempts to at least ten. You should be
seeing
failed
logon attempts
such as Event ID 529 on some computers in the
domain.
These failed logons
could be on any computer in the domain - not just
domain
controllers. Be
sure you have auditing of "logon events" for
failure
which is different than
account logon events enabled in Domain Security
Policy
and Domain Controller
Security Policy. You may also need to configure
it
at
the
OU level if you
are using Organizational Units with their own
Group
Policies that have
auditing disabled. You can check the Local
Security
Policy of any domain
computer and look at the "effective" settings for
auditing to see if it is
enabled. Those failed logon events will give a
lot
of
helpful info on why
the logons are failing and from what computers
the
logon
attempts are coming
from.
In addition I would run some diagnostics on the
domain
controller and then a
couple domain computers. First run netdiag on the
domain
controller looking
for any failed tests/errors/warnings
particularly
relating to dns, domain
membership, and dclist. Then run dcdiag on the
domain
controller looking for
failed tests again. After that do the same with
netdiag
on one of the domain
members. On the domain controller and domain
member
run "
netdiag
/test:ipsec " which will show if an ipsec policy
is
assigned that can cause
problems in a domain. You can post results here
in a
reply if any problems
are found. Those tools are found on the install
cdrom
in
the support/tools
folder where you will need to run the setup
there. --
Steve
"Merrick"
