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. The fact that they have the same userid doesn’t matter because the file is only associated with the SID of the user that created it.
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 user defined on that server computer.
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.
Fully Qualified Usernames
Typing out a long meaningless unique number is hard, and remembering it is impossible.
So there is a way to define a User account by qualifying it with the hostname or fully qualified name of the machine on which it is defined.
For this example, assume there are two computers named SNARK and BOOJUM and each has an account named “bellman” with the same password on both machines. SNARK\bellman means the account for bellman on SNARK and BOOJUM\bellman means the account on BOOJUM. They are two different accounts with different SIDs. If bellman writes a file onto an NTFS thumb drive on SNARK and moves it to BOOJUM, then it belongs to some unrecognized S-1-5-21-193347605-2781663674-4123826664-1001, not “bellman”.
However, 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.
The university Domain is named “YALE”, so for this example assume that “bellman” is also the Netid of the person who owns SNARK and BOOJUM. The Domain SID is identified as YALE\bellman.
Now to create a real messy example, suppose we belatedly join the two computers SNARK and BOOJUM to the Yale Domain and add the YALE\bellman domain account to the Users group on both machines.
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 create 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. Create files or grant permissions to a file on an NTFS thumb drive attached to SNARK, then move it to BOOJUM and BOOJUM knows these files and permissions belong to YALE\bellman who has the same SID everywhere.
So the good news is that if everyone uses Domain accounts on all machines, then users, files, groups, and permission work everywhere, across the network or on transportable media. However, in a hybrid environment where you have both Domain accounts and Local accounts, then the Domain accounts work everywhere but never have NTLM style access to files belonging to a local user with the same name and password, while the Local accounts get NTLM transparency across the home network but are unable to access YALE Domain resources anywhere.
Impersonate
Windows has two different ways to generate a SID for a remote user request or session.
If a Userid and Password is presented along with the request, then the server can use them to login. If it is a Domain Userid it can login to the YALE AD. If it is a Local User then it can verify the password on the local machine and then save the password for NTLM access to services on the local network.
However, sometimes a program will be able to verify a user without using a password. It might use a Certificate, or a public key (SSH), or some biometric thing. In this case it cannot login to the YALE Domain and it has no password to store for NTLM.
However, if it has been permitted (by Group Policy configuration on the computer) to make the request, it can ask Windows to start a process that “impersonates” the SID of the account. This gives the user’s request or session access to local files and services on the local machine that the SID is allowed to use. However, a process running through impersonation has no access to any file or service on any other computer on the network.
If you SSH to an account on another machine and authenticate with a password, then the password is stored and can be used to access network services. If you SSH with your public key, then there is no password and the session uses impersonation and only has implied access to what is permitted to this user on this computer. Of course, you can store a public key or password credential on the machine and code that knows how to find it could start a new network connection.
Powershell Remoting
Some Powershell commands operate on other computers.
If the command has a -Computer parameter and an optional -Credential then it uses WSMan. In a home environment where all the computers are members of a Workgroup and are connected to the same network, then you can probably Enable-PSRemoting (you are given a checkbox to do this when installing Powershell 7) and use NTLM authentication. Then you can execute commands across computers where you have a userid with the same password on two or more machines.
Powershell 7 is also migrating toward an SSH based version of remoting, where you specify -Hostname and -Username instead of Computer and Credential. This works across Windows and Linux systems and will use your SSH public key.
Both the WSMan and SSH versions require some additional configuration and have certain limitations. For example, WSMan can be used by a Powershell 7 client, but it runs old Windows Powershell 5 on the server. To get Powershell SSH remoting to work, you need to edit the SSH configuration on the server.
Windows SSH
Microsoft has an Open Source project to develop OpenSSH for Windows.
SSH creates a session and runs commands on Windows or Linux system on the network. It does not support Microsoft technologies like NTLM or WSMan. To authenticate you either provide a userid and password valid on the other system or else you provide a userid and store a private key file in the .ssh subdirectory of you home directory on the client system and a public key file on the server computer.
Although SSH itself supports commands, there are utilities that use the same connection to transfer files, and VS Code can create a split development environment where the standard VS Code user interface is presented on the client machine, but all files and operations take place on the server machine elsewhere in the network.
The SSH client is installed by default, but the SSH server has to be selected as an Optional Feature of Windows. The server is usually installed by default on Linux systems.