Pass Through Authentication chooses wrong user account on remote server??

Weird one. If you're inclined to help, you may want to draw a picture. :)

2 Servers:

Mars (Windows 2003) has two local accounts, AccountA and AccountB, both
local administrators.
Pluto (Windows 2000) has two local accounts, also named AccountA and
AccountB, both local administrators.

Both servers are member servers (not DCs) on the same mixed mode 2003
domain.

The passwords for AccountA and AccountB are the same on both servers
(respectively), for the purpose of pass-through authentication.

I log in to Mars locally with AccountB, and UNC to \\Pluto\c$ at the run
command, expecting the local AccountB on Pluto to be used to access the
shared resource. I get the message that it is not accessible, and that the
referenced account is currently locked out and may not be logged on to.
When I check the security log on Pluto, I see that instead of it using the
local AccountB account to access the share (as I would expect pass-through
authentication to do), it is instead using AccountA (even though I was
logged in with AccountB on Mars). This happens not just with the default
shares, but any share AccountB has access to.

Any idea why Pluto would attempt to use the opposite account when logically
it should grab the one with the same name as what I'm logged into Mars with?

If I do everything the same, except log in with AccountA, everything works
fine.

Any thoughts appreciated!!

Phil

Logs from Pluto:

Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 681
Date: 09/05/2006
Time: 11:34:04 AM
User: NT AUTHORITY\SYSTEM
Computer: Pluto
Description:
The logon to account: AccountA
by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
from workstation: Mars
failed. The error code was: 3221226036

and:

Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 539
Date: 09/05/2006
Time: 11:34:04 AM
User: NT AUTHORITY\SYSTEM
Computer: Pluto
Description:
Logon Failure:
Reason: Account locked out
User Name: AccountA
Domain: Pluto
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: Mars

On Mars go to Control Panel - stored user names and passwords to see if
anything is shown there which may be using the other user account. You can
remove entries from there if you want. --- Steve


"Phil McNeill" <philmcneill@NOSPAM4MEhydroottawa.com> wrote in message
news:uQXIGO4cGHA.3556@TK2MSFTNGP02.phx.gbl...
> Weird one. If you're inclined to help, you may want to draw a picture. :)
>
> 2 Servers:
>
> Mars (Windows 2003) has two local accounts, AccountA and AccountB, both
> local administrators.
> Pluto (Windows 2000) has two local accounts, also named AccountA and
> AccountB, both local administrators.
>
> Both servers are member servers (not DCs) on the same mixed mode 2003
> domain.
>
> The passwords for AccountA and AccountB are the same on both servers
> (respectively), for the purpose of pass-through authentication.
>
> I log in to Mars locally with AccountB, and UNC to \\Pluto\c$ at the run
> command, expecting the local AccountB on Pluto to be used to access the
> shared resource. I get the message that it is not accessible, and that
> the referenced account is currently locked out and may not be logged on
> to. When I check the security log on Pluto, I see that instead of it using
> the local AccountB account to access the share (as I would expect
> pass-through authentication to do), it is instead using AccountA (even
> though I was logged in with AccountB on Mars). This happens not just with
> the default shares, but any share AccountB has access to.
>
> Any idea why Pluto would attempt to use the opposite account when
> logically it should grab the one with the same name as what I'm logged
> into Mars with?
>
> If I do everything the same, except log in with AccountA, everything works
> fine.
>
> Any thoughts appreciated!!
>
> Phil
>
> Logs from Pluto:
>
> Event Type: Failure Audit
> Event Source: Security
> Event Category: Account Logon
> Event ID: 681
> Date: 09/05/2006
> Time: 11:34:04 AM
> User: NT AUTHORITY\SYSTEM
> Computer: Pluto
> Description:
> The logon to account: AccountA
> by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
> from workstation: Mars
> failed. The error code was: 3221226036
>
> and:
>
> Event Type: Failure Audit
> Event Source: Security
> Event Category: Logon/Logoff
> Event ID: 539
> Date: 09/05/2006
> Time: 11:34:04 AM
> User: NT AUTHORITY\SYSTEM
> Computer: Pluto
> Description:
> Logon Failure:
> Reason: Account locked out
> User Name: AccountA
> Domain: Pluto
> Logon Type: 3
> Logon Process: NtLmSsp
> Authentication Package: NTLM
> Workstation Name: Mars
>
>
>

