I have two computers, client and server. The client is running Windows 2000
Professional and is in a workgroup, say "MyWorkgroup". The server is running
Windows Server 2003 Standard Edition and is in a domain, say "MyDomain".
What I need is to logon to the client as some generic local administrator
user and then access resources (e.g. share folder, SQL Server using Windows
Authentication, etc.) on the server.

Here is what I did:
I create another local administrator user (user A) with on the client with
the same username and password as a domain user (user B) on the server. I
then access resources on the server by first logging on to the client as the
generic administrator user and then impersonating to user A and use user A's
credentials to access the server. I have two sets of such systems in two
environments. This works fine in one environment, but not the other. In the
environment that works fine, when accessing the server, user A is
automatically viewed as the domain user B. In the environment that fails,
user A is not recognized as a domain user on the server, i.e. it's not
automatically mapped to user B.

There're only 2 differences between the two environments:
Environemnt 1: Server is domain controller. There's no firewall between the
server and the client.
Environment 2: Server is a member server of a domain, the domain controller
is another computer residing somewhere else. There's a firewall between the
server and the client.

I don't think the problem is with the firewall, because I can get to the
server from the client successfully (I can ping), and I also did see the
logon request coming over to the server from the client. It's just that the
logon request fails (in environemnt) 2 because the client user (user A) is
not mapped to the domain user (user B). In the EventViewer (I have auditing
on), it reports logon failure because user doesn't exist (error code
0xC0000064).

Any idea on why it fails in environemnt 2? Also any idea on how to tell the
Windows server to look for the username in the server's domain rather than
just looking for it in the local user list on the server? That username is a
domain user on the server, not a local user.

Thank you very much.

RE: URGENT: Why the impersonation work in one case and not the other? by NoSpamMgbworld

NoSpamMgbworld
Fri Jan 07 07:23:02 CST 2005

Technically, domain controllers have no local groups, so all access is domain
related. Member servers have local users and groups and default to them. This
gives a couple of choices.

1. Set the machine to another default, most likely through some registry
tweak. This is not a good option, overall, as it makes it harder to log on
locally.

2. Add the domain information to the login, like MyDomain\MyUser, not
MyUser. This is an easier solution if there is only one domain to deal with.
Have the client supply the MyDomain when it is not present and you are golden.

3. Take the client out of the workgroup and join to the domain. I am not
100% sure on this one, but I believe it will work.


---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************


"CyberDigger" wrote:

> I have two computers, client and server. The client is running Windows 2000
> Professional and is in a workgroup, say "MyWorkgroup". The server is running
> Windows Server 2003 Standard Edition and is in a domain, say "MyDomain".
> What I need is to logon to the client as some generic local administrator
> user and then access resources (e.g. share folder, SQL Server using Windows
> Authentication, etc.) on the server.
>
> Here is what I did:
> I create another local administrator user (user A) with on the client with
> the same username and password as a domain user (user B) on the server. I
> then access resources on the server by first logging on to the client as the
> generic administrator user and then impersonating to user A and use user A's
> credentials to access the server. I have two sets of such systems in two
> environments. This works fine in one environment, but not the other. In the
> environment that works fine, when accessing the server, user A is
> automatically viewed as the domain user B. In the environment that fails,
> user A is not recognized as a domain user on the server, i.e. it's not
> automatically mapped to user B.
>
> There're only 2 differences between the two environments:
> Environemnt 1: Server is domain controller. There's no firewall between the
> server and the client.
> Environment 2: Server is a member server of a domain, the domain controller
> is another computer residing somewhere else. There's a firewall between the
> server and the client.
>
> I don't think the problem is with the firewall, because I can get to the
> server from the client successfully (I can ping), and I also did see the
> logon request coming over to the server from the client. It's just that the
> logon request fails (in environemnt) 2 because the client user (user A) is
> not mapped to the domain user (user B). In the EventViewer (I have auditing
> on), it reports logon failure because user doesn't exist (error code
> 0xC0000064).
>
> Any idea on why it fails in environemnt 2? Also any idea on how to tell the
> Windows server to look for the username in the server's domain rather than
> just looking for it in the local user list on the server? That username is a
> domain user on the server, not a local user.
>
> Thank you very much.

RE: URGENT: Why the impersonation work in one case and not the oth by CyberDigger

CyberDigger
Fri Jan 07 11:57:14 CST 2005

Gregory,

