A Windows user account can be renamed. You almost certainly never want to do it, and changing your Yale Netids is almost impossible because of all the systems that use it, but Windows does allow it. What doesn’t change is a unique binary identifier created when the account was defined: the Security ID or SID. When you login, Windows identifies you through your SID. Access to files and directories are through the SID. Each group you are a member of also has its own SID.
There are three sources for SIDs:
Microsoft generates some built in “factory installed” SIDs for standard Windows components, and many of these built in accounts also have a dummy User name.
As an administrator, you create Local User accounts on your own machine. The SID for a Local User is unique and exists only on the one computer, even if you create an account with the same User name on another computer.
Microsoft’s Active Directory creates SIDs that can be shared across machines. All computers that are members of the same AD, including all the Managed Workstations at Yale, share the SIDs in the yu.yale.edu domain also known by the nickname YALE. This is where your Netid and its password are saved.
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. You do not have and do not want to have direct access to it.
SYSTEM 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 can access any file on a local hard disk but this SID is meaningless to other computers, so programs that run under this SID have no access to anything on another computer. There are two practical consequences of this:
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 a local disk, and it can only export/import a VM to local directories.
In some cases, the utility that you are running under your userid may have access to a file through your logon that the background service cannot access. You may be able to build a SQL Server backup request or configure a VM through the Hyper-V manager, but when you try to run the backup or start the VM, that will fail. Typically, an administrator learns to copy files to local disk before an operation and then move or copy files to a network disk when they are no longer needed.
Local User SIDs created by You
Yale Security Policy expects users to login with their Yale Netid to Yale Managed Workstations and other computers that are Yale owned and on the Yale network. This section describes the security procedures for Hyper-V VMs that run inside your laptop or personally owned computers on a 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 machine, 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. You can see this by logging in as a non-admin Local User, creating a file on an NTFS formatted thumb drive, and then move the drive to another computer. The other computer has no idea who owns or created the file because the Local SID generated by that computer is meaningless to other machines.
When you login to a computer, it runs everything in your session under your SID.
Workgroup (Local User) Authentication
Yale owned machines running Windows must be members of the YALE AD Domain. Yale Policy requires you to use your Netid Domain account to login to such machines.
Personally owned machines or VMs are typically not a member of the YALE Domain or any other AD. Microsoft created AD in 2000, so from around 1994 to 2000 Windows machines shared files with another protocol named “Workgroups” (from the “Windows for Workgroups 3.11” product release of 1994).
Any Windows 10/11 or Windows Server can create Local Users and Local Groups. Local Users are assigned a userid and password by an administrator of the machine. Someone knowing the password can login to that machine as that user.
When you have more than one computer (in a home, department, lab, or small company) then the same userid and password can be defined as a Local User on more than one computer.
On each computer, each Local User is assigned a large generated binary ID number called the “SID”. Local User objects on different machines have different SID values on each machine. Although you may think of yourself by your “userid” and that name will show up in every tool and command that presents information about files and programs to a person, in reality it is the SID and not the userid that is stored in memory or written to disk as the owner of a file or someone permitted to use the file.
Since the SID of user “johndoe” is different on each machine, if you mount a USB disk formatted with NTFS and create a file as user johndoe on one machine, then eject the disk and move it to another machine, the owner of the file will not be displayed as “johndoe” but rather as some very long number that is the SID generated on the other machine. No Windows system recognizes the SID of a Local User from another Windows system.
However, if two Windows computers are on the same network, and the same userid with the same password is defined on both machines, then “johndoe” on one computer can transparently through the network access files owned by or permitted to “johndoe” on the other computer. The trick here is Workgroup Authentication. If the two machines have Local Users with the same userid and same password on both machines, then when the machines talk to each other over the network they correlate the two Local Users accounts and “map” the SID on the client machine to the corresponding SID for the same userid on the server machine.
Until Windows 11 24H2 this authentication was done with a Microsoft protocol named “NTLMv2”. Starting sometime after the introduction of 24H2, a new protocol based on Kerberos called LocalKDC will be phased in and NTLM will be phased out. This will happen under the covers and will be transparent to Windows users, although it may be more visible to Linux users who access Windows file shares, where the same support will have to be added.
Although Workgroup Authentication is normally used for sharing files over the network, it also applies to commands and utilities that control, configure, administer, or query information between two Windows computers.
Since Yale policy prohibits creation of Local User accounts on Yale Managed Workstations, you may have to access files on Workgroup machines by interactively presenting the userid and password as alternate credentials in the dialog boxes or commands used to access the Workgroup Machine. If you install OpenSSH Server and add your public key to the authorized_keys file in the .ssh subdirectory of your home directory, then on a Workgroup computer from an account with your matching private key you can SSH to yale\netid@mwhostname and enter commands or scp files. You can also execute PowerShell command using PowerShell remoting with “-hostname mwhostname -username yale\netid”.
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 netnameIn 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 (the UID) with lower numbers for system services, and numbers starting at 1000 for Users. Since Windows NT in 1994, each Windows machine has its own account database called the SAM, and each account has a much larger binary string called the Security ID or SID.
Unix has a separate set of numbers for groups, and Windows also assigns SIDs to groups. By default a file is owned by the User who creates it, unless that user is in the Administrators group. When an administrator creates a file, ownership defaults to the group. This is a special rule that applies only to Administrators.
Just as Linux stores the UID of the owner in directories and files, Windows stores the SID of the owner of directories and files of an NTFS file system. It also grants access permissions to SIDs. When displaying any system information that contains a SID, Windows typically replaces it with the username or groupname of the account associated with the SID.
During the 1990’s, a Windows NT Domain was simply one NT computer on the network that essentially “shared” its SAM with other computers that were members of the Domain. In Windows 2000, Microsoft created a more flexible, reliable, and secure type of Domain called Active Directory, but it kept the SAM account in individual Windows machines that were not members of a Domain and included the same SID structure in AD.
Every Windows 11 desktop system still has its own SAM. While Yale policy prohibits creating Local Users on a Yale Managed Workstation, inside the system Microsoft has already created Built-In Local Users such as “LocalSystem” (a.k.a. SYSTEM), Administrator, and Guest, and the SAM also defines the Local Groups even when all the members of the Group are Domain accounts.
A given computer can only be a member of one Domain, so by default it will only have SIDs from its SAM and the one Domain to which it is joined, but disks can move around from machine to machine. If you format a USB drive with NTFS instead of one of the FAT filesystems, then it can pick up directories and files with ownership and permissions that include SIDs from the SAM of other computers or even other Domains. When Windows encounters a SID that is not Local or from the Domain this computer is currently joined to, it cannot display a user or group name and will either ignore it or display the SID as a string of numbers.
A large corporation or university system with multiple campuses may have an AD with more than one Domain. If a User is moved from one Domain to another, it gets a new SID from the new Domain. The previous SID is stored in a history list and may still be used to grant access permissions.
AD uses Kerberos, which regards each computer as a type of User. When a computer joins a Domain, it gets a computer account record and a SID. Every time the computer starts up, it logs into the Domain like any other User.
A User who logs in with Kerberos gets a token called the “TGT”. Windows stores this token in a secure part of the OS and uses it to gain access to files and services on other computers. The SID stored by the Windows system on this computer is sufficient to prove the user’s identity to services running on the same system, but the SID itself is public information and therefore by itself proves nothing to other computers.
When you start up a brand-new copy of Windows, it generates a mostly random 12-byte binary string that is unique to this computer. That string becomes part of every SID generated by this computer. When a new AD Domain is created, a similar unique 12-byte string is generated and becomes part of the SIDs that belong to that Domain. Individual User, Group, or Computer accounts are then just represented by an administratively managed sequence of numbers managed by the computer or the Domain.
When you enter a User or Group name and when Windows displays the User or Group name corresponding to a SID it finds in a file or permission, the convention is to prefix the name of the individual object with the Hostname of the computer for Local Users and Groups from the SAM of that computer, or else the nickname of the Domain for AD accounts. Thus YALE\netid is your User object in the Yale Domain, YALE\IAMDEV is the “iamdev” group in the Yale AD, while on a computer named CORNMUFFIN there could be a User named CORNMUFFIN\FRED and a Local Group named CORNMUFFIN\DEVELOPERS.
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. So before or after one of these operations, you may have to move database backup or virtual disk files between local disk and network disk.
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. You will also have Local User accounts on personally owned machines in your home network.
When a new Windows VM starts up, you may be prompted for a password for the “administrator” account and a username and password for the first Local User. After that, you create additional Local Users as an administrator of the machine.
It is possible that you will have a personally owned home computer with several users who are family members who share the machine. If you are a developer creating a test environment, then you will typically define just your own username and perhaps a handful of test case users.
When you have a group of VMs running different parts of your development environment, it is important to define the same username and password for yourself and any other administrator accounts you choose to use. As will be explained below, this allows you to share files and issue commands from one VM to another in what is called a Workgroup.
Local SIDs are meaningful only on one computer. If you move a disk from one computer to another, Local SIDs from other machines display as unknown numbers.
However, you can subvert this if you have a utility to clone (make a complete copy) of a physical disk or if you copy virtual disk files or even entire VMs. In this case you may have more than one computer or VM running a copy of the same SAM with the same SIDs, and then if a USB disk is moved from one system to a clone of the same system, it may match the SID to a User object in its SAM and display the Local username for that SID.
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 Test AD in a VM
Workgroups provide all the services you need. Nobody will get a benefit from creating an AD in their home that outweighs the headaches of learning how to administer it.
However, this assumes that you are really using an AD to control machines, users, services, and to enforce policy.
You can download an ISO image of Windows Server and use it to create a new VM. It behaves almost the same as desktop Windows. Then two PowerShell commands and two reboots create an AD on that VM. Only that one VM is a member of the AD, or even knows it exists.
You can then create any number of Users, Groups, OUs, or any other data structures you need to use to test applications. The dummy Users you create could have the same names as real people, or you can make names up. Even if you create a User object that contains the same information as your YALE Netid account, it controls no machines, owns no resources, and has no real permissions. You don’t need to control any other computers or set any policy with this AD. Its only use is to test applications that read, modify, or create information in an AD, but to test changes in a safe environment where mistakes do not affect real users or even other developers.
The instructions for adding AD to a Windows Server VM are covered in detail in /wiki/spaces/IAM/pages/51607680.
Up to this point, we were dealing with YALE Domain users and groups that were used only by the native Windows system of the Yale owned laptop, and Local users and groups defined on VMs created with Hyper-V in the laptop and perhaps also on personally owned computers. When the same Local username and password is defined on each machine, they form a Workgroup where you can share files and issue administrative commands across systems.
A test Domain creates a third set of identities. Windows systems in one Domain cannot interoperate with Windows systems in a different Domain, and with real Domains (like YALE) identities in a Workgroup cannot interoperate with computers in the Domain.
However, the article referenced above explains that if before you create the AD on the Windows Server VM you first add all the usual usernames and passwords that you have been defining on all the other Windows VMs in the Workgroup, then this group of Local Users (who are members of the Administrators group) are given special treatment when the Domain is created. The resulting VM has an AD Domain, but it also continues to behave as if it were a member of the Workgroup. You can use Workgroup authentication to access shared directories across systems. You can even use PowerShell commands on a Workgroup computer to Get, Set, or Add ADUsers and ADGroups in the test domain even though the computer on which the PowerShell script is running is not itself a member of that Domain and is running while you are logged on as a Local User instead of a Domain User.
You would never do this in a real Domain. Microsoft warns everyone that this creates a security exposure. However, you do not really need an AD to be secure if it is hidden away in a VM running on a virtual network inside your laptop that no other computer can get to, and the AD has no real users, no real passwords or other sensitive data, and it controls no real resources.
When you create an AD on a Windows Server, you also have to create a DNS Server on the VM. This server will resolve DNS names that end in the Domain name. For example, if you created a Domain named yu.yale.sandbox, then this DNS server will resolve all names ending in yu.yale.sandbox. However, none of the other VMs in the workgroup need to use this name. They can continue to reference the VM by any of its Workgroup names (typically hostname.local) and in any place where they have to configure the name of the AD (for example, in the -Server parameter of a PowerShell command) they can substitute a network name of the VM in place of the official name of the Domain. If testing requires that you add a Windows VM as a member of the Domain, then change the network configuration on that VM to use the IP address of the Domain Controller as the DNS Server IP address of the Windows system you want to join to the Domain before you perform the change to add it to the Domain.
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
SSH 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 will be pre-installed, but the service will still be stopped and has to be started.
The Windows version of the SSH client 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 run 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 C:\ProgramFiles\ssh\administrators_authorized_keys instead of the normal $HOME/.ssh/authorized_keys file.
PowerShell Remote using SSH
PowerShell has powerful command to administer all aspects of a computer. By default, it uses Windows Management Instrumentation (WMI) to communicate between machines. 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.