Thanks for the suggestion. Nothing there at all. This is completely
bizarre.

The account that doesn't work (because the remote machine seems to refuse to
use it and instead uses another local account) is being used to run
scheduled jobs on Mars, which are now unsuccessful - the app person says it
was working for a couple months) which of course results in the opposite
account on the "connected to" server to get locked out due to this
weirdness.

Anything in the local security policy on either machine for either of these
accounts that could account for this?

I can't imagine what would cause that. I think I'll suggest they create a
new account and try it to see what the results are. Either that or use a
domain account for this stuff. Very strange.

Thanks again!




"Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
news:ut1pz$%23cGHA.3908@TK2MSFTNGP04.phx.gbl...
> On Mars go to Control Panel - stored user names and passwords to see if
> anything is shown there which may be using the other user account. You can
> remove entries from there if you want. --- Steve


>
> "Phil McNeill" <philmcneill@NOSPAM4MEhydroottawa.com> wrote in message
> news:uQXIGO4cGHA.3556@TK2MSFTNGP02.phx.gbl...
>> Weird one. If you're inclined to help, you may want to draw a picture.
>> :)
>>
>> 2 Servers:
>>
>> Mars (Windows 2003) has two local accounts, AccountA and AccountB, both
>> local administrators.
>> Pluto (Windows 2000) has two local accounts, also named AccountA and
>> AccountB, both local administrators.
>>
>> Both servers are member servers (not DCs) on the same mixed mode 2003
>> domain.
>>
>> The passwords for AccountA and AccountB are the same on both servers
>> (respectively), for the purpose of pass-through authentication.
>>
>> I log in to Mars locally with AccountB, and UNC to \\Pluto\c$ at the run
>> command, expecting the local AccountB on Pluto to be used to access the
>> shared resource. I get the message that it is not accessible, and that
>> the referenced account is currently locked out and may not be logged on
>> to. When I check the security log on Pluto, I see that instead of it
>> using the local AccountB account to access the share (as I would expect
>> pass-through authentication to do), it is instead using AccountA (even
>> though I was logged in with AccountB on Mars). This happens not just
>> with the default shares, but any share AccountB has access to.
>>
>> Any idea why Pluto would attempt to use the opposite account when
>> logically it should grab the one with the same name as what I'm logged
>> into Mars with?
>>
>> If I do everything the same, except log in with AccountA, everything
>> works fine.
>>
>> Any thoughts appreciated!!
>>
>> Phil
>>
>> Logs from Pluto:
>>
>> Event Type: Failure Audit
>> Event Source: Security
>> Event Category: Account Logon
>> Event ID: 681
>> Date: 09/05/2006
>> Time: 11:34:04 AM
>> User: NT AUTHORITY\SYSTEM
>> Computer: Pluto
>> Description:
>> The logon to account: AccountA
>> by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
>> from workstation: Mars
>> failed. The error code was: 3221226036
>>
>> and:
>>
>> Event Type: Failure Audit
>> Event Source: Security
>> Event Category: Logon/Logoff
>> Event ID: 539
>> Date: 09/05/2006
>> Time: 11:34:04 AM
>> User: NT AUTHORITY\SYSTEM
>> Computer: Pluto
>> Description:
>> Logon Failure:
>> Reason: Account locked out
>> User Name: AccountA
>> Domain: Pluto
>> Logon Type: 3
>> Logon Process: NtLmSsp
>> Authentication Package: NTLM
>> Workstation Name: Mars
>>
>>
>>
>
>