Thanks for the reply. I cannot go with options 1 or 2. Do you know how to
do option 1. What's the registry value to be changed?

Thanks,
CyberDigger

"Cowboy (Gregory A. Beamer) - MVP" wrote:

> Technically, domain controllers have no local groups, so all access is domain
> related. Member servers have local users and groups and default to them. This
> gives a couple of choices.
>
> 1. Set the machine to another default, most likely through some registry
> tweak. This is not a good option, overall, as it makes it harder to log on
> locally.
>
> 2. Add the domain information to the login, like MyDomain\MyUser, not
> MyUser. This is an easier solution if there is only one domain to deal with.
> Have the client supply the MyDomain when it is not present and you are golden.
>
> 3. Take the client out of the workgroup and join to the domain. I am not
> 100% sure on this one, but I believe it will work.
>
>
> ---
>
> Gregory A. Beamer
> MVP; MCP: +I, SE, SD, DBA
>
> ***************************
> Think Outside the Box!
> ***************************
>
>
> "CyberDigger" wrote:
>
> > I have two computers, client and server. The client is running Windows 2000
> > Professional and is in a workgroup, say "MyWorkgroup". The server is running
> > Windows Server 2003 Standard Edition and is in a domain, say "MyDomain".
> > What I need is to logon to the client as some generic local administrator
> > user and then access resources (e.g. share folder, SQL Server using Windows
> > Authentication, etc.) on the server.
> >
> > Here is what I did:
> > I create another local administrator user (user A) with on the client with
> > the same username and password as a domain user (user B) on the server. I
> > then access resources on the server by first logging on to the client as the
> > generic administrator user and then impersonating to user A and use user A's
> > credentials to access the server. I have two sets of such systems in two
> > environments. This works fine in one environment, but not the other. In the
> > environment that works fine, when accessing the server, user A is
> > automatically viewed as the domain user B. In the environment that fails,
> > user A is not recognized as a domain user on the server, i.e. it's not
> > automatically mapped to user B.
> >
> > There're only 2 differences between the two environments:
> > Environemnt 1: Server is domain controller. There's no firewall between the
> > server and the client.
> > Environment 2: Server is a member server of a domain, the domain controller
> > is another computer residing somewhere else. There's a firewall between the
> > server and the client.
> >
> > I don't think the problem is with the firewall, because I can get to the
> > server from the client successfully (I can ping), and I also did see the
> > logon request coming over to the server from the client. It's just that the
> > logon request fails (in environemnt) 2 because the client user (user A) is
> > not mapped to the domain user (user B). In the EventViewer (I have auditing
> > on), it reports logon failure because user doesn't exist (error code
> > 0xC0000064).
> >
> > Any idea on why it fails in environemnt 2? Also any idea on how to tell the
> > Windows server to look for the username in the server's domain rather than
> > just looking for it in the local user list on the server? That username is a
> > domain user on the server, not a local user.
> >
> > Thank you very much.

Re: URGENT: Why the impersonation work in one case and not the oth by Alexander

Alexander
Fri Jan 07 12:45:46 CST 2005

