Odd bug identified: XP locking out accounts - prevention found!

[Guest]

We have been researching why our admin accounts have been locking themselves
out on a daily basis and we finally found the answer!

The problem arises out of mapped drives that were created with a different
ID than the ID used to logon to the workstation.

What happens is that XP tries to re-establish these connections on logon
without knowing the password (or possibly trying the password used to sigon
to the desktop .. which likely does not match).

Since the connection fails, 1 attempt out of an allowed 6 attempts has been
utilized and the ID is now closer to being locked-out.

This sounds like an XP bug .. it should not try to logon to a connection
without a password when it (XP) knows it is not saving any password
information.

Unti this is resolved, I suggest never selecting auto-connect when mapping a
network drive with credentials that differ from the ones used to signon to
the desktop.

Windows NT did not do this .. it prompted the user with logon prompts during
signon and the user could choose to logon or cancel the connection.

Your welcome in advance

 

[Steven L Umbach]

There are more than a few ways that can generate multiple failed logons when
wrong credentials are used. I believe last time I checked Microsoft
recommends that IF you use account lockout that your set the threshold to 50
bad attempts [though some are bound to much lower threshold due to some sort
of regulation]. That will prevent a lot of innocent denial of service
disruptions while still providing protection when at least reasonably strong
passwords are being used. In your case you can check the security log of the
computer that contains the share and look for type 3 failed logon attempts
and it should show the user account being used for the attempted logon to
the share. Another issue with XP Pro computers is stored credentials for a
remote computer/share that do not get updated when user changes password.

Steve

 

[Guest]

So if I understand you correctly Microsoft is already aware of this problem
or doesn't look at it like a problem. Thanks for your comments.

There are more than a few ways that can generate multiple failed logons when
wrong credentials are used. I believe last time I checked Microsoft
recommends that IF you use account lockout that your set the threshold to 50
bad attempts [though some are bound to much lower threshold due to some sort
of regulation]. That will prevent a lot of innocent denial of service
disruptions while still providing protection when at least reasonably strong
passwords are being used. In your case you can check the security log of the
computer that contains the share and look for type 3 failed logon attempts
and it should show the user account being used for the attempted logon to
the share. Another issue with XP Pro computers is stored credentials for a
remote computer/share that do not get updated when user changes password.

Steve

We have been researching why our admin accounts have been locking
themselves
out on a daily basis and we finally found the answer!

The problem arises out of mapped drives that were created with a different
ID than the ID used to logon to the workstation.

What happens is that XP tries to re-establish these connections on logon
without knowing the password (or possibly trying the password used to
sigon
to the desktop .. which likely does not match).

Since the connection fails, 1 attempt out of an allowed 6 attempts has
been
utilized and the ID is now closer to being locked-out.

This sounds like an XP bug .. it should not try to logon to a connection
without a password when it (XP) knows it is not saving any password
information.

Unti this is resolved, I suggest never selecting auto-connect when mapping
a
network drive with credentials that differ from the ones used to signon to
the desktop.

Windows NT did not do this .. it prompted the user with logon prompts
during
signon and the user could choose to logon or cancel the connection.

Your welcome in advance

 

[Steven L Umbach]

I tend to believe that Microsoft does not look at it like a problem which I
know does not help you out but I seriously doubt they are working to change
the behavious. Thanks for sharing your findings with the group as account
lockouts can be a pain to track down.

Steve

So if I understand you correctly Microsoft is already aware of this
problem
or doesn't look at it like a problem. Thanks for your comments.

There are more than a few ways that can generate multiple failed logons
when
wrong credentials are used. I believe last time I checked Microsoft
recommends that IF you use account lockout that your set the threshold to
50
bad attempts [though some are bound to much lower threshold due to some
sort
of regulation]. That will prevent a lot of innocent denial of service
disruptions while still providing protection when at least reasonably
strong
passwords are being used. In your case you can check the security log of
the
computer that contains the share and look for type 3 failed logon
attempts
and it should show the user account being used for the attempted logon to
the share. Another issue with XP Pro computers is stored credentials for
a
remote computer/share that do not get updated when user changes password.

Steve

We have been researching why our admin accounts have been locking
themselves
out on a daily basis and we finally found the answer!

The problem arises out of mapped drives that were created with a
different
ID than the ID used to logon to the workstation.

What happens is that XP tries to re-establish these connections on
logon
without knowing the password (or possibly trying the password used to
sigon
to the desktop .. which likely does not match).

Since the connection fails, 1 attempt out of an allowed 6 attempts has
been
utilized and the ID is now closer to being locked-out.

This sounds like an XP bug .. it should not try to logon to a
connection
without a password when it (XP) knows it is not saving any password
information.

Unti this is resolved, I suggest never selecting auto-connect when
mapping
a
network drive with credentials that differ from the ones used to signon
to
the desktop.

Windows NT did not do this .. it prompted the user with logon prompts
during
signon and the user could choose to logon or cancel the connection.

Your welcome in advance

 

[VanguardLH]

We have been researching why our admin accounts have been locking
themselves
out on a daily basis and we finally found the answer!

The problem arises out of mapped drives that were created with a
different
ID than the ID used to logon to the workstation.

What happens is that XP tries to re-establish these connections on
logon
without knowing the password (or possibly trying the password used
to sigon
to the desktop .. which likely does not match).

Since the connection fails, 1 attempt out of an allowed 6 attempts
has been
utilized and the ID is now closer to being locked-out.

This sounds like an XP bug .. it should not try to logon to a
connection
without a password when it (XP) knows it is not saving any password
information.

Unti this is resolved, I suggest never selecting auto-connect when
mapping a
network drive with credentials that differ from the ones used to
signon to
the desktop.

Windows NT did not do this .. it prompted the user with logon
prompts during
signon and the user could choose to logon or cancel the connection.

Your welcome in advance

Rather than using mapped drives (to a drive letter which then, by
default, attempts to reconnect to that drive when you login), try
using UNC paths to the file destination (i.e., \\hostname\path\file).
Then you only connect at the time you actually access the file, not by
having a drive designator active all the time and which may have
problems maintaining that connections (there are network outages,
sometimes due to long delays when super busy). It is the same UNC you
use when defining the mapping to a drive designator. Only if your
application can't handle UNC paths are you stuck with using a drive
letter. If you must have a drive letter, do you really need it
*connected* when you login, or do you need it later when you actually
use a file from there? If you can connect later, don't enable the
"Reconnect at logon" option when defining the mapping.

A mapped drive that is too busy to respond or dead, or a busy network,
can make booting Windows excruciatingly slow when waiting for all
those timeouts. Alternatively, if YOU don't need the mapped drive
(versus needing it for some program that also starts when Windows
loads) until a little latter, even if a couple minutes later, then use
the "net use" command as an event in Task Scheduler where the event
runs on login. After all, if you have a software firewall running on
the host which has enabled an option to disable all network
connections until the firewall has fully loaded then whether or not
you get the mapped drives depends on which happens first: the firewall
comes up first or the mapping gets done first.