...
The instructions for adding AD to a Windows Server VM are covered in detail in Howto Create Standalone AD Server - Identity and Access Management - Confluence (atlassian.net). /wiki/spaces/IAM/pages/51607680.
That article describes a trick that nobody would use to create a real enterprise AD, but which is extremely helpful in a Sandbox. Before creating the AD, you add all your common Workgroup administrator usernames and passwords as Local Users on the Windows Server machine. At this point, the Windows Server behaves as a member of the Workgroup.
...
Impersonation is used by SSH when you use public key authentication.
SSH Server
Every new Windows system gets the SSH client. On Windows 10/11 or Windows Server 2022, the SSH Server is an optional Feature that can be installed. The OpenSSH server (sshd.exe) runs as a background service under a SYSTEM userid. It is authorized to use impersonationSSH is a protocol developed for Linux and then adapted by Microsoft to Windows. It is important for interoperability between Linux and Windows, but as a result it does not precisely align with the other Microsoft strategic decisions for Windows communication and security.
The SSH client comes preinstalled on modern Windows systems. Add the usual files to your home directory and you can use it to access Linux computers.
On Windows 10/11 and Windows Server 2022, the SSH Server is an Optional Feature that you can install from a Settings panel. It becomes a service and runs a program called sshd.exe in the system background. You have to administratively start the service and configure it to start automatically if that is what you want.
On Windows Server 2025 OpenSSH server Server will be pre-installed, but will have the service will still be stopped and has to be started manually or reconfigured to start automatically.
The Windows version of the SSH client is ssh.exe on Windows and just “ssh” on Linux.
You can run ssh.exe to prompt for a password. When SSH is called with a userid and password, it does a internal Re-Login and then the password is available to do Workgroup Authentication, and if the userid was a Domain userid (HUNTING\bellman) then Kerberos was used and leaves behind the TGT needed to talk to other machines.
Normally, people put a secret key file in their Home directory on the SSH client and a pubic key in their Home directory on the SSH Server and do “public key” SSH authentication. The SSH server verifies that the client knows the secret key, but now with no password to do a Login, all it can do is impersonate the user by starting cmd.exe under that user’s SID. This session will then have access only to local files and services.
SSH uses the secret key in the Home directory of the currently logged in use on the client machine. The ssh command contains the userid and computer name of the SSH Server. The userid in the command defaults to a Local User unless you explicitly qualify it with a Domain name. The userid you are logging in as does not have to in any way match the userid you are logged into on the client machine. SSH is the only form of programmed session that works between a Domain user account on one machine and a Local user or even a user in a different Domain on another machine.
When the OpenSSH Server starts cmd.exe, whether through a userid/password or public key impersonation, if the user specified in the command is a member of the Administrators group on the machine, sshd.exe has to decide whether cmd.exe will run in user or administrator mode. It has to be one or the other, and there is no way in cmd.exe to elevate from user to administrator mode through SSH. They decided that most people using SSH want to do admin stuff, so they opted for cmd.exe to run elevated from the start.
However, program is compatible with the Linux command, but tolerates the Windows “\” file separator. If you want to login as a Domain username, the command form is:
ssh YALE\netid@computername
If you leave off the Domain prefix, it searches for a Local User account.
You can login with a password. SSH will prompt for the password if needed. If you are connecting to sshd.exe on a Windows computer, it does a re-Login (RunAs) to generate new local credentials to run commands on cmd.exe on that machine. If the account is a Local User then the saved password allows Workgroup authentication. If this is a Domain User, then a login was done to the Domain and a TGT object was generated. Either way, the commands running on the Server machine have full access to services in the Workgroup or Domain.
However, Linux programmers normally use “public key” authentication. They put a text file with their secret key in their Home directory on the client machine, and a text file containing their public key in the home directory of the account to which they want to login (the account name before the “@” in the ssh command). If the public key verifies that the client has the secret key, then sshd.exe will use Impersonation to run cmd.exe under the SID associated with the account named in the command.
As with all impersonation, without a password there is no access on the server machine to Workgroup files or services, and without a Kerberos TGT there is no access to Domain files and services. However, the cmd.exe session has access to file, services, and even SQL Server databases that are local to that one computer.
If the user you are logging in as is an Administrator of the machine, ssh.exe starts cmd.exe in “elevated” mode so it can run admin commands. For whatever reason, the programmers who wrote sshd.exe decided that they wanted an extra level of permission to do thisrun administrators. Therefore, to login as any user in the Administrators group of the remote machine, the SSH public key has to be a line in the Windows file location of C:\ProgramFiles\ssh\administrators_authorized_keys ( instead of the normal $HOME/.ssh/authorized_keys file in the individual user’s home directory).
PowerShell Remote using SSH
There are some standard Windows Management tools that allow you to administer other machines over the network. The PowerShell has powerful command to administer all aspects of a computer. By default, it uses Windows Management Instrumentation (WMI) protocol authenticates to communicate between two machines that are members of Domains using the Kerberos protocol, and it authenticates between two machines that are not members of any domain using the workgroup protocol. If one machine is in a domain and the other is either not in any domain or is a member of a different untrusted domain, then WMI doesn’t work.
A developers Sandbox consists of a laptop that must be a member of the YALE Domain, plus VMs that may be workgroup machines or may be members of the internal test SANDBOX domain. WMI doesn’t work across all of them, and yet the developer wants to be able to administer the machines centrally without have to login to each of them one at a time.
PowerShell Remoting can now use SSH between computers. To set this up, you need your private key on the system from which you will be doing administration (typically your native laptop in the YALE Domain) and you need a userid in all the other machines that is a member of the Administrators group, and you need your public key to be in the C:\ProgramData\ssh\administrators_authorized_keys file.
Now domain membership doesn’t matter for any of your VMs. You can run PowerShell commands that do machine administration by adding, for example:
-UserName bellman -HostName SNARK
on PowerShell commands such as Invoke-Command or New-PSSession that operate across computers. Note that you replace the WMI parameter -Computer netname with the SSH parameter -HostName netnamemachines. WMI works very well between two machines in the same Domain, and it works with a bit more effort between two machines in the same Workgroup. It does not work at all between two machines one of which is a member of a Domain and the other is not a member of the same Domain.
PowerShell added the ability to send commands or whole blocks of code between computers using SSH instead of WMI. All you do is use the -Hostname parameter instead of the -Computer parameter to specify the target system (the string after the “@” in an ssh command), and you must add -Username to specify the account name (the string before the “@”). Using PowerShell over SSH means that every VM or computer in your Sandbox, including Linux machines and the Yale Managed Workstation can participate and all interoperate freely.