Ever wanted to be able to access a client’s backend data source using Windows Authentication, but your machine wasn’t a member of their domain?

For example – you might be working with a client that can’t provide you with a client machine that has Excel or InfoPath, but you need to access data in SQL.

The usual problem I’ve run into is this – If I’m using my local Excel or InfoPath client, when attempting to add a new data connection, you get prompted with a screen such as that below.  Selecting Windows Authentication will use your local machine credentials  and won’t work.  The Username and Password box as we all know are for SQL authentication.

So how can we specify a username and password for an account on another domain? Well one would expect that if you’re VPN’d into the client network, a regular runas should work.  It doesn’t though, because the machine isn’t part of the domain:

Well, recently I found switch that does allow you to run an application as a user from another domain, and it seems to be fairly well hidden so thought I’d share it.

If you add the switch /netonly to the start of the runas command, the application will run, and the credentials will be passed through when needed.

runas /netonly /user:clientdomain\accountname “C:\Program Files (x86)\Microsoft Office\Office14\Excel.exe”

Naturally you need to be able to access to the data source in the first place (e.g. VPN’d into the network and have a valid account) for this to work.  Pretty cool though.