Prev: there was an unexpected error with your zone settings. unable
Next: RecoveryBin
From: Will on 29 Jan 2007 21:31
"Rick" <Rick(a)discussions.microsoft.com> wrote in message
news:2DD53465-6073-4DD9-96FC-5EA0BB75254A(a)microsoft.com...
> Hi Will, this is a member server and the account is a Domain Admin
account,
> not local. If I pull the network cable and reboot, it does not lock my
> account.

So what seems likely is that *something* on this member server is attempting
a connection to your domain controller with the wrong credentials.

On the domain controller, are you auditing failed logins? If not, start
doing so. Are you seeing failed login attempts from this member server
prior to your attempted logins in the security event viewer of the domain
controller? They must be there, because the account does not get locked
out unless you reboot this particular server.

Now the question is where is the program that is entering the bad command
located. Is it possible you have a startup script running on that server
that possibly attempts to copy over files from the server after
authenticating from a command line script with NET USE? Perhaps that
script has hard-coded into it the old password? Have you thought about
scanning all local hard drives for any file that contains the old domain
controller password?

Is there any chance you are logging in as the local administrator and then
attempting to use NET USE with domain administrator credentials?

--
Will


From: Rick on 30 Jan 2007 13:33
Hi Will, thanks for the reply, see responses below:

"Will" wrote:

> So what seems likely is that *something* on this member server is attempting
> a connection to your domain controller with the wrong credentials.

Totally agree.

> On the domain controller, are you auditing failed logins? If not, start
> doing so. Are you seeing failed login attempts from this member server
> prior to your attempted logins in the security event viewer of the domain
> controller? They must be there, because the account does not get locked
> out unless you reboot this particular server.

Yes, and I can see failed login attempts from the member server in question
when I reboot it.

> Now the question is where is the program that is entering the bad command
> located. Is it possible you have a startup script running on that server
> that possibly attempts to copy over files from the server after
> authenticating from a command line script with NET USE? Perhaps that
> script has hard-coded into it the old password? Have you thought about
> scanning all local hard drives for any file that contains the old domain
> controller password?

No startup scripts that are unique to this server. I did upgrade HP's
Insight Manager lately and this could be the cause but I'm not 100% certain.

I scanned all files on the server and the registry for the name of my admin
ID since I would think a password stored in a configuration file or registry
would be encrypted and not stored in plain text. Didn't find anything. I
will scan all files for my old password in a little while.

> Is there any chance you are logging in as the local administrator and then
> attempting to use NET USE with domain administrator credentials?

Nope, I never log in as the local administrator, only a domain admin account.

> --
> Will

Is there anything from the alockout.log that I posted that helps to identify
what might be causing this?

Rick
From: Will on 30 Jan 2007 19:09
Microsoft has a program named MSConfig that will freeze execution of some of
the startup tasks when you login until you give explicit permission for each
to continue. I would selectively start to deselect items from that and
rebooting and keep careful track of the point at which the authentication no
longer takes place.

I would also search your sysvol on the domain controller for any scripts in
any group policy, and you may find one somewhere you didn't know about. I
don't know from memory how to check for a startup script on a computer, but
no doubt there is a registry setting for that and you should look for it.

If you have excluded any startup script, and excluded any scheduled task,
and excluded and startup task that MSConfig can trace, you may have a virus
at work. If the abnormal behavior you see suddenly stops out of the blue
in the next few days I would get particularly concerned since the trojan
could have brute force attacked any locally cached hashes of your new domain
password and broken them, hence no more account lockouts. If I couldn't
account for why this behavior was happening I would want to disconnect this
machine from my network entirely until I had an explanation.

Finally, have you thought about running a sniffer on the computer after it
boots up and check for what ports the machine is trying to reach on your
network. I would be suspect of all SMB activity (destination ports 139 and
445) to machines that are not file servers or domain controllers. With the
computer off the network I would leave a sniffer running for a few days and
sift through the traffic filtering out what is expected and analyzing
carefully what is not.

--
Will



From: Rick on 31 Jan 2007 20:32
Will, thanks for your help. I found out it was the HP Virtual Machine
Manager service (even though the service used a service account to run). I
don't use this software so I uninstalled it - problem solved.

Rick
From: Will on 31 Jan 2007 22:09
"Rick" <Rick(a)discussions.microsoft.com> wrote in message
news:C1EB3C57-679D-49F2-ADF7-C5652E61D69A(a)microsoft.com...
> Will, thanks for your help. I found out it was the HP Virtual Machine
> Manager service (even though the service used a service account to run).
I
> don't use this software so I uninstalled it - problem solved.

Another quality HP software product. :) I still wish for the old Compaq
driver update software they wrote for their workstation product line. HP
software steadily gets worse each new generation. Anyway, glad you found
it.

--
Will


First  |  Prev  | 
Pages: 1 2
Prev: there was an unexpected error with your zone settings. unable
Next: RecoveryBin