Well that was my best shot as usually stored credentials or persistent
credentials in a mapped drive are the problem. Offhand I can't think of a
reason either why that would happen. What I would try to see what happens is
use the net use command to connect to the share as in net use * \\pluto\c$
/u:AccountB at which time you should be prompted for a password or maybe you
will get some error message that could be a clue. Another thing to try is to
temporarily disable accountA on Mars and try again to see what happens. Also
check the logs on Mars to see if anything helpful is reported particularly
at or around the time you try those connection attempts. I can't think of
ant Local Security Policy setting that would cause such behavior. --- Steve


"Phil McNeill" <philmcneill@NOSPAM4MEhydroottawa.com> wrote in message
news:%23BFzJOEdGHA.3888@TK2MSFTNGP02.phx.gbl...
> Thanks for the suggestion. Nothing there at all. This is completely
> bizarre.
>
> The account that doesn't work (because the remote machine seems to refuse
> to use it and instead uses another local account) is being used to run
> scheduled jobs on Mars, which are now unsuccessful - the app person says
> it was working for a couple months) which of course results in the
> opposite account on the "connected to" server to get locked out due to
> this weirdness.
>
> Anything in the local security policy on either machine for either of
> these accounts that could account for this?
>
> I can't imagine what would cause that. I think I'll suggest they create a
> new account and try it to see what the results are. Either that or use a
> domain account for this stuff. Very strange.
>
> Thanks again!
>
>
>
>
> "Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
> news:ut1pz$%23cGHA.3908@TK2MSFTNGP04.phx.gbl...
>> On Mars go to Control Panel - stored user names and passwords to see if
>> anything is shown there which may be using the other user account. You
>> can remove entries from there if you want. --- Steve
>
>
>>
>> "Phil McNeill" <philmcneill@NOSPAM4MEhydroottawa.com> wrote in message
>> news:uQXIGO4cGHA.3556@TK2MSFTNGP02.phx.gbl...
>>> Weird one. If you're inclined to help, you may want to draw a picture.
>>> :)
>>>
>>> 2 Servers:
>>>
>>> Mars (Windows 2003) has two local accounts, AccountA and AccountB, both
>>> local administrators.
>>> Pluto (Windows 2000) has two local accounts, also named AccountA and
>>> AccountB, both local administrators.
>>>
>>> Both servers are member servers (not DCs) on the same mixed mode 2003
>>> domain.
>>>
>>> The passwords for AccountA and AccountB are the same on both servers
>>> (respectively), for the purpose of pass-through authentication.
>>>
>>> I log in to Mars locally with AccountB, and UNC to \\Pluto\c$ at the run
>>> command, expecting the local AccountB on Pluto to be used to access the
>>> shared resource. I get the message that it is not accessible, and that
>>> the referenced account is currently locked out and may not be logged on
>>> to. When I check the security log on Pluto, I see that instead of it
>>> using the local AccountB account to access the share (as I would expect
>>> pass-through authentication to do), it is instead using AccountA (even
>>> though I was logged in with AccountB on Mars). This happens not just
>>> with the default shares, but any share AccountB has access to.
>>>
>>> Any idea why Pluto would attempt to use the opposite account when
>>> logically it should grab the one with the same name as what I'm logged
>>> into Mars with?
>>>
>>> If I do everything the same, except log in with AccountA, everything
>>> works fine.
>>>
>>> Any thoughts appreciated!!
>>>
>>> Phil
>>>
>>> Logs from Pluto:
>>>
>>> Event Type: Failure Audit
>>> Event Source: Security
>>> Event Category: Account Logon
>>> Event ID: 681
>>> Date: 09/05/2006
>>> Time: 11:34:04 AM
>>> User: NT AUTHORITY\SYSTEM
>>> Computer: Pluto
>>> Description:
>>> The logon to account: AccountA
>>> by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
>>> from workstation: Mars
>>> failed. The error code was: 3221226036
>>>
>>> and:
>>>
>>> Event Type: Failure Audit
>>> Event Source: Security
>>> Event Category: Logon/Logoff
>>> Event ID: 539
>>> Date: 09/05/2006
>>> Time: 11:34:04 AM
>>> User: NT AUTHORITY\SYSTEM
>>> Computer: Pluto
>>> Description:
>>> Logon Failure:
>>> Reason: Account locked out
>>> User Name: AccountA
>>> Domain: Pluto
>>> Logon Type: 3
>>> Logon Process: NtLmSsp
>>> Authentication Package: NTLM
>>> Workstation Name: Mars
>>>
>>>
>>>
>>
>>
>
>

