Sql-server – Using integrated security over VPN

Since you are running in a workgroup the only possible authentication is one using 'mirrored NT accounts', which means that the process trying to authenticate must be running under an identity that is 'mirrored' on the host that is authenticating the process. 'Mirrored' accounts are distinct local accounts with identical name and password on both hosts doing the authentication.

So it must follow that you're running SSMS from an account that it is mirrored on the SQL Server host (eg. <computername>\Administrator, which is mirrored by the <sqlhost>\Administrator and has the same password). Note that UAC has nothing to do here (ie running as administrator will not help).

Your application is probably running under a different local account (default IIS appool perhaps?) and the account under which the application runs is not mirrored on the SQL Server host.

Your best solution is to ditch the makeshift network and deploy a proper AD (domain). As an interim, make sure you run your application under an account that is mirrored on thew SQL Server host machine.

Regarding providing DBA access, you might be better-off creating an Active Directory group and adding the DBAs into that group. That way, you can provide group-level permissions and give sysadmin to the group rather than individual users, meaning that when a DBA leaves (or a new one gets hired), you just need to adjust Active Directory rights rather than going into each SQL Server and altering logins. The same applies (though without granting sysadmin!) for other groups of internal users. Windows authentication is more secure than SQL authentication, and if you can use it, you probably should.

Regarding auditing, you can still have individual-level auditing when users are in a group. You can use SUSER_NAME() to get the username in whatever process you're going to use to log activity. Note that somebody could do an EXECUTE AS to switch their user context, but you should be able to log that as well as the IP address from which the query came, so you'd still be able to correlate activity to a person.

The idea of using a jumpstation (in your case, you mentioned a server) is possible. It would make administration a bit easier, especially if the laptop domain does not have a full trust relationship with the domain upon which the SQL Server instances are located. It would probably be a bit annoying for the support personnel, honestly, but if you go that route, I'd recommend a virtualized desktop for each IT support team member. That way, they don't have to deal with server contention issues and you can minimize the pain. If you do go down that route, then the IT support team members could have domain accounts and you'd create relevant Windows groups the same way as the DBA group.