In all computer systems, there is some system that stores Accounts defining mechanism to define Accounts for 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 . 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, so there is . 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, you still need the Kerberos TGT to communicate with any other Domain computers on the networkthat 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.
...