B
Bill B
We have an interesting situation,
windows 2000 client not on domain.
windows 2000 domain
It happens when a user connect via a vpn client to our internal network.
their initial login works perfectly, the concentrator authenticates them
against a DC with their domain account and password, and all is well. But
as soon as a user tries to access a local resource, such as a shared folder.
The client attempts to authenticate against the resource by passing its
local/account information.
If I attempt to access a resource on a domain controller, I get a small
delay, and then am successful.
But if i look in the security audit log, i see that i had 22 failure
messages where the vpn connected system tried to authenticate using its
local account credentials. it looks like I am getting 2 error messages per
attempt, so i believe it is trying 11 time with the wrong account. It then
magically figures out it was using a the wrong account and uses the the
correct domain account and credentials and is successful. I receive no
prompts for passwords during any of this.
This causes us multiple problems:
1. If a users password on their remote system is the same as thier domain
password, then the authentication against the domain controller will be
successful on the first try, but the user will have authenticated against
the domain using thier local account, and therfore will not have access to
any of the shares in DFS that do not reside on a DC. DFS, isnt smart enough
to prompt for a password, so they basically will have to connect
individually to each system to deliver the correct domain credentials
2. I had to bump up the account lockout threshold from 5 to 16 in order to
keep the 11 bad attempts from locking the account. I am not confident that
this number 11 is an accurate number, or why these attemps are continuing,
so bumping it up to 16 only fixes the lockout problem for how it manifests
on this specific system, but untill i know what causes these attempts and
how the number is determined, accounts will still probably get locked out.
It also pretty much defeats the purpose of a lockout policy.
Can anyone give an explaination of why this occurs this way, and
suggestions for a workaround?
windows 2000 client not on domain.
windows 2000 domain
It happens when a user connect via a vpn client to our internal network.
their initial login works perfectly, the concentrator authenticates them
against a DC with their domain account and password, and all is well. But
as soon as a user tries to access a local resource, such as a shared folder.
The client attempts to authenticate against the resource by passing its
local/account information.
If I attempt to access a resource on a domain controller, I get a small
delay, and then am successful.
But if i look in the security audit log, i see that i had 22 failure
messages where the vpn connected system tried to authenticate using its
local account credentials. it looks like I am getting 2 error messages per
attempt, so i believe it is trying 11 time with the wrong account. It then
magically figures out it was using a the wrong account and uses the the
correct domain account and credentials and is successful. I receive no
prompts for passwords during any of this.
This causes us multiple problems:
1. If a users password on their remote system is the same as thier domain
password, then the authentication against the domain controller will be
successful on the first try, but the user will have authenticated against
the domain using thier local account, and therfore will not have access to
any of the shares in DFS that do not reside on a DC. DFS, isnt smart enough
to prompt for a password, so they basically will have to connect
individually to each system to deliver the correct domain credentials
2. I had to bump up the account lockout threshold from 5 to 16 in order to
keep the 11 bad attempts from locking the account. I am not confident that
this number 11 is an accurate number, or why these attemps are continuing,
so bumping it up to 16 only fixes the lockout problem for how it manifests
on this specific system, but untill i know what causes these attempts and
how the number is determined, accounts will still probably get locked out.
It also pretty much defeats the purpose of a lockout policy.
Can anyone give an explaination of why this occurs this way, and
suggestions for a workaround?