In all computer systems, there is some system that stores Accounts defining users and services in that machine and sometimes computer on the network. Each account is given a unique numeric or binary identifier that does not change. This binary identifier is stored in the file system as the owner of files and directories, and it can be assigned permissions to access files or request services.
Accounts can represent a single User or a Group of users.
Each account has a friendly name that is displayed on the screen to people. We generally use this friendly userid, username, or Netid when we talk about the account, but under the covers it is the binary ID we do not see that is really used by the OS.
In Windows, this binary ID is called the SID (Security ID).
All users have a SID. All programs run under a SID. All files and directories are owned by a SID. Permissions are granted to a SID.
The friendly name of an account can be changed. Since everything in the system was connected to the SID and not the name, renaming a user account has no important consequences.
In Windows, every computer is assigned a SID when it is installed or first starts up. The SID has at least 12 bytes that are randomly generated, so the SID of a computer is unique. Generally users and groups defined locally on the computer have a SID that contains the SID of the computer and then an additional unique number designating a specific user or group inside that machine.
Every Windows Domain has a SID generated when the Domain is created. Again, the users, groups, and computer accounts in the Domain contain the Domain SID and then a unique additional number designating the specific object managed by that Domain.
There are several types of Windows SIDs:
Microsoft has created some SID for itself when it does things like install maintenance on the machine.
There are predefined Local Groups that contain the machine SID and then a predefined reserved individual unique object number. Administrators is an example of this.
Ordinary Local Users and Groups are created by you as administrator of the machine.
If a Windows system is a member of a Domain, then it has access through the network to all the Users and Groups defined in the Domain. Domain Users and Groups can be added to a Local Group defined on the one machine, Domain Users can login to the machine, they can own files and directories they create, and they can have permissions granted to them.
Factory Installed SIDs
The Microsoft TrustedInstaller identity is built into Windows and has permission to update the most sensitive files in the operating system. It installs the monthly maintenance and optional components of Windows. Key operating system files and directories can only be changed by applying digitally signed updates.
SYSTEM (also called LocalSystem) is an anonymous identity for most of the programs that run as background Services. There are some special versions of SYSTEM for SQL Server and Hyper-V. SYSTEM identities have administrator access to all files on local disks, but only Anonymous access to network files. In practice, they cannot access files on other machines at all.
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 System of Yale Managed Workstations. 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 of the clone. After that, new Users and Groups created in the two clones will be different, but the same Local User SID may be assigned to new Users with different names who are potentially different people. This would be a problem when machines are used by different people. It is not a problem when you are the only person who creates and uses the VMs.
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 User name, they will display as the long numeric SID value.
When you login to a computer, it runs all programs in your session under your SID.
The YALE Domain, Netids, and Managed Workstations
Every person at Yale is given a Netid. The Netid is also the friendly name 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 be used to login to it.
Yale policy prohibits using Local Users in the Windows system of your Yale owned computer. However, various forms of Hyper-V virtual machines are required to use certain Windows services (WSL Linux, containers, Windows Sandbox, and various hidden security components).
WSL Linux distributions, containers, and VMs that you create inside your computer are not visible to other computers on the network. Even if you run a Windows in a VM, there are various reasons why it probably should not be a member of the YALE Domain.
A special case is anyone developing and testing applications that will be deployed after testing in production. A developer needs to test on dummy data that is completely isolated from the real Yale systems so that any errors cannot damage the real data. This means that VMs may contain SQL Server databases with the same schema as the real Yale databases, but with dummy data. An application that modifies Users and Groups in the YALE AD may need a VM with a local dummy AD to do unit testing.
A group of VMs that internally and in isolation duplicate components of the real Yale system is called a Sandbox. You can play in it. Sometimes it is called the “Padded Cell” because it is a place where stuff can run without doing any harm to yourself or anyone else.
However, when you combine the constraints placed on the main Windows system of a Yale Managed Workstation with the need to create VMs that have only Local Users or even some that have their own isolated AD Domain, then you have to carefully navigate through the problem caused by mismatched systems of accounts.
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.
It may be a stereotype, but the Yale Managed Workstation is typically a laptop, and the personally owned machine is frequently a “gaming rig” with a more powerful CPU and a much more powerful video card.
The current Microsoft strategy is to convince you to configure your Microsoft Office 365 account on both machines and put your files in OneDrive. Implicitly your files are automatically backed up and files you create on one machine will be shared with the other machine and can be loaded on demand.
Of course, this may mean that in order for a file to move between two computers that sit next to each other in your living room, Microsoft will first upload a copy of the file through the Internet to some system in Virginia, then download the same file back through the Internet to the other computer. This is fine for students, faculty, managers, and office workers who are writing homework, research papers, or business reports. It is not an option for software developers who need an application on one machine to query a database on the other machine.
With Hyper-V, you can have the same situation between the native “host” operating system on the laptop computer and a Virtual Machine running under Hyper-V inside the laptop (under, but independent from the host Windows system).
Before there was an Office 365 or OneDrive, two computers connected to the same LAN would exchange data directly computer to computer. Starting around 1994, Microsoft called this a “Workgroup”. Workgroups are still supported in Windows today, but Microsoft tries to convince casual users to do use their cloud instead.
Workgroups use Local Users. A Yale Managed Workstation does not have Local Users, while your personally owned machine is not on any domain and only has Local Users.
A consequence of Yale Security Policy is that the Yale Managed Workstation laptop cannot share its directories and files with the personally owned machine, but the personally owned machine can share its directories with the Yale laptop. When the laptop as a client selects the option to “Map network drive” click the checkbox for “Connect with different credentials” and in the popup enter the Local User name and password for the account on the other computer. Yale security policy does not allow this mechanism to work in the other direction.
As you start to add VMs, all the physical or virtual Windows computers on your network except for the Yale laptop can form a Workgroup. All you need to do is define a Local User with the same userid and password on more than one (and I suggest on all) the other computers and VMs.
On each computer, each Local User is internally assigned a different SID. Files created by that user are owned by the SID, and permissions granted to that user are granted to the SID. If you have a SQL Server, then Windows Logins for that user 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 userid exists on two systems and when it has the same password on both systems, then even though the SIDs are different, the network session between the two machines is bound to the local SID of that userid on both machines. Requests coming over the network from one machine are essentially remapped to execute under the SID of the matching User on the other machine.
So in simple terms, a Workgroup is a set of computers or VMs connected to each other on a common LAN where someone has taken the time to define matching one or more Local Users on each system with the same username and password on each system. That user on any Workgroup machine can access the same files, request the same services, run system utilities, and access the same SQL Server databases through the network across all the machines.
From 1994 to 2024 (specifically 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 computers, or Linux computers that access Windows shared directories where the protocol support will have to be updated.
Workgroup Authentication is also used for commands that can be issued on one computer but which run on another computer. Hyper-V Manager allows you on one Workgroup machine to display and manage VMs running on more than one physical machine. A client program running on one Workgroup machine can access a SQL Server on another Workgroup machine using Windows authentication if the Local userid is the same on both the client and server machines.
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.
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 without providing explicit alternate credentials, then BOOJUM defaults to Workgroup Authentication and verifies that it has a local user also named “bellman” and that the password for “bellman” is the same on both BOOJUM and SNARK. It then assigns the SID of BOOJUM\bellman to the network session.
This works for access to files and directories owned by or permitted to BOOJUM\bellman. It also works for SQL Server sessions using Windows authentication, which are then associated with the SQL Server login identified as BOOJUM\bellman (even though the remote client is really SNARK\bellman). It also works for Windows admin command that can be directed over the network to another computer.
There is, however, no way to generate a permission on a network session for a specific user on a remote computer. The user SNARK\baker could not connect to BOOJUM at all unless there is a BOOJUM\baker with the same password, and SQL Server can only generate Logins for Local Users (and Domain Users if the machine is also a member of a Domain).
Active Directory Domain User SIDs
An Active Directory is a central network service that creates SIDs for user accounts, and Domain SIDs can be shared with all the computers that are members of the Domain. Any user logging onto a machine with a Domain account gets the SID from the Domain. When that user moves to another computer in the same Domain and logs in, he gets the same SID on that machine too.
If you are logged into a computer with a Domain account, and you create a file on a USB drive formatted with NTFS, and you then move that drive to another computer in the same Domain, that computer recognizes the SID on the file and displays your Domain userid as the owner instead of the SID number.
So, if “bellman” is a Yale Netid, and SNARK and BOOJUM are Yale machines, then there would be only one userid named YALE\bellman, it would be the same on both machines, it would have the same SID on both machines, and disks could be freely moved from one machine to the other.
While it is against Yale policy to do this on a Yale owned machine, Windows allows a computer in a Domain to have both Domain Users and Local Users. In this case, when a user is logged in with his Domain account, then the machine uses Kerberos authentication to access files and services on other computers in the same Domain. Logoff and log back in as a Local User account, and now the computer uses Workgroup Authentication to access files and services on other computers connected to the same LAN.
A Local User account can have the same userid as a Domain account. The Domain account is referred to by the fully qualified name of domainname\userid. In the YALE Domain, YALE\bellman is a Domain account, and it is entirely different and completely unrelated to the Local Users BOOJUM\bellman and SNARK\bellman. They have different home directories, own different files, and have different permissions (because they have different SIDs).
Every Yale Managed Workstation is a member of the YALE Domain. Other computers and VMs can be added to the YALE Domain, though it is best if you administer a departmental OU and can create a “new computer” object with that hostname in that OU before you join them to the Domain. When you have two systems in the Yale OU, you can use and test most Domain identity features.
Your Own Domain
You can only create an AD on a computer or VM running Windows Server. It takes about 10 minutes to install the VM from an ISO image file (or you can download a VHDX file where it is already installed). You can then install your own AD with two PowerShell commands. Unless you really want to learn about ADs, or you need to test a program that manages them, having your own AD is probably more trouble than it is worth.
Yale’s site license allows us to run as many copies of Windows Server as we want, so there is no cost to installing it in a VM. It is not an attractive choice as the primary system on the first two or three personal computers that you own because it lacks a few consumer-oriented features. Windows Server 2025 will be better, but traditionally Server expected to run unattended in a machine room and lacked good WiFi, audio, webcam, and drivers for some devices. Don’t plan on using it for Zoom meetings.
Windows Server 2022 looks like Windows 10. Server 2025 looks like Windows 11 and can, for the most part, be configured and managed the same way that you manage a desktop.
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).
A Domain needs a DNS name and a nickname. We will call this one yu.yale.sandbox with nickname HUNTING.
When the DNS Server Role was added, Windows tells it to forward all requests it cannot resolve internally to the same external DNS server that
That is because when you create the AD, they also become Domain Admins. This initial group of admins becomes especially useful because they are both Local Users and Domain Users at the same time. This will allow you to use either Workgroup Authentication or Domain Authentication to connect to this Server and access files or services (including AD Admin services). We create a user named “bellman”, or to be precise “FIT\bellman”.
For testing and software development, it is only necessary for this test Domain to have one computer (FIT) which is its Domain Controller and, because it is required, is also a DNS Server.
There are two PowerShell commands to install the Active Directory support and to create the new Domain. You may have to reboot between the two commands. The AD needs a full DNS name and a nickname. For this example, we make the nickname HUNTING.
The DNS name will only be known to the DNS server that you created while the second PowerShell command generated the Domain. You are free to define this name in other computers. The HUNTING nickname is, at this point, only known on the Server itself.
Fortunately, FIT is still a computer on your network, and you can reference it from other machines using standard tricks like typing in “\\fit.local”. Remember that part about how you can use either Workgroup or Domain authentication to talk to a machine in your network and authenticate as a Local/Domain user like “bellman”.
Here is the Big Idea. The Local User FIT\bellman is the same SID and therefore the same account as the Domain user HUNTING\bellman. Generally speaking, anywhere you could enter the DNS name of a Domain, you can instead enter the name of a Server that is a Domain Controller of the Domain. For example, in any AD PowerShell command, the -Server parameter can specify the Domain Name, but it can also be
get-ADxxxx -Server fit.local
Even though “fit.local” is the name of a computer and not the name of a Domain, it doesn’t matter inside your personal development network. The computer name designates a Domain controller, so AD stuff goes to the Domain even though it wasn’t explicitly named in the command.
At Yale, the Domain Controllers are secured and nobody can login to them except AD administrators. However, when you create an AD in your own VM, you are in full control. Of course, nothing you put in it will control any other machines. You can use it to understand and test various forms of authentication or learn more about AD in your personal Sandbox LAN.
Impersonate
All programs run under a SID. Some programs run in the background under Microsoft built in SIDs like SYSTEM. Ordinary users login with a userid and password, get a session with their corresponding SID, and then all the programs they run in that session use that SID.
Anyone can run a new program under a different userid and SID by triggering an internal Re-Login where they provide or prompt for a new userid and password. This is called “RunAs”.
Components that are part of the Windows System are authorized to temporarily change their SID to any other SID that they can find by searching for the Users on the computer.
When a System Program simply changes the SID to some other SID, this is called “impersonation”.
Impersonation affects the permissions the program has to access Local files or call Local services. It works only on the local computer.
Changing the current SID 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, so there is 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, you still need the Kerberos TGT to communicate with any other Domain computers on the network.
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.