Peter Seale's weblog

Bullet point summary, for the skimmers

Your attention is already waning, so I’ll get with the bullet points:

• Runas is useful in surprising ways, including troubleshooting build breakages, security testing, and running as your service account. This is the old, boring runas.
• Runas features the /netonly switch, which makes the impossible possible on VMs and off-domain machines. I’ll save some of the thunder for later.

Introduction

I feel sorry for everyone who is forced to do their day-to-day work on a corporate machine. It seems that in the last few years, virus scanners have dug their filthy, performance-sapping claws into your network connection, your email, and your (Internet Explorer) browser. All this added to the “scan every file before it’s accessed” behavior we’ve all come to know and love.

On behalf of corporate IT everywhere: you’re welcome.

It’s brutal out there for those of us beholden to the dreaded corporate desktop image. Oops—did I say us? I mean you. You—you’re beholden to whatever IT gives you. I’m living the high life*.
* this is a metaphor 

At work we’ve run some tests (literally—we routinely run a pile of integration tests), and my old, busted laptop* is somewhere in the area of five times faster than the new hotness desktops running the corporate Windows XP image. But let’s not belabor the point.
* “What a piece of junk!” “She'll make point five past lightspeed. She may not look like much, but she's got it where it counts, kid. I've made a lot of special modifications myself.”

For those of you reading this on a corporate desktop, thanks for getting this far, but the following blog post probably won’t help you. You’re already on the domain, so you will rarely (if ever) need this trick! Enjoy running Windows XP for another five-to-ten years!

Now that we’ve gotten rid of the losers

…let’s get on with it. Runas allows you to impersonate another user while running most any Windows app.

For server admins, this means you can run with an unprivileged account for your day-to-day tasks (like waiting patiently while Outlook runs chkdsk on your 4GB PST file) and perform your catastrophic admin mistakes (like accidentally promote a domain controller) inside a management console or command shell running as a Domain Admin. You still make catastrophic mistakes, but not catastrophic mistakes specifically because you’re running a Windows account with full administrative privileges all the time. There’s a whole world of catastrophic mistakes for you to discover and experience as an admin. Moving along.

This Runas behavor is the plain, vanilla Runas , and you can get this behavior by SHIFT+RIGHTCLICKing on pretty much anything in Windows. To make things easier, you can also create shortcuts on your desktop to always prompt you to log in as someone else (AKA “run as” someone else).

For developers, this means you can run SQL Server Management Studio as your app’s service account so you can talk to your test database…your app’s test service account, I’m sure.

Also for developers, you can also launch a browser window as another Windows user. This is a great trick for testing out security on web apps that use Integrated Windows Authentication.

Also also for developers, you can impersonate your build service account to run your build so that your prompt runs 100.0% precisely the way TFS/TeamCity/Whatever runs it, in order to troubleshoot any weird problem with your build. <==THIS IS A LIFESAVER

For SP admins, you can launch browser windows as your farm account or whatever admin account you have, or of course, completely unprivileged accounts to test security trimming.

Let’s see this in action:

Let’s break down what just happened:

1. I ran PowerShell as myself (username “P”). This is evidenced when I interrogate the USERNAME environment variable.
2. From PowerShell, I perform a Runas cmd.exe. This launches the cmd.exe shell.
3. From the impersonated cmd.exe shell, I interrogate the USERNAME environment variable. This shell is running as svc-sql. So smooth.

And yes, I give the SQL instance running on my laptop its own service account…what of it. I’m not crazy.

But I knew all that already—what if I’m not on the domain?

I’ll bring the thunder, I promise.

First of all, a slight technicality. Wherever I say “domain” in this blog post, I mean “AD forest”. Sometimes being precise with your vocabulary isn’t helpful.

So. There are two major scenarios wherein you need (absolutely NEED) to run as a user on a different domain.

ONE: you’re running a virtual machine running in its own little virtual world on its own virtual domain, and NEED to talk to the real domain, so that you can connect to the test database server and run some queries.

