...
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 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 machinesa 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”.
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 without providing explicit alternate credentials, then BOOJUM defaults to Workgroup Authentication and 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
An Active Directory is a central network service that creates SIDs for user accounts, and Domain SIDs can be shared with all the computers that are members of the Domain. Any user logging onto a machine with a Domain account gets the SID from the Domain. When that user moves to another computer in the same Domain and logs in, he gets the same SID on that machine too.
If you are logged into a computer with a Domain account, and you create a file on a USB drive formatted with NTFS, and you then move that drive to another computer in the same Domain, that computer recognizes the SID on the file and displays your Domain userid as the owner instead of the SID number.
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 against Yale policy to do this on a Yale owned machine, Windows allows a computer in a Domain to have both Domain Users and Local Users. In this case, when a user is logged in with his Domain account, then the machine uses Kerberos authentication to access files and services on other computers in the same Domain. Logoff and log back in as a Local User account, and now the computer uses Workgroup Authentication to access files and services on other computers connected to the same LAN.
A Local User account can have the same userid as a Domain account. The Domain account is referred to by the fully qualified name of domainname\userid. In the YALE Domain, YALE\bellman is a Domain account, and it is entirely different and completely unrelated to the Local Users BOOJUM\bellman and SNARK\bellman. They have different home directories, own different files, and have different permissions (because they have different SIDs).
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. Traditionally Windows Server lacks support for many consumer-oriented features. It doesn’t support Webcams for meetings, and by default all audio support is turned off so you have to reconfigure to hear anything. There is no Windows Store, and WiFi isn’t a type of networking that Servers need.
Windows Server 2025 will enable a lot of these features and might become a more reasonable choice for adventuresome end users. It is also an easier choice to download the disk and install in a VM.
When you launch Windows Server for the first time, Server Manager comes up. This is a GUI interface for adding Features and Roles like AD. Click “Local Server”, the second entry in the list in the left margin. Here you can click on and change things like the generated bad Computer Name (defaults to something like “WIN-0E37EN6I3U6“) and Time Zone (defaults to Pacific). For this example, we give the Server a Computer Name of FIT.
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 also become Domain Admins. This initial group of admins becomes especially useful because they are both Local Users and Domain Users at the same time. This will allow you to use either Workgroup Authentication or Domain Authentication to connect to this Server and access files or services (including AD Admin services). We create a user named “bellman”, or to be precise “FIT\bellman”.
For testing and software development, it is only necessary for this test Domain to have one computer (FIT) which is its Domain Controller and, because it is required, is also a DNS Server.
There are two PowerShell commands to install the Active Directory support and to create the new Domain. You may have to reboot between the two commands. The AD needs a full DNS name and a nickname. For this example, we make the nickname HUNTING.
The DNS name will only be known to the DNS server that you created while the second PowerShell command generated the Domain. You are free to define this name in other computers. The HUNTING nickname is, at this point, only known on the Server itself.
Fortunately, FIT is still a computer on your network, and you can reference it from other machines using standard tricks like typing in “\\fit.local”. Remember that part about how you can use either Workgroup or Domain authentication to talk to a machine in your network and authenticate as a Local/Domain user like “bellman”.
Here is the Big Idea. The Local User FIT\bellman is the same SID and therefore the same account as the Domain user HUNTING\bellman. Generally speaking, anywhere you could enter the DNS name of a Domain, you can instead enter the name of a Server that is a Domain Controller of the Domain. For example, in any AD PowerShell command, the -Server parameter can specify the Domain Name, but it can also be
get-ADxxxx -Server fit.local
Even though “fit.local” is the name of a computer and not the name of a Domain, it doesn’t matter inside your personal development network. The computer name designates a Domain controller, so AD stuff goes to the Domain even though it wasn’t explicitly named in the command.
At Yale, the Domain Controllers are secured and nobody can login to them except AD administrators. However, when you create an AD in your own VM, you are in full control. Of course, nothing you put in it will control any other machines. You can use it to understand and test various forms of authentication or learn more about AD in your personal Sandbox LAN.
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 their corresponding SID, and then all the programs they run in that session use that SID.
Anyone can run a new program under a different userid and SID by triggering an internal Re-Login where they provide or prompt for a new userid and password. This is called “RunAs”.
Components that are part of the Windows System are authorized to temporarily change their SID to any other SID that they can find by searching for the Users on the computer.
When a System Program simply changes the SID to some other SID, this is called “impersonation”.
Impersonation affects the permissions the program has to access Local files or call Local services. It works only on the local computer.
Changing the current SID did not create a password that can be used for Workgroup Authentication, nor did it obtain a Kerberos “TGT” object needed to do Domain Authentication, so there is no access to files or services on any other computer on the Local LAN. Even if the SID is a Domain SID that came from the AD, you still need the Kerberos TGT to communicate with any other Domain computers on the network.
Impersonation is used by SSH when you use public key authentication.
SSH Server
Every new Windows system gets the SSH client. The On Windows 10/11 or Windows Server 2022, 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 impersonationIt is authorized to use impersonation.
On Windows Server 2025 OpenSSH server will be pre-installed but will have to be started manually or reconfigured to start automatically.
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 is ssh.exe on Windows and just “ssh” on Linux.
You can run ssh.exe to prompt for a password. When SSH is called with a userid and password, it does a internal Re-Login and then the password is available to do Workgroup Authentication, and if the userid was a Domain userid (HUNTING\bellman) then Kerberos was used and leaves behind the TGT needed to talk to other machines.
Normally, people put a secret key file in their Home directory on the SSH client and a pubic key in their Home directory on the SSH Server and do “public key” SSH authentication. The SSH server verifies that the client knows the secret key, but now with no password to do a Login, all it can do is impersonate the user by starting cmd.exe under that user’s SID. This session will then have access only to local files and services.
SSH uses the secret key in the Home directory of the currently logged in use on the client machine. The ssh command contains the userid and computer name of the SSH Server. The userid in the command defaults to a Local User unless you explicitly qualify it with a Domain name. The userid you are logging in as does not have to in any way match the userid you are logged into on the client machine. SSH is the only form of programmed session that works between a Domain user account on one machine and a Local user or even a user in a different Domain on another machine.
When the OpenSSH Server starts cmd.exe, whether through a userid/password or public key impersonation, if the user specified in the command is a member of the Administrators group on the machine, sshd.exe has to decide whether cmd.exe will run in user or administrator mode. It has to be one or the other, and there is no way in cmd.exe to elevate from user to administrator mode through SSH. They decided that most people using SSH want to do admin stuff, so they opted for cmd.exe to run elevated from the start.
However, they wanted an extra level of permission to do this. Therefore, to login as any user in the Administrators group of the remote machine, the SSH public key has to be a line in the Windows file location of C:\ProgramFiles\ssh\administrators_authorized_keys (instead of the authorized_keys file in the individual user’s home directory).
PowerShell Remote using SSH
...