What's the problem with option 2? It even saves you the trouble
of creating a local account with same credentials as the domain
account (since you don't need it). Are you perhaps not aware
of WNetAddConnection2/3?

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

"CyberDigger" <CyberDigger@discussions.microsoft.com> wrote in message
news:186ACF7C-B36C-444E-B12D-22AF23E31F90@microsoft.com...
> Gregory,
>
> Thanks for the reply. I cannot go with options 1 or 2. Do you know how
> to
> do option 1. What's the registry value to be changed?
>
> Thanks,
> CyberDigger
>
> "Cowboy (Gregory A. Beamer) - MVP" wrote:
>
>> Technically, domain controllers have no local groups, so all access is
>> domain
>> related. Member servers have local users and groups and default to them.
>> This
>> gives a couple of choices.
>>
>> 1. Set the machine to another default, most likely through some registry
>> tweak. This is not a good option, overall, as it makes it harder to log
>> on
>> locally.
>>
>> 2. Add the domain information to the login, like MyDomain\MyUser, not
>> MyUser. This is an easier solution if there is only one domain to deal
>> with.
>> Have the client supply the MyDomain when it is not present and you are
>> golden.
>>
>> 3. Take the client out of the workgroup and join to the domain. I am not
>> 100% sure on this one, but I believe it will work.
>>
>>
>> ---
>>
>> Gregory A. Beamer
>> MVP; MCP: +I, SE, SD, DBA
>>
>> ***************************
>> Think Outside the Box!
>> ***************************
>>
>>
>> "CyberDigger" wrote:
>>
>> > I have two computers, client and server. The client is running Windows
>> > 2000
>> > Professional and is in a workgroup, say "MyWorkgroup". The server is
>> > running
>> > Windows Server 2003 Standard Edition and is in a domain, say
>> > "MyDomain".
>> > What I need is to logon to the client as some generic local
>> > administrator
>> > user and then access resources (e.g. share folder, SQL Server using
>> > Windows
>> > Authentication, etc.) on the server.
>> >
>> > Here is what I did:
>> > I create another local administrator user (user A) with on the client
>> > with
>> > the same username and password as a domain user (user B) on the server.
>> > I
>> > then access resources on the server by first logging on to the client
>> > as the
>> > generic administrator user and then impersonating to user A and use
>> > user A's
>> > credentials to access the server. I have two sets of such systems in
>> > two
>> > environments. This works fine in one environment, but not the other.
>> > In the
>> > environment that works fine, when accessing the server, user A is
>> > automatically viewed as the domain user B. In the environment that
>> > fails,
>> > user A is not recognized as a domain user on the server, i.e. it's not
>> > automatically mapped to user B.
>> >
>> > There're only 2 differences between the two environments:
>> > Environemnt 1: Server is domain controller. There's no firewall
>> > between the
>> > server and the client.
>> > Environment 2: Server is a member server of a domain, the domain
>> > controller
>> > is another computer residing somewhere else. There's a firewall
>> > between the
>> > server and the client.
>> >
>> > I don't think the problem is with the firewall, because I can get to
>> > the
>> > server from the client successfully (I can ping), and I also did see
>> > the
>> > logon request coming over to the server from the client. It's just
>> > that the
>> > logon request fails (in environemnt) 2 because the client user (user A)
>> > is
>> > not mapped to the domain user (user B). In the EventViewer (I have
>> > auditing
>> > on), it reports logon failure because user doesn't exist (error code
>> > 0xC0000064).
>> >
>> > Any idea on why it fails in environemnt 2? Also any idea on how to
>> > tell the
>> > Windows server to look for the username in the server's domain rather
>> > than
>> > just looking for it in the local user list on the server? That
>> > username is a
>> > domain user on the server, not a local user.
>> >
>> > Thank you very much.



Re: URGENT: Why the impersonation work in one case and not the oth by CyberDigger

CyberDigger
Fri Jan 07 13:39:05 CST 2005

The problem here is that I need to log on to the client (in a workgroup) as
some generic local user and then access a share folder and SQL Server on the
server (in a separate domain, not a domain controller) using Windows
authentication of a specific domain user. Therefore, what I need is to be
able to impersonate the generic local user on the client to a specific domain
user on the server in order to access server resources like share folder and
SQL Server using Windows authentication. Any idea on a better or alternative
way to do this?

Thank you.


"Alexander Nickolov" wrote:

> What's the problem with option 2? It even saves you the trouble
> of creating a local account with same credentials as the domain
> account (since you don't need it). Are you perhaps not aware
> of WNetAddConnection2/3?
>
> --
> =====================================
> Alexander Nickolov
> Microsoft MVP [VC], MCSD
> email: agnickolov@mvps.org
> MVP VC FAQ: http://www.mvps.org/vcfaq
> =====================================
>
> "CyberDigger" <CyberDigger@discussions.microsoft.com> wrote in message
> news:186ACF7C-B36C-444E-B12D-22AF23E31F90@microsoft.com...
> > Gregory,
> >
> > Thanks for the reply. I cannot go with options 1 or 2. Do you know how
> > to
> > do option 1. What's the registry value to be changed?
> >
> > Thanks,
> > CyberDigger
> >
> > "Cowboy (Gregory A. Beamer) - MVP" wrote:
> >
> >> Technically, domain controllers have no local groups, so all access is
> >> domain
> >> related. Member servers have local users and groups and default to them.
> >> This
> >> gives a couple of choices.
> >>
> >> 1. Set the machine to another default, most likely through some registry
> >> tweak. This is not a good option, overall, as it makes it harder to log
> >> on
> >> locally.
> >>
> >> 2. Add the domain information to the login, like MyDomain\MyUser, not
> >> MyUser. This is an easier solution if there is only one domain to deal
> >> with.
> >> Have the client supply the MyDomain when it is not present and you are
> >> golden.
> >>
> >> 3. Take the client out of the workgroup and join to the domain. I am not
> >> 100% sure on this one, but I believe it will work.
> >>
> >>
> >> ---
> >>
> >> Gregory A. Beamer
> >> MVP; MCP: +I, SE, SD, DBA
> >>
> >> ***************************
> >> Think Outside the Box!
> >> ***************************
> >>
> >>
> >> "CyberDigger" wrote:
> >>
> >> > I have two computers, client and server. The client is running Windows
> >> > 2000
> >> > Professional and is in a workgroup, say "MyWorkgroup". The server is
> >> > running
> >> > Windows Server 2003 Standard Edition and is in a domain, say
> >> > "MyDomain".
> >> > What I need is to logon to the client as some generic local
> >> > administrator
> >> > user and then access resources (e.g. share folder, SQL Server using
> >> > Windows
> >> > Authentication, etc.) on the server.
> >> >
> >> > Here is what I did:
> >> > I create another local administrator user (user A) with on the client
> >> > with
> >> > the same username and password as a domain user (user B) on the server.
> >> > I
> >> > then access resources on the server by first logging on to the client
> >> > as the
> >> > generic administrator user and then impersonating to user A and use
> >> > user A's
> >> > credentials to access the server. I have two sets of such systems in
> >> > two
> >> > environments. This works fine in one environment, but not the other.
> >> > In the
> >> > environment that works fine, when accessing the server, user A is
> >> > automatically viewed as the domain user B. In the environment that
> >> > fails,
> >> > user A is not recognized as a domain user on the server, i.e. it's not
> >> > automatically mapped to user B.
> >> >
> >> > There're only 2 differences between the two environments:
> >> > Environemnt 1: Server is domain controller. There's no firewall
> >> > between the
> >> > server and the client.
> >> > Environment 2: Server is a member server of a domain, the domain
> >> > controller
> >> > is another computer residing somewhere else. There's a firewall
> >> > between the
> >> > server and the client.
> >> >
> >> > I don't think the problem is with the firewall, because I can get to
> >> > the
> >> > server from the client successfully (I can ping), and I also did see
> >> > the
> >> > logon request coming over to the server from the client. It's just
> >> > that the
> >> > logon request fails (in environemnt) 2 because the client user (user A)
> >> > is
> >> > not mapped to the domain user (user B). In the EventViewer (I have
> >> > auditing
> >> > on), it reports logon failure because user doesn't exist (error code
> >> > 0xC0000064).
> >> >
> >> > Any idea on why it fails in environemnt 2? Also any idea on how to
> >> > tell the
> >> > Windows server to look for the username in the server's domain rather
> >> > than
> >> > just looking for it in the local user list on the server? That
> >> > username is a
> >> > domain user on the server, not a local user.
> >> >
> >> > Thank you very much.
>
>
>

Re: URGENT: Why the impersonation work in one case and not the oth by Alexander

Alexander
Fri Jan 07 16:13:34 CST 2005

WNetAddConnection2 gives you access to network shares.
I don't know about SQL Server, you'll have to ask in the
appropriate group. My point is, you don't need to locally
log on as that user to get the necessary credentials remotely.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

