As many of you know, I am an independent consultant and use my own laptop when possible. I’ve got all my tools set up the way I like them and everything else that I need to be productive. Given that I work for multiple clients, I can’t join my laptop to any particular client’s domain. First is the hassle factor, especially when switching between different clients within a week. Each domain join requires a domain admin to authorize the join by typing in his/her credentials when prompted on my laptop. Second I don’t want a client’s Group Policy being applied to my laptop. Third – and more importantly – is the non-disclosure agreements that I sign with clients. If I join my laptop to a domain, the domain admins have full rights to my machine and hence data from other clients. So domain joining just isn’t an option.
In most cases, not being joined to a client’s domain doesn’t make one iota of difference. You need to access a network share or printer, browser to it and you will be prompted for 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 one bit. If you want to expedite the process and not wait for an authentication time-out, you can utilize NET USE from the command line to tell Windows which credentials you want to use when accessing certain computers. You can even make them persistent or roll the whole thing into a batch script that you can execute whenever at a particular client.
net use \\server /user:domain\username /persistent:yes
Unfortunately this doesn’t work in all cases. One of my longstanding development pet peeves has been certain tools – I’m looking at you SQL Server Management Studio and SQL Query Analyzer – that don’t allow you to specify alternate domain credentials for authentication. For example, SQL Server Management Studio 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 horribly if not. It doesn’t let you specify alternate credentials or even prompt you for alternate credentials if the log-in fails.
I’ve tried seemingly everything. NET USE doesn’t help here because NET USE is specifically for network shares.
net use \\sql-server-name /user:domain\username # DOES NOT WORK – Only provides the domain credentials when accessing shares
RUNAS also fails – either the SHIFT right-click variety or command line – 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.
runas /user:domain\username “C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe”
For years (yes, years) I have resorted to using Remote Desktop to log into a domain computer so that I could run SQL Server Management Studio, used a domain-joined virtual machine, or begged co-workers to run commands for me. Now I feel foolish because I stumbled upon a solution that has been built into Windows for years. It is a simple command line switch for the RUNAS command that I never noticed: /netonly. (Note that the /netonly flag is not accessible via the SHIFT right-click menu, only via the command line.)
runas /netonly /user:domain\username “C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe”
Success! And SQL Server Management Studio running using /netonly domain credentials. The command is run as my local user, but uses the supplied domain credentials only when accessing the network.
I can access remote SQL Servers using Windows Authentication without problem now! (You’ll have to take my word for it or try it yourself as it would be impolite for me to show screenshots of me accessing a client’s SQL Server.) Hopefully this makes some other consultant’s life a little bit easier.
