In all computer systems, there is some mechanism to define Accounts for users and services. It may be as simple as the Linux /etc/passwd file where each account has an integer with lower numbers for services and users beginning at 1000 and incremented by 1 for each new entry. Since Windows NT in 1994, each Windows machine has an account database called the SAM and each account has a much larger binary string called the Security ID or SID. Like Linux, Windows stores the number/SID to represent the owner and permissions to files and directories on disk, but not the owner name. That way, a user can be renamed at any time and the only place the name is stored is in the SAM.
Originally a Windows NT Domain was simply one NT system on the network that shared its SAM with other machines. In Windows 2000, Microsoft created a new much more powerful structure called the Active Directory, and they have been improving it since then. For upward compatibility, AD also uses the SID structure so an old NT Domain could be converted to an AD preserving all the information stored in existing disk directories.
A Windows 11 desktop machine still has a SAM. Accounts defined in it are called Local Users and Groups. In addition, the Windows 11 desktop can join an AD Domain, and then it can use a mixture of SIDs, some belonging to the Local SAM and some to the Domain.
While no Windows machine will create or use SIDs from more than these two sources (Local and Domain), you can move a disk from one computer to another. The disk can have file ownership and permissions related to SIDs that the previous machine knew about. These SIDs, which the new machine does not recognize as Local or Domain, are ignored. In theory a Windows 11 computer could leave one Domain and then Join a different Domain, resulting in some legacy disk entries for the old Domain which are now no longer recognized.
Users and groups have a name stored in the SAM or Domain. When Windows encounters a SID in its tables, it will replace the long unfriendly binary string with the corresponding name from the Account.
Accounts have a SID History to solve a special AD problem. Large organizations can have more than one Domain in their AD. Domains may represent the division of a company or the campus of a university system. If someone moves within the organization from a role associated with one Domain to a new role associated with a different Domain, administrators can move their Account to the new Domain. SIDs are specific to a single Domain, so during the move the Account has to be given a new SID from the new Domain, but it also has to retain the old SID which may be recorded in disk ownership or permissions. The previous SID is retained in the SID History. At any time, a user has access to resources permitted to the current or previous SIDs in their account.
When a computer joins a Domain, it is added as a Computer account to the Domain database. It gets its own SID from the Domain and establishes what amounts to a password it can use to authenticate itself to the Domain Controllers. Every time the computer boots up it tries to connect to the Domain and login as its own computer account.
To login with a Local account, you enter the userid and password on the computer, which looks the name up in its own SAM. To login with a Domain account, you enter the domain userid and password. The computer sends this login to the Domain Controller to verify the password, and the Domain sends back an object (the “TGT”) that programs you run can use to authenticate your Domain identity to computers and services on the network.
When Windows starts up the first time, it generates a 12 byte mostly random unique identifier string which becomes part of every SID in its SAM. We say that the computer has its own self-generated SID. When a Domain is created, a different 12 byte mostly random unique identifier string is generated which becomes part of every SID belonging to the Domain. This means that every Security Identifier contains either the unique ID of one Windows computer or one AD Domain.
Technically, you can create accounts with the same username in both the SAM of your computer and in the Domain the computer is joined to. To address the ambiguity, the username can be prefixed with either the Hostname of a computer or a Domain name. Thus on a Yale laptop that Yale named MWAB12C3D4, the name YALE\netid unambiguously refers to a Domain account while MWAB12C3D4\LocalSystem refers explicitly to the Microsoft built in account “LocalSystem” defined in the SAM of the machine and used to run most background services.
There are several types of Windows SIDs:
Microsoft has created some SIDs for services that perform Microsoft managed operations, like patching or upgrading the Windows system.
There are predefined Local Users and Groups that are machine specific, include the 12 byte generated string identifying this specific computer, but where the rest of the SID including the number of the specific account in the SID is the same on every machine. The LocalSystem user and the Administrators group are examples of this type of account
Generally, anyone can create a Local Group on their computer, or a Domain Group.
Ordinary Local Users are created by you as administrator of a personally owned computer or a VM you create.
Domain Users can be manually created by Domain Administrators. Your Yale Netid is automatically created by a program when you first appear in Yale systems.
Built in SID Permissions
The Microsoft TrustedInstaller identity owns subdirectories of C:\Windows that contain Windows components. Even administrators do not have permission to change these files. The system itself modifies these directories when you install monthly patches or perform an annual upgrade of the system.
SYSTEM (also called LocalSystem) is the built-in identity used by default to run ordinary background services. When you add features and products to the computer, additional versions of the “system” user can be created for components such as SQL Server or Hyper-V. SYSTEM is a member of the Administrators group, has read/write access to all files on local disk not owned by TrustedInstaller, but has access on the network only to files that have been granted anonymous access (where Everyone can read them).
As a result:
SQL Server can only backup and restore databases to files on a local disk.
Hyper-V can only start a VM if all its VM VHDX disk files and ISO DVD image files are on local disk, and it can only export/import a VM to local directories.
Utilities like SSMS for SQL Server and Hyper-V Manager run under your userid and have access to your files. Sometimes they will let you browse to a directory that is on a network disk to which you have access. However, when you try to run the Backup or start the VM, an error will be reported because the actual SQL Server database or Hyper-V supervisor cannot access the files that you can access.
In practice, you may have to move database backup or ISO image files from the network server to local disk before the operation, or you may want to move the generated backup or export data off local disk when you are done.
Local User SIDs (in VMs or on Personally Owned Machines)
Yale Security Policy prohibits the use of Local User accounts in the native Windows system of Yale Managed Workstations. However, you are allowed to install Hyper-V and create a separate Windows VM. Since such a VM cannot join the YALE Domain, you must use only Local User accounts in the VM.
However, if you create a VM that runs under Hyper-V and install the Windows system yourself, that VM is not a member of the YALE Domain and will typically have to use Local User accounts. You will also have Local User accounts on personally owned machines in your home network.
A Local User is an account you create when you are acting as an administrator of your Windows 11 or Windows Server VM. You assign a name and a password to the account and then add it to local groups. A local user can login to the VM, own files, and can be given various permissions.
The SID for a Local User account is unique to the one machine where it was created and is meaningless on other machines. At least that is the way it is supposed to be. However, if you clone the system disk and install the copy in a different computer, or if you clone a VM and now run the two VMs side by side, then both copies of the original system will have the same machine SID and the same set of Local Users and Groups that existed at the time you did the cloning. After that, new Users and Groups created in the two clones will be different, but the same binary SID value may be assigned to potentially different User accounts on the two systems. Generally, you either clone two machines that you will continue to intelligently control, or you make sure that they are completely separated and will never generate confusion.
If a non-system disk formatted in NTFS is moved from one computer to another, file ownership and permissions assigned to Local Users on other machines will be meaningless to a different system. Instead of displaying a friendly Username, they will display as the long numeric SID value.
The YALE Domain, Netids, and Managed Workstations
Every person at Yale is given a Netid. The Netid is also the unique username of a Domain User object in the YALE Domain.
Yale Faculty and appropriate Staff members are assigned one personal Yale Managed Workstation. When you get it, it will have been joined to the YALE Domain and your Netid can login to it.
The Windows system that was preinstalled and starts up when you power on the machine is the “native” or “host” operating system. Yale policy applies to it. That system will be locked down by Yale policy to prevent access from other machines in the network.
However, modern Microsoft system design encourages you to put you work files on your OneDrive, and to define the same Office 365 account on all your computers. So, locking down the host operating system on the laptop may not really secure information.
Modern Microsoft systems include features based on Virtual Machine technology. Windows Subsystem for Linux creates a VM which is also used by Docker Containers. Microsoft ensures that data is isolated and can only be accessed by the logged-on user.
However, once Windows requires support for VMs, it makes sense to use that feature. VMs that you create running inside your Yale laptop are completely separate from the host Windows operating system. They appear as entirely separate machine connected on a network, and are indistinguishable from personally owned computers on your home network.
The more technically trained a user is, the more likely that they will use VMs. In particular, anyone developing and testing computer programs will want to create an environment where the program can in isolation, safely separated from the real Yale network. To do this, they create VMs running SQL Server with test versions of databases. An application that modifies Users and Groups in the YALE AD may need a VM with an internal isolated dummy AD to do unit testing.
A group of VMs that simulates a real system and can be used to safely test software is sometimes called the Developer’s Sandbox.
So a software developer will have a Yale laptop that is a member of the YALE Domain, has no local users, and will not share files with non-Yale computers. Internally it can have VMs that are not members of the Domain, have only local users, and can share their own files to the laptop OS, but cannot access directories on the laptop. The developer can use Remote Desktop to login to the VMs. If the VMs are connected to the physical LAN they can appear as additional personally owned computers on the home network.
A developer who needs to create an Active Directory Domain in the Sandbox further complicates things, because now in addition to Local User accounts there will be Domain accounts belonging to a different Domain (which we will name SANDBOX). Now there are three different types of accounts YALE, Local, and SANDBOX, that are specifically designed not to talk to each other.
Workgroup (Local User) Authentication
When you start up a personally owned computer, you give it a name and define your own account. You end up with a “standalone” Windows system that is not a member of any Domain.
When you then bring into your house your new Yale Managed Workstation, it is a member of the Yale Domain and only has Domain accounts.
You can associate the same OneDrive account on each computer. This causes a separate copy of the shared files to be stored on each real or virtual machine. Your OneDrive account can hold a Terabyte of space, but that is a lot of data to duplicate and a lot of network activity to upload and download.
Before there was Office 365 and even before there was Active Directory, Microsoft allowed files to be shared directly between two computers connected to the same network without a common Domain. This type of communication is called a Workgroup, and it has been supported since Windows NT 3.1 in 1994. Today Microsoft would like to sell you an Office 365 account, but they still support Workgroups even if they don’t encourage them.
Workgroups are based on Local Users and Groups. This means that the native operating system on your Yale laptop cannot be a member of a Workgroup, but it can access files shared by computers in the Workgroup if when you select the option to “Map network drive”, you click the checkbox for “Connect with different credentials” and in the popup enter the username and password for the Local User in the Workgroup.
As you start to add VMs, all the physical or virtual Windows computers on your network except for the Yale laptop can combine to form the Workgroup. Sharing is possible by default when you create a Local User account on each member of the Workgroup with the same username and password.
On each computer, each Local User is internally assigned a different SID. Files created by that user are owned by that machine specific SID, and permissions are granted to that SID. If you have a SQL Server on that system, then Windows Logins are really associated with the local SID.
Although the SIDs are different on each machine and on disks attached to each machine, over the network the Workgroup protocols verify when the same username exists on two systems and has the same password on both systems. Then even though the SID is different on each computer in the Workgroup, access to files, services, and databases from a program run under the username on one computer are translated during the network communication between the two computers so that the operations on the other computer run under the SID assigned to Local account with the matching username.
Domains provide better security, which is why they are used by companies and universities. Workgroups are acceptable when they are physically isolated from the outside world. VMs running inside your laptop are isolated. Computers on your home network are isolated (provided that you do not share your WiFi with someone else).
From 1994 to Windows 11 24H2, Workgroup authentication was done with a Microsoft protocols named some version of “NTLM”. Starting sometime after the introduction of 24H2, a new protocol based on Kerberos called LocalKDC will be phased in, and NTLM will slowly be phased out. This will happen under the covers and will be transparent to Windows users, although it may be more visible to people running obsolete versions of Windows on some personally owned computers, or Linux computers that will require an upgrade of their support for Windows shared files.
Workgroup Authentication is also used for commands that can be issued on one computer but which run on another computer. Some Windows management tools can display activity running on several machines of the same Workgroup. Some commands can display data from another machine. Blocks of PowerShell code can be directed to run on another Workgroup computer.
However, the Yale Managed Workstation native Windows OS is a member of the YALE Domain and not a member of the Workgroup, so it cannot participate in all this automatic cross-computer sharing.
Your Own Domain
Workgroups provide all the convenience you need. Nobody will benefit from creating the own Domain in their own home. So only software developers testing application programs that modify AD may want to create a dummy domain that they can safely use to test modifications to their programs.
You can only create an AD on a computer or VM running Windows Server. The Yale site license allows us to run Server on VMs, and anyone can download evaluation or test versions of Server from Microsoft. It is almost the same as Windows 11. Install it from an ISO image or download a VHDX file with it preinstalled.
An AD can be created on a Windows Server VM in about 10 minutes by typing in two PowerShell commands and rebooting after each command.
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).
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.
Now when you create the AD the Workgroup administrators are promoted to Domain Admins in the AD. However, they retain their old Local User SID (presumably in the SID History field mentioned previously). As a result, the Windows Server VM behaves both as a Domain and a member of the Workgroup.
You can continue to use Workgroup protocol to access files and administrative services on the new Domain Controller. From another Workgroup computer logged in as a Local User who is a Workgroup administrator, you can issue PowerShell commands referencing the Sandbox VM by its hostname (Set-ADuser -server hostname.local ….) and the command executes with Domain Admin privileges even though the command was entered by a Workgroup account on a computer that is not a member of the Domain by a user who did not authenticate using Kerberos.
When you create an AD on a Windows Server, you also have to add the DNS Server Role to the computer. It starts up a DNS Server that initially only knows the DNS name of the Domain and new DNS name added to the VM on which the AD was created. You can ignore this DNS and continue to use whatever DNS server you were previously using on all your computers and VMs. However, if you want to do testing where another VM joins the test Domain, then before joining it, you should change the network configuration of the new VM so it’s configured DNS Server IP address points to the Windows Server containing the AD.
Impersonate
Programs running as SYSTEM (also called LocalSystem) have permission to launch new programs under an arbitrary SID that they choose from the local account database.
Any program that knows a username and password of another account can pass that to an internal “re-Login” service and run a program under that account, but services running as SYSTEM do not need to know the password. A system component just changing the SID like this is called “impersonation”.
Changing the current SID provides access to files and services on the current computer, but it did not create a password that can be used for Workgroup Authentication, nor did it obtain a Kerberos “TGT” object needed to do Domain Authentication. Therefore, the program has no access to files or services on any other computer on the Local LAN. Even if the SID is a Domain SID that came from the AD, that Domain SID only provides access to files and services permitted to that Domain user on the local computer. To access anything on other computers in the Domain, you need to use Kerberos and you cannot do that without a TGT object.
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 impersonation.
On Windows Server 2025 OpenSSH server will be pre-installed but will have to be started manually or reconfigured to start automatically.
The 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, they wanted an extra level of permission to do this. 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 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 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.