Archive for August, 2017

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); 


I recently configured my Ubiquiti/Ubnt Unifi wireless access point to use WPA Enterprise (wpaeap) and pointed Radius at my domain controller running Network Policy Server (NPS).

I could connect fine using my Android mobile but could not connect from my laptop. Logs in the event viewer indicated an authentication issue, but this was definitely not the case.

After lots of fiddling and googling I discovered that PEAP does not work with wildcard SSL certificates. I replaced the certificate with a server specific cert and voila.

Here’s an article which shows you where to change the certificate;

%d bloggers like this: