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 Authentication
Personally owned machines or VMs are not members of an AD Domain, but they can be on the same home or small business network. To allow simple administration and file sharing between Windows 11 computers on such networks, Microsoft has a form of Network Authentication for a “workgroup” with Local Users.
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. If you put a file on a USB disk and move it to the other machine, the SID will not be recognized on the machine that did not create it.
However, if one machine shares a directory and the other machine maps that shared disk to an unused disk letter, now “workgroup” authentication applies over the network.
For thirty years, Workgroup authentication has used a protocol called NTLM (or NTLMv2 in its latest version). Starting with some future version of Windows 11 after 24H2 Microsoft will be adding a new protocol based on Kerberos called LocalKDC, but the switch will be transparent to users.
Using either NTLM or LocalKDC, the two workgroup computers will, without transmitting the password, verify that each has the same password for this userid. The Server end of the connection assigns its local user SID to the session, and the client computer has access, through the network, to the same files, SQL Server logins, and admin services that the Server permits to its local user.
The technical details of how and why it works are unimportant to most users. Typically, someone will simply define all the same userids and passwords on all computers and VMs and they will simply be able to talk to each other. A developer may do something a bit more complicated and is then better off to understand what is going on inside the box.
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, 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. 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
Even before Microsoft created Active Directory, a Domain was a set of userids with SID values that could be shared on multiple machines over a network. When a user is defined in a Domain, then a SID is created. Other machines that are members of the same Domain can create accounts on the machine for that Domain user, and when they do so they copy the SID from the Domain controller to their local account database.
If we now repeat the previous experiment and transfer a file from one computer to another computer using a USB drive formatted with the NTFS file system, then a file created by a Domain user account on one machine will be recognized by another machine in the same Domain because all the Domain SID values are known and shared by all the computers in 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 basic security standards.
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 not allowed by YALE policy, there can be both a Doman account with a given user name and a Local account with the same username. It is possible for SNARK to have both a SNARK\bellman local user and a YALE\bellman Domain account. These are two entirely different people, with different files and permissions and separate home directories.
If someone is logged into a computer with a Domain account, then Kerberos protocol is used to authenticate to the login machine and to all other computers anywhere in the world that are members of the same Domain. If someone is logged on to a computer with a local user, then workgroup authentication is used to other computers, but typically those computers will be on the same LAN.
Your Own Domain Controller
You can only create an AD on a Windows Server machine. It can be a real computer or a VM. Yale’s site license allows anyone at Yale to run Windows Server, but it is not a very good choice for a personal computer. It lacks end user features like Windows Store, drivers for devices that servers don’t use (like WebCams for meetings), and other things you use every day. However, Windows Server is easy to install as a VM.
There is a Server Manager with a menu interface to add the Active Directory Role to the server and then configure your own single-machine AD. Alternately, you can do this with two PowerShell commands.
However, before you create the AD, you should create Local Users who are going to be in the Administrators group of the Server. That is because when you create the AD, they become Domain Admins.
Start by creating a Windows Server VM. At this point it is just a Windows machine and needs a hostname, so we will call it FIT. Create a local user “bellman” and put him in the Administrator’s group. Create other admins as desired. At this point the Server is temporarily just a Workgroup machine and it can interact with other computers and VMs using workgroup rules.
Now two PowerShell commands documented elsewhere can transform the FIT machine into the Domain Controller of a new AD. Every AD must have its own DNS server, and it needs a new DNS name that will be known to that server plus a nickname. We give it the DNS name of hunting.yale.sandbox and nickname of 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.
In a corporate or campus AD, the Domain servers provide a widely used public service, but nobody is allowed to login to these machines except for a small number of specially trusted users. This is a Sandbox AD. You are the only one who will ever use it, and your VMs and test users are the only ones who will use it. So, it is convenient for you to be easily able to access it from all your computers.
So in this case, if you are “bellman” or if you added your real userid to the Administrators group before creating the AD Domain, you can now access the Windows Server and all the AD services and interfaces using either a Domain Admin account login (like HUNTING\bellman) to a computer in the domain (like FIT), or else you can still use workgroup authentication and send AD requests and commands from other computers in the network using NTLM/localKDC protocol from a login as SNARK\bellman or BOOJUM\bellman. Because the local userid FIT\bellman is the same SID as the Domain user HUNTING\bellman, once a network request is received by the machine, it gets the same SID and is handled the same way whether the request authenticated using workgroup or Kerberos protocol.
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 the corresponding SID, and then all the programs run in that session use that SID.
Anyone can run a new program under a different userid by triggering a new Login and provide or prompt for a new userid and password. This is called “RunAs”.
However, components that are part of Windows or run as part of the System are authorized to temporarily change their SID to any other SID defined in the system. This is called “impersonation”.
Changing the current SID does not create a userid/password or get the Kerberos “TGT” object needed to authenticate across a network using an AD Domain. So, while the program can temporarily use files and call services on the local machine, it cannot do anything involving other machines.
SSH Server
Every new Windows system gets the SSH client. The SSH Server is an optional Feature that can be installed on Windows desktop or server systems. The OpenSSH server (sshd.exe) runs as a background service under a SYSTEM userid. It is authorized to use impersonation.
The client ssh program can either present a userid/password or a public key. If it presents a password, then sshd.exe can do a RunAs login to create a new cmd.exe session running as that user. This session has the password and if it is a Domain userid it has the Keberos TGT object needed to authenticate to network services.
However, sshd.exe can also authenticate a user with a public key. The client uses a private key that has to correspond to an entry in the $HOME\.ssh\authorized_keys file of the specified userid. The userid can be a local user with a SID from the local machine, but it can also be a domain userid with a SID from AD. However, when sshd.exe impersonates a domain SID it does not magically generate a Kerberos TGT that a real domain user would have from a real Domain login. The local SID is good on the local machine for accessing local files. It can even make to the local SQL Server running on this machine.
If the $HOME\.ssh directory contains a private key, then it can be used to ssh to another machine in the network. Alternately, the end user can type in a userid and password to use when connecting to another computer. The only restriction is that the “currently logged in Windows user” level of authentication is only good for accessing things on the local machine when running a session created by ssh using public key authentication.
There is a special Windows-only configuration problem. If a user is a member of the Administrators group, then sshd.exe has to decide whether to start the new cmd.exe session in “elevated” (Run as Administrator) mode. It is not possible once the session gets going for someone to successfully elevate in the middle of a session since there is no way to answer the popup Window that you are presented when you elevate in a normal desktop login. Therefore, sshd.exe will always start Administrator users in elevated mode. If you want to run in non-elevated mode, you need two userids to use with SSH, one who is an Administrator and one who isn’t. For security, when someone in the Administrators group logs in through SSH their public key certificate is checked against the list in C:\ProgramFiles\ssh\administrators_authorized_keys instead of the authorized_keys file in the user’s home directory.
PowerShell Remote using SSH
There are some standard Windows Management tools that allow you to administer other machines over the network. The Windows Management Instrumentation (WMI) protocol authenticates between two machines that are members of Domains using the Kerberos protocol, and it authenticates between two machines that are not members of any domain using the workgroup protocol. If one machine is in a domain and the other is either not in any domain or is a member of a different untrusted domain, then WMI doesn’t work.
A developers Sandbox consists of a laptop that must be a member of the YALE Domain, plus VMs that may be workgroup machines or may be members of the internal test SANDBOX domain. WMI doesn’t work across all of them, and yet the developer wants to be able to administer the machines centrally without have to login to each of them one at a time.
PowerShell Remoting can now use SSH between computers. To set this up, you need your private key on the system from which you will be doing administration (typically your native laptop in the YALE Domain) and you need a userid in all the other machines that is a member of the Administrators group, and you need your public key to be in the C:\ProgramData\ssh\administrators_authorized_keys file.
Now domain membership doesn’t matter for any of your VMs. You can run PowerShell commands that do machine administration by adding, for example:
-UserName bellman -HostName SNARK
on PowerShell commands such as Invoke-Command or New-PSSession that operate across computers. Note that you replace the WMI parameter -Computer netname with the SSH parameter -HostName netname.