ISS scan account continually locking out

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello Microsoft,

You guys always know the answer.
Please take the time to read this and respond.

Please help me with this; I'm a network administrator with an account
lockout problem. We have an ISS domain account which has administrative
permissions to all the machines on the network. The ISS scanner uses this
account to authenticate to the machine its scanning. For some reason, the
account continually keeps locking out during scanning. Randomly....
I have ruled out all the basics and have even created a separate second ISS
account with the same permissions; this one keeps locking out too. The
Netlogon.log on the DCs shows Transitive Network logons from the machines
it’s scanning. Some successful, some not.

I believe the following are the successful logons...

SamLogon: Transitive Network logon of Domain1\ISSaccount from ISS-Scanner
(via CONFmachine) Returns 0x0

Some of the unsuccessful ones appear as follows

SamLogon: Transitive Network logon of (null)\Domain1\ISSaccount from \\ (via
Confmachine) Returns 0xC0000064

What does the (null) mean?
Also after the from, where you should see ISS-Scanner, all there is are 2
\\??
When I look at these events on the local machine, the source workstation,
where it normally give you the IP or machine name of the remote machine
making the logon request, it also just has the 2 \\?

A few more unsuccessful entries

SamLogon: Transitive Network logon of (null)\ISSaccount from \\ (via
Confmachine)Returns 0xC000006A

Here the entry doesn't even list the domain name before the user account,
just the (null) and still lists the FROM machine as just \\. However it still
returns a 0xc06A error which means bad password.
By the looks of it, shouldn't it come back with unknown username?

Eventually the log fills up with 0x00000234 when the account finally locks out

Does anyone know?
What the (null) means?
Why the FROM is listed as only \\
Why the account is locking out

PLEASE. ANY HELP WOULD BE GREATLY APPRECIATED.
 
The two ?? usually means that the message may not have resolved where this
was coming from-locally, or externally via the redirector. Null entries can
be passed from legacy clients (like Windows 9x) or non-domain member
computers. On the face of it I would not be terribly concerned about the
additional field data in your netlogon log-the meat and potatoes is in the
resulting codes you are seeing (below).

The codes you are seeing in the netlogon.log map to:

0xC000006A User logon with Misspelled or bad Password
0xC0000064 User logon with Misspelled or Bad User Account
0xC0000234 User logon with Account Locked

The info above is documented in:
Using the Checked Netlogon.dll to Track Account Lockouts
http://support.microsoft.com/default.aspx?scid=kb;en-us;189541&sd=tech

The most likely reason the accounts are locking out is that the ISS
application is testing the complexity of your user passwords by sending bad
password attempts using common weak passwords. I'm not familiar enough with
ISS' product to say for sure, but this is a typical behavior for security
strengthening or reporting software packages.

To verify that the account lockouts are definetly coming from the ISS
application you can use the excellent troubleshooting tool Alockout.dll
(installed on the client machines this is occuring on):
Account Lockout and Management Tools
http://www.microsoft.com/downloads/...9C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en

This will create a log file with Process ID and image name (essentially
executable) that is causing the account lockouts. Of course, you may need
to wait for them to recur.

If you are already certain that the ISS application is the cause, or later
identify it for certain (and it is worth your time to make sure) then you
may want to contact ISS for details on why that product is doing what it's
doing, and whether that is expected behavior.

Please repost if we can assist further.

--

Tim Springston
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
 
The two ?? usually means that the message may not have resolved where
this was coming from-locally, or externally via the redirector. Null
entries can be passed from legacy clients (like Windows 9x) or
non-domain member computers. On the face of it I would not be
terribly concerned about the additional field data in your netlogon
log-the meat and potatoes is in the resulting codes you are seeing
(below).

The codes you are seeing in the netlogon.log map to:

0xC000006A User logon with Misspelled or bad Password
0xC0000064 User logon with Misspelled or Bad User Account
0xC0000234 User logon with Account Locked

The info above is documented in:
Using the Checked Netlogon.dll to Track Account Lockouts
http://support.microsoft.com/default.aspx?scid=kb;en-us;189541&sd=tech

The most likely reason the accounts are locking out is that the ISS
application is testing the complexity of your user passwords by
sending bad password attempts using common weak passwords. I'm not
familiar enough with ISS' product to say for sure, but this is a
typical behavior for security strengthening or reporting software
packages.

To verify that the account lockouts are definetly coming from the ISS
application you can use the excellent troubleshooting tool
Alockout.dll (installed on the client machines this is occuring on):
Account Lockout and Management Tools
http://www.microsoft.com/downloads/details.aspx?FamilyID=7AF2E69C-91F3-
4E63-8629-B999ADDE0B9E&displaylang=en

This will create a log file with Process ID and image name
(essentially executable) that is causing the account lockouts. Of
course, you may need to wait for them to recur.

If you are already certain that the ISS application is the cause, or
later identify it for certain (and it is worth your time to make sure)
then you may want to contact ISS for details on why that product is
doing what it's doing, and whether that is expected behavior.

Please repost if we can assist further.
Click to expand...

I've run into the same problem on another scanner. I believe it is caused
by having local user accounts that are the same as domain accounts. It's
not from the password checker/cracker. I believe it's being caused by one
of the NTLM auth checks.

TEP
 
Back
Top