"CyberDigger" <CyberDigger@discussions.microsoft.com> wrote in message
news:AA3FF437-0B3E-445A-8E54-6BE63E08BB8D@microsoft.com...
> The problem here is that I need to log on to the client (in a workgroup)
> as
> some generic local user and then access a share folder and SQL Server on
> the
> server (in a separate domain, not a domain controller) using Windows
> authentication of a specific domain user. Therefore, what I need is to be
> able to impersonate the generic local user on the client to a specific
> domain
> user on the server in order to access server resources like share folder
> and
> SQL Server using Windows authentication. Any idea on a better or
> alternative
> way to do this?
>
> Thank you.
>
>
> "Alexander Nickolov" wrote:
>
>> What's the problem with option 2? It even saves you the trouble
>> of creating a local account with same credentials as the domain
>> account (since you don't need it). Are you perhaps not aware
>> of WNetAddConnection2/3?
>>
>> --
>> =====================================
>> Alexander Nickolov
>> Microsoft MVP [VC], MCSD
>> email: agnickolov@mvps.org
>> MVP VC FAQ: http://www.mvps.org/vcfaq
>> =====================================
>>
>> "CyberDigger" <CyberDigger@discussions.microsoft.com> wrote in message
>> news:186ACF7C-B36C-444E-B12D-22AF23E31F90@microsoft.com...
>> > Gregory,
>> >
>> > Thanks for the reply. I cannot go with options 1 or 2. Do you know
>> > how
>> > to
>> > do option 1. What's the registry value to be changed?
>> >
>> > Thanks,
>> > CyberDigger
>> >
>> > "Cowboy (Gregory A. Beamer) - MVP" wrote:
>> >
>> >> Technically, domain controllers have no local groups, so all access is
>> >> domain
>> >> related. Member servers have local users and groups and default to
>> >> them.
>> >> This
>> >> gives a couple of choices.
>> >>
>> >> 1. Set the machine to another default, most likely through some
>> >> registry
>> >> tweak. This is not a good option, overall, as it makes it harder to
>> >> log
>> >> on
>> >> locally.
>> >>
>> >> 2. Add the domain information to the login, like MyDomain\MyUser, not
>> >> MyUser. This is an easier solution if there is only one domain to deal
>> >> with.
>> >> Have the client supply the MyDomain when it is not present and you are
>> >> golden.
>> >>
>> >> 3. Take the client out of the workgroup and join to the domain. I am
>> >> not
>> >> 100% sure on this one, but I believe it will work.
>> >>
>> >>
>> >> ---
>> >>
>> >> Gregory A. Beamer
>> >> MVP; MCP: +I, SE, SD, DBA
>> >>
>> >> ***************************
>> >> Think Outside the Box!
>> >> ***************************
>> >>
>> >>
>> >> "CyberDigger" wrote:
>> >>
>> >> > I have two computers, client and server. The client is running
>> >> > Windows
>> >> > 2000
>> >> > Professional and is in a workgroup, say "MyWorkgroup". The server
>> >> > is
>> >> > running
>> >> > Windows Server 2003 Standard Edition and is in a domain, say
>> >> > "MyDomain".
>> >> > What I need is to logon to the client as some generic local
>> >> > administrator
>> >> > user and then access resources (e.g. share folder, SQL Server using
>> >> > Windows
>> >> > Authentication, etc.) on the server.
>> >> >
>> >> > Here is what I did:
>> >> > I create another local administrator user (user A) with on the
>> >> > client
>> >> > with
>> >> > the same username and password as a domain user (user B) on the
>> >> > server.
>> >> > I
>> >> > then access resources on the server by first logging on to the
>> >> > client
>> >> > as the
>> >> > generic administrator user and then impersonating to user A and use
>> >> > user A's
>> >> > credentials to access the server. I have two sets of such systems
>> >> > in
>> >> > two
>> >> > environments. This works fine in one environment, but not the
>> >> > other.
>> >> > In the
>> >> > environment that works fine, when accessing the server, user A is
>> >> > automatically viewed as the domain user B. In the environment that
>> >> > fails,
>> >> > user A is not recognized as a domain user on the server, i.e. it's
>> >> > not
>> >> > automatically mapped to user B.
>> >> >
>> >> > There're only 2 differences between the two environments:
>> >> > Environemnt 1: Server is domain controller. There's no firewall
>> >> > between the
>> >> > server and the client.
>> >> > Environment 2: Server is a member server of a domain, the domain
>> >> > controller
>> >> > is another computer residing somewhere else. There's a firewall
>> >> > between the
>> >> > server and the client.
>> >> >
>> >> > I don't think the problem is with the firewall, because I can get to
>> >> > the
>> >> > server from the client successfully (I can ping), and I also did see
>> >> > the
>> >> > logon request coming over to the server from the client. It's just
>> >> > that the
>> >> > logon request fails (in environemnt) 2 because the client user (user
>> >> > A)
>> >> > is
>> >> > not mapped to the domain user (user B). In the EventViewer (I have
>> >> > auditing
>> >> > on), it reports logon failure because user doesn't exist (error code
>> >> > 0xC0000064).
>> >> >
>> >> > Any idea on why it fails in environemnt 2? Also any idea on how to
>> >> > tell the
>> >> > Windows server to look for the username in the server's domain
>> >> > rather
>> >> > than
>> >> > just looking for it in the local user list on the server? That
>> >> > username is a
>> >> > domain user on the server, not a local user.
>> >> >
>> >> > Thank you very much.
>>
>>
>>