...
SQL Server can only backup and restore databases to files on a local disk. When you run SSMS you can build a backup or restore request for a *.bak file on a network disk you have access to, but when that request is sent to the SQL Server it cannot access the network share so the backup fails. When you run
Hyper-V Manager you can configure a VM to mount an ISO DVD image from a network disk you have access to, but when you try to start the VM it will fail because Hyper-V itself cannot access the network diskruns as System and only has access to files on local disks. Every VHDX that you attach to a VM and every ISO DVD image that you mount has to be local. To import a previously exported VM, the files generated by the export have to be on local disk.
Typically, an administrator has to do a Remote Desktop login to a machine and copy network files to a local disk before a restore, import, or mount operation or copy/move files from local to network disk after a backup or export operation.
Local User SIDs created on your Computer
...
The SID for a Local User account is unique on one machine and is meaningless on other machines. You can see this by logging in as a non-admin Local User, creating a file on an NTFS formated formatted thumb drive, and then moving move the drive to another computer. The other computer has no idea who owns or created the file . because the Local SID are meaningless across a networkgenerated by that computer is meaningless to other machines.
When you login to a computer, it runs everything in your session under your SID.
Workgroup Authentication
Personally owned machines or VMs are not members of an AD Domain, but they can be on the same home or small business network. To allow simple administration and file sharing between Windows 11 computers on such networks, Microsoft has a form of Network Authentication for a “workgroup” with only Local Users.
If you create two Local Users on two personally owned computers and give each the same username and password, then the two accounts have different SIDs on each machine. Again you will see this if you create If you put a file on a thumb drive USB disk and move it to the other computer. Although the same Userid exists on both between machines, it is the SID and will not be recognized on the Userid that is stored with the file, and that SID is meaningless on any machine other than the one that created the file.However, in this case things are different across the network. When someone running under a Local User account tries to connect to another computer on the home network, Windows uses an authentication mechanism called NTLM. The two machine that did not create it.
However, if one machine shares a directory and the other machine maps that shared disk to an unused disk letter, “workgroup” authentication now applies.
Traditionally workgroup authentication has used a protocol called NTLM (or NTLMv2 in its latest version). Starting with some future version of Windows 11 after 24H2 Microsoft will be adding a new protocol based on Kerberos called LocalKDC. The difference between the two will be transparent to end users.
Either way, the two computers, without transmitting the password, agree that the server computer has a userid with the same name as the user currently logged into the client machine, and the password associated with this userid is the same on both machines. The server Server end of the connection is then assigned the SID of the matching Userid on that machine.
This “two local users with the same name and password must be the same person” approach was called “Workgroup” computing when Microsoft created it 30 years ago. Microsoft doesn’t talk much about it today because they would much rather sell you disk space in the Azure cloud and put OneDrive on all your computers, so you transfer a file between two of your home computers by sending the file 1000 miles away and then having Microsoft send it back again, but to the other machine.
[Note: Microsoft has announced that in the future it will replace the NTLMv2 authentication protocol with a version of Kerberos called LocalKDC. Every Windows 11 system will be able to perform Kerberos Authentication of remote Network sessions using Local User accounts. This will be an internal drop-in replacement for NTLM for file sharing and network administration in Workgroups and will be transparent to end users. It is separate from the traditional use of Kerberos in AD Domains.]
Fully Qualified Usernames
Typing out a long meaningless unique number is hard, and remembering it is impossible.
So there is a notation that we use to describe the specific account without using SID. You qualify the Userid by a prefix indicating the machine or AD in which the SID is assigns it matching Local User SID to the session, and the client computer has access to the same files and services that are permitted to that Local User.
Normally, users just learn to install their same userid and password as a Local User (typically in the Administrators group) on all of the computers and VMs that they install or their home network and then they have access across the network to all services and files on all machines. They may never bother to learn terms like “workgroup”, “SID”, or “NTLM”.
Fully Qualified Usernames
While two userids with the same password match each other and allow access over the network, they still have different SIDs, and this may be important when you move disks from one computer to another. There is a Windows notation to explicitly prefix a username with the machine or AD domain where it was defined.
Assume there are two computers named SNARK and BOOJUM and each has an account named “bellman” with the same password on both machines. The notation “SNARK\bellman” means the account (and SID) for bellman on SNARK and “BOOJUM\bellman” means the account on BOOJUM.
If bellman logged into SNARK contacts BOOJUM through the network, then BOOJUM verifies that it has a local user also named “bellman” and that the password for “bellman” is the same on both BOOJUM and SNARK. So, it assigns the SID of BOOJUM\bellman to the request coming from the this network session and allows the remote SNARK\bellman client to access files as BOOJUM\bellman.
...
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.Authorized system components can .
Ordinary users can run a new program under a different userid by triggering a new Login for that program where they enter the new userid and its password. This is typically called “doing a 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 under. They may do a new authentication to get the SID, or in some cases simply look it up. Generically, this is called “impersonation”.
Programs running under a new SID have access to all the files and services permitted to that SID on the current machine. However, if they do not have the password for the user or a login to the Domain under that account (what is technically called a “Ticket Granting Ticket” or TGT) then they cannot access files or services on other computers.
If you use SSH to connect to another computer using your public key file (in your .ssh directory) then you do not transmit a password and do not create a TGT. Your resulting SSH session can only use local files unless you transmit through the SSH tunnel a command containing a userid/password that the remote machine can use to login to something on the network.
However, if you SSH to another computer with your userid and password . 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 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, then the password is transmitted over the encrypted SSH tunnel, and the other machine can login and save the password. Then the saved password can be used to create connections from the remote machine to other systems in the local network.
Most of the time, however, “impersonation” is a term associated with special applications. It is used in cases where an authorized application performs an operation on behalf of a remote user while switched to the SID of that remote user. This is a complicated programming technique outside the scope of this article.
There are also network administration tools that can be configured to transmit the password or some other token of fully authority (like a TGT) from the client computer to a remote machine, so the remote machine can perform operations with the full authority of the client. This is useful but creates a vulnerability if the remote machine has been compromised. This is also a complex topic outside the scope of this paperand 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 machine.