My company provide SQL dba services and build system integrations. We use various VPN clients to connect in to most company networks but have always had issues using integrated windows (active directory) authentication with certain applications.

Launching an RDP session or browseing a network share works just fine, but if we want to connect SQL Server Management Studio to a server on the remote network using our domain credentials we have previously been stuck. Leading us to deviate from (what I feel is) best practice and create sql users.

When we build interfaces in Visual Studio they will normally run on client servers using active directory/domain service accounts. If we wanted to carry out any troubleshooting we could not accurately emulate the interface in Visual Studio (as the domain service account).

If our local machines were joined to the client domain we could either log on as the service account or run SSMS / VS as the network user, but otherwise we are out of luck…

…that was until we stumbled across the /netonly command line argument for runas.exe.

Apparently this whole time there has been a technique to launch an application using credentials which don’t exist locally or on the current/trusted domain! We now have some .bat files saved which launch our core applications using runas.exe with the /netonly argument. For example;

runas /netonly /user:remotedomain\remoteuser “C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\ManagementStudio\ssms.exe”

*EDIT* Furthermore, i’ve just stumbled across ShellRunAs which will integrate into windows explorer and give you the right click option to Run As (Netonly);