"Phil McNeill" <philmcneill@NOSPAM4MEhydroottawa.com> wrote in message
news:%23BFzJOEdGHA.3888@TK2MSFTNGP02.phx.gbl...
> Thanks for the suggestion. Nothing there at all. This is completely
> bizarre.
>
> The account that doesn't work (because the remote machine seems to refuse
> to use it and instead uses another local account) is being used to run
> scheduled jobs on Mars, which are now unsuccessful - the app person says
> it was working for a couple months) which of course results in the
> opposite account on the "connected to" server to get locked out due to
> this weirdness.
>
> Anything in the local security policy on either machine for either of
> these accounts that could account for this?
>

No. There is no "remap accounts" policy.
What Steve suggest is/was my only first thought also.
Are you sure you were logged in on Mars with the account when
you checked for its stored mappings ?? That is stored per account.

--
Roger Abell
Microsoft MVP (Windows Server : Security)

> I can't imagine what would cause that. I think I'll suggest they create a
> new account and try it to see what the results are. Either that or use a
> domain account for this stuff. Very strange.
>
> Thanks again!
>
>
>
>
> "Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
> news:ut1pz$%23cGHA.3908@TK2MSFTNGP04.phx.gbl...
>> On Mars go to Control Panel - stored user names and passwords to see if
>> anything is shown there which may be using the other user account. You
>> can remove entries from there if you want. --- Steve
>
>
>>
>> "Phil McNeill" <philmcneill@NOSPAM4MEhydroottawa.com> wrote in message
>> news:uQXIGO4cGHA.3556@TK2MSFTNGP02.phx.gbl...
>>> Weird one. If you're inclined to help, you may want to draw a picture.
>>> :)
>>>
>>> 2 Servers:
>>>
>>> Mars (Windows 2003) has two local accounts, AccountA and AccountB, both
>>> local administrators.
>>> Pluto (Windows 2000) has two local accounts, also named AccountA and
>>> AccountB, both local administrators.
>>>
>>> Both servers are member servers (not DCs) on the same mixed mode 2003
>>> domain.
>>>
>>> The passwords for AccountA and AccountB are the same on both servers
>>> (respectively), for the purpose of pass-through authentication.
>>>
>>> I log in to Mars locally with AccountB, and UNC to \\Pluto\c$ at the run
>>> command, expecting the local AccountB on Pluto to be used to access the
>>> shared resource. I get the message that it is not accessible, and that
>>> the referenced account is currently locked out and may not be logged on
>>> to. When I check the security log on Pluto, I see that instead of it
>>> using the local AccountB account to access the share (as I would expect
>>> pass-through authentication to do), it is instead using AccountA (even
>>> though I was logged in with AccountB on Mars). This happens not just
>>> with the default shares, but any share AccountB has access to.
>>>
>>> Any idea why Pluto would attempt to use the opposite account when
>>> logically it should grab the one with the same name as what I'm logged
>>> into Mars with?
>>>
>>> If I do everything the same, except log in with AccountA, everything
>>> works fine.
>>>
>>> Any thoughts appreciated!!
>>>
>>> Phil
>>>
>>> Logs from Pluto:
>>>
>>> Event Type: Failure Audit
>>> Event Source: Security
>>> Event Category: Account Logon
>>> Event ID: 681
>>> Date: 09/05/2006
>>> Time: 11:34:04 AM
>>> User: NT AUTHORITY\SYSTEM
>>> Computer: Pluto
>>> Description:
>>> The logon to account: AccountA
>>> by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
>>> from workstation: Mars
>>> failed. The error code was: 3221226036
>>>
>>> and:
>>>
>>> Event Type: Failure Audit
>>> Event Source: Security
>>> Event Category: Logon/Logoff
>>> Event ID: 539
>>> Date: 09/05/2006
>>> Time: 11:34:04 AM
>>> User: NT AUTHORITY\SYSTEM
>>> Computer: Pluto
>>> Description:
>>> Logon Failure:
>>> Reason: Account locked out
>>> User Name: AccountA
>>> Domain: Pluto
>>> Logon Type: 3
>>> Logon Process: NtLmSsp
>>> Authentication Package: NTLM
>>> Workstation Name: Mars
>>>
>>>
>>>
>>
>>
>
>

