...
All programs run under a SID. Some programs run in the background under Microsoft built in SIDs like SYSTEM. Other programs inherit from the session the SID of the User that authenticated to the computer.Ordinary users Ordinary users login with a userid and password, get a session with the corresponding SID, and then all the programs run in that session use that SID.
Anyone can run a new program under a different userid by triggering a new Login for that program where they enter the and provide or prompt for a new userid and its password. This is typically called “doing a RunAs”“RunAs”.
However, components that are part of Windows or run as part of the System can call a service that lets them temporarily change the SID a program is running underare authorized to temporarily change their SID to any other SID defined in the system. This is called “impersonation”.
A program that is normally running as System may change its SID to user “bellman”, but it does not then know the password of user “bellman”, nor does it have any credentials from the AD Domain. As a result, it cannot make network requests to other computers using either “workgroup” or AD Kerberos. It can access local files and local services as “bellman”.
SSH Server
When you install OpenSSH Server (sshd.exe) on Windows, it runs as a service under a System ID.
If an SSH client logs in through SSH with a userid and Changing the current SID does not create a userid/password or get the Kerberos “TGT” object needed to authenticate across a network using an AD Domain. So, while the program can temporarily use files and call services on the local machine, it cannot do anything involving other machines.
SSH Server
Every new Windows system gets the SSH client. The SSH Server is an optional Feature that can be installed on Windows desktop or server systems. The OpenSSH server (sshd.exe) runs as a background service under a SYSTEM userid. It is authorized to use impersonation.
The client ssh program can either present a userid/password or a public key. If it presents a password, then sshd.exe can use them to do a secondary Login. This generates a user session that has a full credential that can be used for “workgroup” or AD domain authentication to remote network services including shared disks and SQL Server databases.
However, if you use public key authentication to SSH, then no password is provided. Then sshd.exe can only do an “impersonation” and create a process to run the command passed by the remote user under the local SID of the userid specified in the SSH client connection. The SSH session can access local files permitted to that user, and SQL Server databases on that one machine, but there is no access to network services and files on other machines.
The SSH client can connect using public key authentication to either a local user account or a domain user account. The client private key simply has to match an entry in the authorized_keys file of the .ssh subdirectory of the home/profile directory of the local or domain user. The sshd.exe program can impersonate the local SID or the domain SID. However, creating a session with the domain SID does not generate Kerberos login credentials (a TGT object) just as impersonating a local SID does not provide a password for workgroup resource access. An impersonated domain SID can access local files permitted to that domain user, and can connect to a Login in a SQL Server instance on the local machine, but no access outside the machine is provided. Of course, the client could force a userid/password authentication instead of using the public keys, and then there would be a TGT granting access from the domain account to other computers on the network.
Sandbox Administration
A Developer Sandbox is a set of VMs, some Linux and some Windows, that are used to test applications. An IAM developer may have a Windows Server VM in the Sandbox with an Active Directory. Typically, a Sandbox AD is called yu.yale.sandbox (alias SANDBOX)
No computer or VM can be a member of two Domains, and a Sandbox AD cannot be configured to know about and “trust” the production yu.yale.edu (alias YALE) AD domain. This means that the developers laptop managed workstation is a member of the YALE domain, while other VMs in the sandbox may be unaffiliated “workgroup” computer or members of the SANDBOX domain.
The Windows tools that allow administration across the network are designed to work easily when both machines are members of the same Domain. They work a bit less simply if both machines are in a “workgroup” connected to the same LAN and the same Administrator userid and password are defined on all machines.
However, Windows admin tools do not work when one machine is in a Domain and the other machine is in a Workgroup, or when the two machines are members of different Domains such as YALE and SANDBOX. However, the PowerShell remote commands and sessions (Invoke-Command, New-PSSession) now support SSH between computers and can use public key authentication that works even when the client is the laptop on the YALE Domain and the remote target is either a standalone workgroup VM or a member of the SANDBOX Domain. Generally there is a PowerShell command for any administrative action you want to perform, so you can build PowerShell admin scripts that use
Invoke-Command -UserName bellman -HostName SNARK {…}
in cases where the normal
Invoke-Command -Computer SNARK {…}
doesn’t work because of mismatch between the current logged in user and the affiliation of the target machinedo a RunAs login to create a new cmd.exe session running as that user. This session has the password and if it is a Domain userid it has the Keberos TGT object needed to authenticate to network services.
However, sshd.exe can also authenticate a user with a public key. The client uses a private key that has to correspond to an entry in the $HOME\.ssh\authorized_keys file of the specified userid. The userid can be a local user with a SID from the local machine, but it can also be a domain userid with a SID from AD. However, when sshd.exe impersonates a domain SID it does not magically generate a Kerberos TGT that a real domain user would have from a real Domain login. The local SID is good on the local machine for accessing local files. It can even make to the local SQL Server running on this machine.
If the $HOME\.ssh directory contains a private key, then it can be used to ssh to another machine in the network. Alternately, the end user can type in a userid and password to use when connecting to another computer. The only restriction is that the “currently logged in Windows user” level of authentication is only good for accessing things on the local machine when running a session created by ssh using public key authentication.
There is a special Windows-only configuration problem. If a user is a member of the Administrators group, then sshd.exe has to decide whether to start the new cmd.exe session in “elevated” (Run as Administrator) mode. It is not possible once the session gets going for someone to successfully elevate in the middle of a session since there is no way to answer the popup Window that you are presented when you elevate in a normal desktop login. Therefore, sshd.exe will always start Administrator users in elevated mode. If you want to run in non-elevated mode, you need two userids to use with SSH, one who is an Administrator and one who isn’t. For security, when someone in the Administrators group logs in through SSH their public key certificate is checked against the list in C:\ProgramFiles\ssh\administrators_authorized_keys instead of the authorized_keys file in the 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 Windows Management Instrumentation (WMI) protocol authenticates 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 netname.