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. When you run SSMS you can build a backup or restore request for a *.bak file on a network disk you have access to, but when that request is sent to the SQL Server it cannot access the network share so the backup fails.
When you run Hyper-V Manager you can configure a VM to mount an ISO DVD image from a network disk you have access to, but when you try to start the VM it will fail because Hyper-V itself cannot access the network disk.
Local User SIDs created on your Computer
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 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 10 or 11 computer. 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 on one machine and is meaningless on other machines. You can see this by creating a file on an NTFS formated thumb drive and then moving the drive to another computer. The other computer has no idea who owns or created the file. Local SID are meaningless across a network.
When you login to a computer, it runs everything in your session under your SID.
If you create two Local Users on two personally owned computers and give each the same username and password, then the two accounts have different SIDs on each machine. Again you will see this if you create a file on a thumb drive and move it to the other computer. Although the same Userid exists on both machines, it is the SID and not the Userid that is stored with the file, and that SID is meaningless on any machine other than the one that created the file.
However, in this case things are different across the network. When someone running under a Local User account tries to connect to another computer on the home network, Windows uses an authentication mechanism called NTLM. The two computers, without transmitting the password, agree that the server computer has a userid with the same name as the user currently logged into the client machine, and the password associated with this userid is the same on both machines. The server end of the connection is then assigned the SID of the matching Userid on that machine.
This “two local users with the same name and password must be the same person” approach was called “Workgroup” computing when Microsoft created it 30 years ago. Microsoft doesn’t talk much about it today because they would much rather sell you disk space in the Azure cloud and put OneDrive on all your computers, so you transfer a file between two of your home computers by sending the file 1000 miles away and then having Microsoft send it back again, but to the other machine.
[Note: Microsoft has announced that in the future it will replace the NTLMv2 authentication protocol with a version of Kerberos called LocalKDC. Every Windows 11 system will be able to perform Kerberos Authentication of remote Network sessions using Local User accounts. This will be an internal drop-in replacement for NTLM for file sharing and network administration in Workgroups and will be transparent to end users. It is separate from the traditional use of Kerberos in AD Domains.]
Fully Qualified Usernames
Typing out a long meaningless unique number is hard, and remembering it is impossible.
So there is a notation that we use to describe the specific account without using SID. You qualify the Userid by a prefix indicating the machine or AD in which the SID is 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, then BOOJUM verifies that it has a local user also named “bellman” and that the password for “bellman” is the same on both BOOJUM and SNARK. So it assigns the SID of BOOJUM\bellman to the request coming from the network and allows the remote SNARK\bellman to access files as BOOJUM\bellman.
Active Directory Domain User SIDs
University and corporate systems assign centrally defined Domain User accounts through Active Directory. AD provides a set of central servers where administrators can create User accounts with a userid (the Netid), password, and a Domain generated SID. Administrators also join computers to the AD. Once a computer joins a Domain, it can login Domain Users, run programs under the Domain SID, and assign file and directory ownership and permissions to that SID. Everything that can be done with a Local User SID can also be done with a Domain SID, but Domain SIDs are the same on all computers that are a member of the Domain.
Yale Security Policy requires you to use your Yale AD account to login to Managed Workstations and other Yale owned computers performing Yale business. This allows the University to enforce minimal security standards.
Active Directory provides a set of accounts and SIDs that are shared between machines. When a computer joins the AD, it continues to have local user account but in addition can allow AD SIDs to login, create, and access files. The AD has its own nickname, and the nickname of the Yale AD is “YALE”. So to extend this example, assume that “bellman” is also the Netid (Userid in the Yale AD) of the person who owns the computers SNARK and BOOJUM, and he joins both machines to the Yale AD.
The account in the Yale AD for Userid “bellman” is identified as “YALE\bellman” and is a SID that is different from both SNARK\bellman and BOOJUM\bellman. However, once the two computers are joined to the AD, they can have logins, user profile directories, and file permissions for “YALE\bellman” as well as their own local “bellman” user.
The user can login to SNARK as either the domain account YALE\bellman or the local account SNARK\bellman. These are, however, two completely different users with different SIDs and there is no way to connect them. Even if YALE\bellman has the same password as SNARK\bellman, when the user is logged in as YALE\bellman he has no access to SNARK\bellman files, unless he logs on as SNARK\bellman first and grants permission to his Yale Domain user account to also access his local files. Even then, they are two separate users who have just granted each other permission to use each other’s files.
However, files created and permissions granted to YALE\bellman on either SNARK or BOOJUM are assigned to the same YALE Domain SID and they do work across machines. If YALE\bellman creates files or grant permissions to a file on an NTFS thumb drive attached to SNARK, then moves the drive to BOOJUM, then BOOJUM knows these files and permissions belong to YALE\bellman and will grant permission to access those files when YALE\bellman logs in or accesses the files over the network.
Your Own Domain Controller
Creating your own private AD is something that ordinary people don’t do. Anyone at Yale has a license to use Windows Server, and if they create a Windows Server VM, then with a few commands they can create their own AD Domain. When you create your own Domain this way, there is a special interaction between what were previously Local Users (before you created the Domain) who then also become Domain account (particularly Admins). This article would not be complete without documenting this special case.
Start with a spare computer or a VM running Windows Server. It needs a computer host name, so we will call it FIT (not an acronym, a word from the Louis Carroll Snark book). Our previous userid “bellman” is added as a local Administrator of this computer when the system is installed and is given the same password it had on the other machines. This means, of course, that it gets yet another SID (FIT\bellman) that local to and initially only meaningful on FIT, and “bellman” on other computers can access this account using Workgroup authentication.
Now two PowerShell commands documented elsewhere can transform the FIT machine into the Domain Controller of a new AD. The AD has its own name, which we will call “HUNTING”.
When the AD is created, the local administrators of the FIT Server now become administrators of the HUNTING AD Domain. Because an unknown amount of time has passed since the Server was installed, and because many files and directories may be owned or permitted to the SID of the local user FIT\bellman, it is not possible to change that SID when FIT\bellman also becomes HUNTING\bellman. So, the old Local User SID is copied to the AD and becomes the AD SID of HUNTING\bellman.
This connection aliasing Local and Domain accounts occurs only during the creation of the AD, so before you create the AD you should create all the Local User accounts that you need to behave this way.
As long as the AD continues to exist, there is no meaningful difference between a network session that authenticated to the computer through NTLM/LocalKDC as FIT\bellman and a network session that authenticated through the AD as HUNTING\bellman. Both sessions have the privileges of a Local User, Local Administrator, and Domain Admin. All programs in the sessions run under the same SID, and all operations they perform and commands they issue have both Local and Domain privileges.
This is, however, quite useful to a developer Sandbox because it means that computers and VMs that are not members of the Domain can interact with the Domain using NTLM/LocalKDC authentication as the Local User account.
Impersonate
All programs run under a SID. Some programs run in the background under Microsoft built in SIDs like SYSTEM. Other programs inherit from the session the SID of the User that authenticated to the computer.
Authorized system components can change the SID a program is running under. They may do a new authentication to get the SID, or in some cases simply look it up. Generically, this is called “impersonation”.
Programs running under a new SID have access to all the files and services permitted to that SID on the current machine. However, if they do not have the password for the user or a login to the Domain under that account (what is technically called a “Ticket Granting Ticket” or TGT) then they cannot access files or services on other computers.
If you use SSH to connect to another computer using your public key file (in your .ssh directory) then you do not transmit a password and do not create a TGT. Your resulting SSH session can only use local files unless you transmit through the SSH tunnel a command containing a userid/password that the remote machine can use to login to something on the network.
However, if you SSH to another computer with your userid and password instead of using the public keys, then the password is transmitted over the encrypted SSH tunnel, and the other machine can login and save the password. Then the saved password can be used to create connections from the remote machine to other systems in the local network.
Most of the time, however, “impersonation” is a term associated with special applications. It is used in cases where an authorized application performs an operation on behalf of a remote user while switched to the SID of that remote user. This is a complicated programming technique outside the scope of this article.
There are also network administration tools that can be configured to transmit the password or some other token of fully authority (like a TGT) from the client computer to a remote machine, so the remote machine can perform operations with the full authority of the client. This is useful but creates a vulnerability if the remote machine has been compromised. This is also a complex topic outside the scope of this paper.