This WAS the problem after all. I must have been logged in with the wrong
account when I checked for it the first time (didn't realize it would be a
profile-specific setting, which was pretty dumb of me). Anyway, found the
entry, removed it, and I think they are back in business. Thanks to both
Steven and Roger!!

Phil

"Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
news:esfivBFdGHA.564@TK2MSFTNGP02.phx.gbl...
> Well that was my best shot as usually stored credentials or persistent
> credentials in a mapped drive are the problem. Offhand I can't think of a
> reason either why that would happen. What I would try to see what happens
> is use the net use command to connect to the share as in net use *
> \\pluto\c$ /u:AccountB at which time you should be prompted for a password
> or maybe you will get some error message that could be a clue. Another
> thing to try is to temporarily disable accountA on Mars and try again to
> see what happens. Also check the logs on Mars to see if anything helpful
> is reported particularly at or around the time you try those connection
> attempts. I can't think of ant Local Security Policy setting that would
> cause such behavior. --- Steve
>
>
> "Phil McNeill" <philmcneill@NOSPAM4MEhydroottawa.com> wrote in message
> news:%23BFzJOEdGHA.3888@TK2MSFTNGP02.phx.gbl...
>> Thanks for the suggestion. Nothing there at all. This is completely
>> bizarre.
>>
>> The account that doesn't work (because the remote machine seems to refuse
>> to use it and instead uses another local account) is being used to run
>> scheduled jobs on Mars, which are now unsuccessful - the app person says
>> it was working for a couple months) which of course results in the
>> opposite account on the "connected to" server to get locked out due to
>> this weirdness.
>>
>> Anything in the local security policy on either machine for either of
>> these accounts that could account for this?
>>
>> I can't imagine what would cause that. I think I'll suggest they create
>> a new account and try it to see what the results are. Either that or use
>> a domain account for this stuff. Very strange.
>>
>> Thanks again!
>>
>>
>>
>>
>> "Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
>> news:ut1pz$%23cGHA.3908@TK2MSFTNGP04.phx.gbl...
>>> On Mars go to Control Panel - stored user names and passwords to see if
>>> anything is shown there which may be using the other user account. You
>>> can remove entries from there if you want. --- Steve
>>
>>
>>>
>>> "Phil McNeill" <philmcneill@NOSPAM4MEhydroottawa.com> wrote in message
>>> news:uQXIGO4cGHA.3556@TK2MSFTNGP02.phx.gbl...
>>>> Weird one. If you're inclined to help, you may want to draw a picture.
>>>> :)
>>>>
>>>> 2 Servers:
>>>>
>>>> Mars (Windows 2003) has two local accounts, AccountA and AccountB, both
>>>> local administrators.
>>>> Pluto (Windows 2000) has two local accounts, also named AccountA and
>>>> AccountB, both local administrators.
>>>>
>>>> Both servers are member servers (not DCs) on the same mixed mode 2003
>>>> domain.
>>>>
>>>> The passwords for AccountA and AccountB are the same on both servers
>>>> (respectively), for the purpose of pass-through authentication.
>>>>
>>>> I log in to Mars locally with AccountB, and UNC to \\Pluto\c$ at the
>>>> run command, expecting the local AccountB on Pluto to be used to access
>>>> the shared resource. I get the message that it is not accessible, and
>>>> that the referenced account is currently locked out and may not be
>>>> logged on to. When I check the security log on Pluto, I see that
>>>> instead of it using the local AccountB account to access the share (as
>>>> I would expect pass-through authentication to do), it is instead using
>>>> AccountA (even though I was logged in with AccountB on Mars). This
>>>> happens not just with the default shares, but any share AccountB has
>>>> access to.
>>>>
>>>> Any idea why Pluto would attempt to use the opposite account when
>>>> logically it should grab the one with the same name as what I'm logged
>>>> into Mars with?
>>>>
>>>> If I do everything the same, except log in with AccountA, everything
>>>> works fine.
>>>>
>>>> Any thoughts appreciated!!
>>>>
>>>> Phil
>>>>
>>>> Logs from Pluto:
>>>>
>>>> Event Type: Failure Audit
>>>> Event Source: Security
>>>> Event Category: Account Logon
>>>> Event ID: 681
>>>> Date: 09/05/2006
>>>> Time: 11:34:04 AM
>>>> User: NT AUTHORITY\SYSTEM
>>>> Computer: Pluto
>>>> Description:
>>>> The logon to account: AccountA
>>>> by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
>>>> from workstation: Mars
>>>> failed. The error code was: 3221226036
>>>>
>>>> and:
>>>>
>>>> Event Type: Failure Audit
>>>> Event Source: Security
>>>> Event Category: Logon/Logoff
>>>> Event ID: 539
>>>> Date: 09/05/2006
>>>> Time: 11:34:04 AM
>>>> User: NT AUTHORITY\SYSTEM
>>>> Computer: Pluto
>>>> Description:
>>>> Logon Failure:
>>>> Reason: Account locked out
>>>> User Name: AccountA
>>>> Domain: Pluto
>>>> Logon Type: 3
>>>> Logon Process: NtLmSsp
>>>> Authentication Package: NTLM
>>>> Workstation Name: Mars
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

