As a consultant or contractor, many times the client we are at does not provide us with a laptop, so we must use our own.  Usually that is preferred anyway, as we have all the software and tools installed and setup the way we want to make us as productive as possible.  And since we may be working for multiple clients, that means there are multiple client domains we have to access.  But it’s a real pain to have to join all the clients domains, for the following reasons:

1. The constant switching between domains if I am working on different clients at the same time can be a real hassle
2. Each domain join requires that each companies domain admin has to authorize the join by typing in their credentials when prompted on my laptop
3. When joining a domain, each companies Group Policy would be applied to my laptop
4. The domain admins would have full rights to my machine and therefore data from other clients

Usually, not being joined to a client’s domain is not a big deal.  If you need access to a network share or printer, just browse to it and you will be prompted for your domain credentials.  The fact that you’re using different domain credentials to access the resource from those that you logged in with doesn’t matter.  If you want to maintain a persistent connection to a network share (and avoid a authentication time-out), you can create a batch file and include commands like:

NET USE \\server /user:domain\username /persistent:yes

However, there are certain tools, such as SQL Server Management Studio (SSMS), SQL Query Analyzer, and Visual Studio, that don’t allow you to specify alternate domain credentials for authentication.  For example, SSMS allows you to log into a SQL Server instance using Windows Authentication or SQL Server Authentication.  If the SQL instance requires Windows Authentication – the recommended configuration – SQL Server Management Studio uses your logged in credentials.  This works well if your computer is part of the domain, but fails if it is not.  It doesn’t let you specify alternate credentials or even prompt you for alternate credentials if the log-in fails.

So how do you get around this problem?  NET USE doesn’t help here because NET USE is specifically for network shares.  Using the SHIFT right-click on a program that gives you the “Run as different user” prompt does not work either as it tries to run the command locally as the domain user, who is unknown by your computer because you’re not part of the domain.

There are a few “undesirable” solutions: remote desktop into a domain computer so that you could run the tools such as SSMS, use a domain-joined virtual machine, or ask co-workers to run commands for you.

The two “desirable” solutions are:

1) Use the RUNAS command with an option that most people have not noticed: /netonly.  The command is run as your local user, but uses the supplied domain credentials only when accessing the network.  For example, to run SSMS:

RunAs /netonly /user:domain\username “C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe”

You will be prompted to enter a password when you run this command.  That could be a pain, but fortunately there is a utility that is a RunAs replacement that allows you to specify a password.  It is called CPAU.

2) Use the ShellRunAs utility.  It provides functionality similar to that of RunAs to launch programs as a different user via a convenient shell context-menu entry.  It is essentially the same thing as using the SHIFT right-click on a program which gives you the “Run as different user” prompt, except this gives you a “Run as different user (netonly)” prompt, meaning it adds the “netonly” switch.  This is more convenient than the RunAs command as you don’t have to type a long DOS command.

I have found these solutions very helpful for testing purposes.  For example, say I created a role in a SSAS cube called “Northeast Role” that is granted access to only a particular subset of data, the northeast region.  The membership of this role includes a windows group, say “Northeast region”.  I can have a test windows account created, say “NEtest”, and have that account placed in the “Northeast region” group.  To make sure that user is only able to see the northeast region, I can use one of the above solutions to login as “NEtest” via Excel to access the cube and make sure it’s working as it is supposed to.