Odd bug identified: XP locking out accounts - prevention f..

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.

"Steven L Umbach" wrote:

> 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
>
>
> "dajunke" <dajunke RemoveThis @discussions.microsoft.com> wrote in message
> news:CE078B56-8E40-4407-B829-59A855F4561C@microsoft.com...
> > 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
> >
>
>
>
 >> Stay informed about: Odd bug identified: XP locking out accounts - prevention f.. 

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


"dajunke" <dajunke.TakeThisOut@discussions.microsoft.com> wrote in message
news:0B90C96F-622E-49CE-A1D7-3406E1BF5148@microsoft.com...
> 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.
>
> "Steven L Umbach" wrote:
>
>> 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
>>
>>
>> "dajunke" <dajunke.TakeThisOut@discussions.microsoft.com> wrote in message
>> news:CE078B56-8E40-4407-B829-59A855F4561C@microsoft.com...
>> > 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
>> >
>>
>>
>>
 >> Stay informed about: Odd bug identified: XP locking out accounts - prevention f.. 

"dajunke" <dajunke DeleteThis @discussions.microsoft.com> wrote in message
news:CE078B56-8E40-4407-B829-59A855F4561C@microsoft.com...
> 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.
 >> Stay informed about: Odd bug identified: XP locking out accounts - prevention f..