[MarlonC]

Does this apply for NT server as well?

When different users try to access the mapped drive on the network they get the same message "K:\ is not accessible The referenced account is currently locked out & may not be logged on to"

OS for users XP Pro SP2

They could access the drive everyday untill now.

What could the problem be?

Many thanks!!!

"MarlonC" <MarlonC.2pjnbi@DoNotSpam.com> wrote in message
news:MarlonC.2pjnbi@DoNotSpam.com...
>
> Does this apply for NT server as well?
>
> When different users try to access the mapped drive on the network they
> get the same message "K:\ is not accessible The referenced account is
> currently locked out & may not be logged on to"
>
> OS for users XP Pro SP2
>
> They could access the drive everyday untill now.
>
> What could the problem be?
>

I am not so sure what you are asking Marlon.
NT and later server of a share behaved the same.
If the account used for the share access cannot be authenticated
(bad pwd, non-account, lock account, disabled account) then the
attempted access will not be allowed.

Roger

[MarlonC]

Hi Roger,

User could access the share drive on the netowrk before, when they try to access the drive now they get the following message displayed: "K:\ is not accessible The referenced account is currently locked out & may not be logged on to"

K: is the network drive they trying to access. I none of the users accounts are locked in AD.

"MarlonC" <MarlonC.2pl1bh@DoNotSpam.com> wrote in message
news:MarlonC.2pl1bh@DoNotSpam.com...
>
> Hi Roger,
>
> User could access the share drive on the netowrk before, when they try
> to access the drive now they get the following message displayed: "K:\
> is not accessible The referenced account is currently locked out & may
> not be logged on to"
>
> K: is the network drive they trying to access. I none of the users
> accounts are locked in AD.
>

So, you say there is one account experiencing lockout?
But when you look it is no longer showing as locked in
the AD Users and Comps UI tool ?

The user probably changed their password, but something that
they have set in motion does not know that (or the new pwd).
If you audit on the DCs for failed account logins the security
log messages should tell you where this happens.

Roger