Administrator account disabled but still get "incorrect password" errors in Event log

Hi all,

I have disabled the Administrator account on a standalone remote Web server
that we lease from a hosting company. There have been occasional failed
attempts at logon by, I presume, a hacker. I have also disabled Teminal
Services login for that account so I am not sure how the hacker is even
getting to the point of attempted login. The IIS server does use Windows
Authentication, however, and I am reading up on security for IIS. I am a
mere programmer that has been thrown into the role of also securing the
server that our application runs on.

Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon account: administrator
Source Workstation: 51WEB-83
Error Code: 0xC000006A

What I don't understand, besides the source of the attempts themselves, is
that the error message being generated indicates an "incorrect password"
instead of a "disabled account".

Would this be expected as some sort of error hierarchy? If the hacker gets
the password wrong then the "incorrect password" code is generated and if by
chance the correct password is entered then the "disabled account" code
would be thrown?

Thanks for any clarification on this issue. In Computer Management/Users the
Red X of a disabled account clearly shows up on the built-in administrator
account. That was why I questioned the actual error message in the Security
tab of the event viewer.

Thanks to all...

 

a few comments in-line...

Maybe, maybe not. What, specifically, suggests to you that this is evidence
of an attempted hack?

The account is not allowed to logon via terminal services, but, imho, there
is no setting that makes it impossible for the account to be used to attempt
to logon. In the event of a non-disabled account attempting such a logon,
that account would first have to get to the point of being authenticated so
that the system will know that the account is one whose logons are not
allowed.

IMHO, the system does not really know the account it is dealing with until
it has been authenticated.

Perhaps something like that, however, I think it is simply inherent in the
authentication process. Policies cannot be applied to an account until the
system knows that the session actually belongs to that account, not just
because someone typed the name in the username field.

I know that when I try a remote desktop logon with an account that is not
allowed to logon that way, or directly to a server the account is not
allowed to logon to, I am not advised of those restrictions until I prove I
am the owner of the account by giving the correct password. Would it make
sense for the authentication mechanism to do otherwise?

Try doing some testing with a non-admin test account to see what is logged
in the various scenarios. Also, try connecting to a share on the server
using the credentials of the test account and the wrong password. I suspect
that that would result in a log entry, and that the failed logon attempt
counter in AD would be incremented, whether or not the account was disabled
or not allowed to map to that share.

Also, consider that if things worked they way you seem to assume, the
security logs would give you less information than you are getting now.

/Al