In all computer systems, there is some mechanism to define Accounts for users and services. It may be as simple as the Linux /etc/passwd file where each account has an integer (the UID) with lower numbers for system services, and users beginning numbers starting at 1000 and incremented by 1 for each new entryfor Users. Since Windows NT in 1994, each Windows machine has an its own 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.
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.
...
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 practiceSo before or after one of these operations, 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 donevirtual 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.
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 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.
...
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 convenience services you need. Nobody will get a benefit from creating the own Domain an AD 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 /wiki/spaces/IAM/pages/51607680.
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 ADthat 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.
...