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”In all computer systems, there is some system that stores Accounts defining users and services in that machine and sometimes computer on the network. Each account is given a unique numeric or binary identifier that does not change. This binary identifier is stored in the file system as the owner of files and directories, and it can be assigned permissions to access files or request services.
Accounts can represent a single User or a Group of users.
Each account has a friendly name that is displayed on the screen to people. We generally use this friendly userid, username, or Netid when we talk about the account, but under the covers it is the binary ID we do not see that is really used by the OS.
In Windows, this binary ID is called the SID (Security ID).
All users have a SID. All programs run under a SID. All files and directories are owned by a SID. Permissions are granted to a SID.
The friendly name of an account can be changed. Since everything in the system was connected to the SID and not the name, renaming a user account has no important consequences.
In Windows, every computer is assigned a SID when it is installed or first starts up. The SID has at least 12 bytes that are randomly generated, so the SID of a computer is unique. Generally users and groups defined locally on the computer have a SID that contains the SID of the computer and then an additional unique number designating a specific user or group inside that machine.
Every Windows Domain has a SID generated when the Domain is created. Again, the users, groups, and computer accounts in the Domain contain the Domain SID and then a unique additional number designating the specific object managed by that Domain.
There are several types of Windows SIDs:
Microsoft has created some SID for itself when it does things like install maintenance on the machine.
There are predefined Local Groups that contain the machine SID and then a predefined reserved individual unique object number. Administrators is an example of this.
Ordinary Local Users and Groups are created by you as administrator of the machine.
If a Windows system is a member of a Domain, then it has access through the network to all the Users and Groups defined in the Domain. Domain Users and Groups can be added to a Local Group defined on the one machine, Domain Users can login to the machine, they can own files and directories they create, and they can have permissions granted to them.
Factory Installed SIDs
The Microsoft TrustedInstaller identity is built into Windows and has permission to update the most sensitive files in the operating system. It installs the monthly maintenance and optional components of Windows. Key operating system files and directories can only be changed by applying digitally signed updates.
SYSTEM (also called LocalSystem) is an anonymous identity for most of the programs that run as background Services. There are some special versions of SYSTEM for SQL Server and Hyper-V. SYSTEM identities have administrator access to all files on local disks, but only Anonymous access to network files. In practice, they cannot access files on other machines at all.
As a result:
SQL Server can only backup and restore databases to files on a local disk.
Hyper-V can only start a VM if all its VM VHDX disk files and ISO DVD image files are on local disk, and it can only export/import a VM to local directories.
Utilities like SSMS for SQL Server and Hyper-V Manager run under your userid and have access to your files. Sometimes they will let you browse to a directory that is on a network disk to which you have access. However, when you try to run the Backup or start the VM, an error will be reported because the actual SQL Server database or Hyper-V supervisor cannot access the files that you can access.
In practice, you may have to move database backup or ISO image files from the network server to local disk before the operation, or you may want to move the generated backup or export data off local disk when you are done.
Local User SIDs (in VMs or on Personally Owned Machines)
Yale Security Policy prohibits the use of Local User accounts in the native System of Yale Managed Workstations. However, if you create a VM that runs under Hyper-V and install the Windows system yourself, that VM is not a member of the YALE Domain and will typically have to use Local User accounts. You will also have Local User accounts on personally owned machines in your home network.
A Local User is an account you create when you are acting as an administrator of your Windows 11 or Windows Server VM. You assign a name and a password to the account and then add it to local groups. A local user can login to the VM, own files, and can be given various permissions.
The SID for a Local User account is unique to the one machine where it was created and is meaningless on other machines. At least that is the way it is supposed to be. However, if you clone the system disk and install the copy in a different computer, or if you clone a VM and now run the two VMs side by side, then both copies of the original system will have the same machine SID and the same set of Local Users and Groups that existed at the time of the clone. After that, new Users and Groups created in the two clones will be different, but the same Local User SID may be assigned to new Users with different names who are potentially different people. This would be a problem when machines are used by different people. It is not a problem when you are the only person who creates and uses the VMs.
If a non-system disk formatted in NTFS is moved from one computer to another, file ownership and permissions assigned to Local Users on other machines will be meaningless to a different system. Instead of displaying a friendly User name, they will display as the long numeric SID value.
When you login to a computer, it runs all programs in your session under your SID.
The YALE Domain, Netids, and Managed Workstations
Every person at Yale is given a Netid. The Netid is also the friendly name of a Domain User object in the YALE Domain.
Yale Faculty and appropriate Staff members are assigned one personal Yale Managed Workstation. When you get it, it will have been joined to the YALE Domain and your Netid can be used to login to it.
Yale policy prohibits using Local Users in the Windows system of your Yale owned computer. However, various forms of Hyper-V virtual machines are required to use certain Windows services (WSL Linux, containers, Windows Sandbox, and various hidden security components).
WSL Linux distributions, containers, and VMs that you create inside your computer are not visible to other computers on the network. Even if you run a Windows in a VM, there are various reasons why it probably should not be a member of the YALE Domain.
A special case is anyone developing and testing applications that will be deployed after testing in production. A developer needs to test on dummy data that is completely isolated from the real Yale systems so that any errors cannot damage the real data. This means that VMs may contain SQL Server databases with the same schema as the real Yale databases, but with dummy data. An application that modifies Users and Groups in the YALE AD may need a VM with a local dummy AD to do unit testing.
A group of VMs that internally and in isolation duplicate components of the real Yale system is called a Sandbox. You can play in it. Sometimes it is called the “Padded Cell” because it is a place where stuff can run without doing any harm to yourself or anyone else.
However, when you combine the constraints placed on the main Windows system of a Yale Managed Workstation with the need to create VMs that have only Local Users or even some that have their own isolated AD Domain, then you have to carefully navigate through the problem caused by mismatched systems of accounts.
Workgroup (Local User) Authentication
When you start up a personally owned computer, you give it a name and define your own account. You end up with a “standalone” Windows system that is not a member of any Domain.
When you then bring into your house your new Yale Managed Workstation, it is a member of the Yale Domain and only has Domain accounts.
It may be a stereotype, but the Yale Managed Workstation is typically a laptop, and the personally owned machine is frequently a “gaming rig” with a more powerful CPU and a much more powerful video card.
The current Microsoft strategy is to convince you to configure your Microsoft Office 365 account on both machines and put your files in OneDrive. Implicitly your files are automatically backed up and files you create on one machine will be shared with the other machine and can be loaded on demand.
Of course, this may mean that in order for a file to move between two computers that sit next to each other in your living room, Microsoft will first upload a copy of the file through the Internet to some system in Virginia, then download the same file back through the Internet to the other computer. This is fine for students, faculty, managers, and office workers who are writing homework, research papers, or business reports. It is not an option for software developers who need an application on one machine to query a database on the other machine.
With Hyper-V, you can have the same situation between the native “host” operating system on the laptop computer and a Virtual Machine running under Hyper-V inside the laptop (under, but independent from the host Windows system).
Before there was an Office 365 or OneDrive, two computers connected to the same LAN would exchange data directly computer to computer. Starting around 1994, Microsoft called this a “Workgroup”. Workgroups are still supported in Windows today, but Microsoft tries to convince casual users to do use their cloud instead.
Workgroups use Local Users. A Yale Managed Workstation does not have Local Users, while your personally owned machine is not on any domain and only has Local Users.
A consequence of Yale Security Policy is that the Yale Managed Workstation laptop cannot share its directories and files with the personally owned machine, but the personally owned machine can share its directories with the Yale laptop. When the laptop as a client selects the option to “Map network drive” click the checkbox for “Connect with different credentials” and in the popup enter the Local User name and password for the account on the other computer. Yale security policy does not allow this mechanism to work in the other direction.
As you start to add VMs, all the physical or virtual Windows computers on your network except for the Yale laptop can form a Workgroup. All you need to do is define a Local User with the same userid and password on more than one (and I suggest on all) the other computers and VMs.
On each computer, each Local User is internally assigned a different SID. Files created by that user are owned by the SID, and permissions granted to that user are granted to the SID. If you have a SQL Server, then Windows Logins for that user are really associated with the local SID.
Although the SIDs are different on each machine and on disks attached to each machine, over the network the Workgroup protocols verify when the same userid exists on two systems and when it has the same password on both systems, then even though the SIDs are different, the network session between the two machines is bound to the local SID of that userid on both machines. Requests coming over the network from one machine are essentially remapped to execute under the SID of the matching User on the other machine.
So in simple terms, a Workgroup is a set of computers or VMs connected to each other on a common LAN where someone has taken the time to define matching one or more Local Users on each system with the same username and password on each system. That user on any Workgroup machine can access the same files, request the same services, run system utilities, and access the same SQL Server databases through the network across all the machines.
From 1994 to 2024 (specifically Windows 11 24H2) Workgroup authentication was done with a Microsoft protocols named some version of “NTLM”. Starting sometime after the introduction of 24H2, a new protocol based on Kerberos called LocalKDC will be phased in, and NTLM will slowly be phased out. This will happen under the covers and will be transparent to Windows users, although it may be more visible to people running obsolete versions of Windows on some computers, or Linux computers that access Windows shared directories where the protocol support will have to be updated.
Workgroup Authentication is also used for commands that can be issued on one computer but which run on another computer. Hyper-V Manager allows you on one Workgroup machine to display and manage VMs running on more than one physical machine. A client program running on one Workgroup machine can access a SQL Server on another Workgroup machine using Windows authentication if the Local userid is the same on both the client and server machines.
However, the Yale Managed Workstation native Windows OS is a member of the YALE Domain and not a member of the Workgroup, so it cannot participate in all this automatic cross-computer sharing.
Fully Qualified Usernames
...