"CyberDigger" <Cy*********@discussions.microsoft.com> wrote in message
news:BF**********************************@microsof t.com...
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.
Wait, is user B a domain user, or a user local to the server in question?
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.
Pardon, but I think you meant to say: "and then impersonating to user B and
use user B's credentials to access the server.", correct?
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.
The language seems somewhat vague. If you are impersonating user B from a
local user A logon, then it is not up to the server to "map" (whatever that
actually means) from the local user A to the domain user B, or to "view user
A as user B". The use of the credentials of domain user B mean that, for all
intents and purposes, your connection to that server resource is a
connection by user B. The only association with user A is that the
impersonation is being done/alternate credentials are being used by/from a
logon of local user A on a remote workstation, a fact that should be
unknowable by the server being accessed (IMHO). At least, I do not think
that AD has the capability of considering a workgroup as a trusted domain.
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.
Are both clients w2k pro, and configured as members of a workgroup?
I don't think the problem is with the firewall, because I can get to the
server from the client successfully (I can ping),
IMHO, being able to ping a computer does not necessarily mean that all
functionality is available.
and I also did see the
logon request coming over to the server from the client.
Was this a "logon" request, or a request to connect to a share on the
server?
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).
It fails, yes. But I do not know what it means to map users.
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?
Though not my area of expertise, I suspect that we have not quite ruled out
the firewall issue completely. Also, you have not explained in much detail
which of the possible "impersonation" mechanisms you are using to
logon/access resources.
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?
Have you tried qualifying the domain username by prefixing it with the
domain name, i.e. "MyDomain\UserB".
What are the share and folder permissions on the resources on the two
servers? Could it be that the permissions on the member resource server are
more restrictive, and that the connection succeeds on the DC, not because
the impersonation worked, but because the permissions are more wide open?
Think "everyone" vs "domain users" vs "authenticated users".
That username is a
domain user on the server, not a local user.
Again "domain user on the server" means which of "domain user" and "local
user on the server"?
You mention that the failing environment (#2) involves a firewall. Is this a
dialup, VPN, or dedicated LAN/WAN-type connection? Are the networking
components configured the same for the two clients? Could you possibly test
these systems in different combinations, i.e. move the environment 2 unit to
the other side of the firewall? If the DC's involved are all in the same
network, what happens when you try to connect env#1's workstation to
resources on the member server? Or when you try to connect env#2's
workstation to resources on a domain controller?
In short, I would identify all of the actual configuration differences, and
introduce each to the working environment individually to see which causes
that environment to fail. If none, then try them in combination. Then also
try eliminating those differences from the failing environment.
/Al
