Re: Prevent User Account Lockouts Caused By Transitive Network Log



Mygposts <Mygposts@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
It seems that the response to the question went off the topic.

You're right; my apologies.

Would raising the account lock threshold do anything about the
account being locked by pass-through authentication? Does pass
through authetication only attempt authentication a fixed number of
times and then eventually present the user with a login box or will
it be continous and unlimited (meaning the account would still
eventually lock out even with a higher threshold)?
Is there any way to disable pass-through authentication on a Windows
2003 domain?

No, not that I'm aware of. Marcin's 2nd post contained a suggestion that
might work for you, though.

If you have two domains, I'd set up a trust between them. Or, at least, set
them up with identical usernames & passwords so this is a non-issue.

"Lanwench [MVP - Exchange]" wrote:

Mygposts <Mygposts@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
1000??

Well, something high anyway. Most companies with sense aren't
worried about actual *users* doing this - they're worried about
automated attacks.

Previous places only allowed 3
5 is the corporate policy here. If it doesn't work the first time,
check the CAPs lock. If it doesn't work the second time, type more
carefully. If it still doesn't work, try 2 alternate passwords it
might be. That's 5 tries and if it still doesn't work, then that
means you don't know what it is and need it reset.


Well, that will keep your helpdesk folks busy - job security :-)

What we would like is an authentication pop up so it doesn't even
attempt to use their pass-through authentication or else only tries
pass-through authentication once and if it fails, pop up a
credentials entry box instead of continuing to push the bad password
through, locking the account.
Why can it not check the both the domain and the user name since it
is domain recources?
Can this be done?

I doubt it. Certainly not with anything built in.


"Lanwench [MVP - Exchange]" wrote:

Mygposts <Mygposts@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
There 5 trys before it locks.

That's too little, IMO. If you really must use account lockout, you
should set it to something very high - like, say, 1000 - because
what you really want to prevent is automated attack, not a user
mistyping his password after a long vacation.

So, it is apparently silently
submitting their local credentials over and over again until the
account locks instead of popping up a login prompt.
Is there some way to make our domain controllers check for both
the domain name and the username when receiving credentials?
domain1\jsmith's account should not be able to lockout
domain2\jsmith's account.
Is there another solution.
The domain controllers are all Server 2003.

"Marcin" wrote:

What's your account lockout threshold setting in the Default
Domain Policy GPO of your domain? You might want to consider
increasing this value - while the prompt in case of password
mismatch is expected, the immediate lockout is a bit surprising.
Do you happen to run Windows Server 2000 SP3 on your domain
controllers? If so, refer to
http://support.microsoft.com/kb/264678

hth
Marcin

"Mygposts" <Mygposts@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:47CFA2BA-6433-475B-9248-1E26E39B1C8C@xxxxxxxxxxxxxxxx
We have users on other domains who connect to shares on our
domain. They may sometimes have the same user names, but a
different password.
When users on the other domain who also happen to have the same
user name on
both domains get links to shares on our domain, instead of being
prompted for
authentication credentials, their password from the other domain
profile gets
passed through to us used against an account with the same user
name on our
domain. This instantly locks out the account on our domain.
Is there any way to prevent this other than having them choose
the same password on both accounts or having to get one of the
user names renamed so
the don't match?
There is not going to be a domain trust set up that allows them
to access our resources with their domain's user account.



.