Copyright

Return to index

********************************

You can make 2 separate connections to the same machine, using different logon credentials, if one connection is to the machine's name and the other is to it's IP.

Let's say you're logged onto your NT workstation with a domain account (mydom\myacct) that has User rights on a remote server (remsrv) and you currently have one connection open to remsrv (e.g. you have your h: drive mapped to \\remsrv\users). Now you realize that you need to access a file on remsrv that is only available to administrators. You have 2 options:

  1. Disconnect all existing connections to remsrv, then reconnect to it, using an administrator account. For example:
  2. net use h: /delete

    net use h: \\remsrv\users /user:mydom\myadmin

     

  3. Map a drive to remsrv's, using its IP address, instead of its name. Specify an administrator account for this connection.

net use j: \\192.168.1.1\users /user:mydom\myadmin

When you access files via your h: drive, you will have the permissions assigned to mydom\myacct. When you access files via your j: drive, you will have the rights assigned to mydom\myadmin.

 

This gets a bit trickier, when you try to use it with some of the administrative tools (e.g. User Manager for Domains). The problem is convincing the tool to use the NetBIOS session that has the necessary permissions.

Let's continue the example from above with remsrv as a member server (not a domain controller). You have already made the connection to the IP address. We'll assume you have User Manager for Domains installed on your wks.

  1. If you run 'usrmgr \\remsrv', you will be using the NetBIOS session validated with mydom\myacct. So you won't have the right to alter administrator accounts on remsrv.
  2. If you run 'usrmgr \\192.168.1.1', you will be using the NetBIOS session validated with mydom\myadmin. So you will have full administrator rights to remsrv's SAM.

As you can see, this works as expected in set of circumstances. In fact, this will even work, if you were to reconnect to the IP of the workstation you are currently logged onto, using an administrator account.

Now, let's say remsrv is the PDC of mydom.

  1. If you run 'usrmgr mydom', you will be using the mydom\myacct session. So you will not have administrator rights.
  2. If you run 'usrmgr remsrv', you will be using the mydom\myacct session. So you will not have administrator rights.
  3. If you run 'usrmgr \\192.168.1.1', you will be using the mydom\myacct session. So you will not have administrator rights.

The problem is that, when you attempt to connect to the IP of a PDC, UMFD detects that it is a PDC and resets the connection to the domain name. I suspect it actually goes through the process of querying the domain's name to locate the PDC, then connecting to that machine (by name). In any case, the result is that you end up using the connection to \\remsrv, instead of the one to \\192.168.1.1. So you don't have administrator rights.

BTW. I haven't tried it, but if you have a physically multihomed machine, you may be able to make additional connections of this type to the primary IP address of other NBT enabled NICs on the same machine.

********************************