TWO: you’re running on a non-domain laptop running its own brand of non-corporate-imaged bliss, and NEED to talk to the real domain, so that you can connect to the test database server and run some queries. Maybe accidentally DROP some databases while your users are testing.

NEED. This is the face of NEED.

Also, more rarely, if you NEED to connect Microsoft Excel directly to your database server to run a query, but must authenticate with Integrated authentication as another user? And you’re running off-domain? Don’t puke: pivot tables are really, really beautiful, and I mean that sincerely. My love for pivot tables is pure as the driven snow. Anyway, I’m not here to defend my Excel+SQL abomination, I’m here to bring the thunder.

Enter the /netonly switch

Using runas /netonly allows you to run your app locally as you (in my case, the user named “P”), while authenticating over a network with another user. It’s like a rare kind of magic, like a hornless unicorn.

Also like rare magic, I have no idea how runas /netonly works. There’s probably somebody who knows how it works (someone who has gazed into Win32, and Win32 has gazed back into them), but not me. It’s good enough for me to know that runas works…somehow.

Let me try to break down what just happened in the screenshot above (and note the differences with between vanilla runas and runas /netonly):

1. I ran PowerShell as myself (username “P”). This is evidenced when I interrogate the USERNAME environment variable.
2. From PowerShell, I perform a runas /netonly cmd.exe. This launches the cmd.exe shell.
3. From the cmd.exe shell, I interrogate the USERNAME environment variable. The impersonated shell is still running as “P”. However, were I to authenticate with resources on another domain, Windows would send the credentials for “OnTheINTERNET\NobodyKnowsYoureADOG”.
1. This is the point where I should try to prove that, as far as authenticating over the network, your program behaves as if it’s the impersonated user. Unfortunately I just tried to connect to CodePlex’s TFS as my example, and the work involved connecting to CodePlex via TFS depressed me, so, I won’t be attempting this today. Just try out one of my sample scripts for yourself; it will take all of 10 seconds to verify. Side note: THANK YOU, CodePlex team, for first funding SVNBridge, THEN including direct SVN support, then providing direct Mercurial support.

Bringing the thunder: SQL 2005 management studio

REM the following script assumes a 64-bit system,
REM and assumes you installed SQL 2005 in the default folder
REM change the parts below in RED
runas /netonly /user:REALDOMAIN\YOURDOMAINUSERNAME "C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe"

Bringing the thunder: SQL 2008 (eight) management studio

REM the following script assumes a 64-bit system,
REM and assumes you installed SQL 2008 in the default folder
REM change the parts below in RED
runas /netonly /user:REALDOMAIN\YOURDOMAINUSERNAME "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\ssms.exe"

Bringing the thunder: Excel 2007

REM the following script assumes a 64-bit system,
REM and assumes you installed Office in the default folder
REM change the parts below in RED
runas /netonly /user:REALDOMAIN\YOURDOMAINUSERNAME "C:\Program Files (x86)\Microsoft Office\Office12\EXCEL.EXE"

Still not perfect

There are a few scenarios where this still doesn’t work:

• TFS command-line client running from inside a cmd.exe prompt. To be fair to the TFS command-line client, it goes out of its way to let you type in credentials at runtime.
• Remote debugging off-domain in Visual Studio is still a challenge. I just tried to set it up on my laptop this last week, and failed. Note remote debugging requires some firewall tweaking as well, so maybe this is a PEBKAC-type problem and not a runas /netonly problem.

You’re welcome

The pattern is simple: give runas your name, full path to the exe, and type in your password when prompted. If you have NEED to run the command frequently, create a batch file and quickly make a SlickRun MagicWord.

Or, let’s be honest, just drag a shortcut of your newly-created batch file to the Windows 7 start menu and be done with it. Searching for items in the Start Menu is almost as good as SlickRun—a good enough experience such that program launchers aren’t necessary anymore.

Credit where due…thanks, TWITTER! (and I guess, Ryan)