A security principal is an entity that can be positively identified and verified via a technique known as authentication (WhatIsAuthentication). Usually when people think of security principals, they think of users, but there's a bit more to it than that. I like to think of three different types of principals:

• User principals
• Machine principals
• Service principals

Here's an example. Imagine that we have two machines in a domain called DOM, named MAC1 and MAC2. DOM\Alice is logged into MAC1 interactively. Now a bunch of network requests that originate from MAC1 are serviced by MAC2. If those requests are authenticated, which security principal will MAC2 see for any given request?

The answer is that I've not given you enough information! Just because Alice is logged on interactively doesn't mean that all requests from that machine will go out using her credentials. Security principals in Windows are assigned on a process by process basis, via a little kernel object called a token (WhatIsAToken). So it depends on which process made the request. Take a look at Figure 12.1 for an example. Here we have three different processes running on the machine where Alice is working. The first is explorer.exe, which is Alice's shell program. When Alice uses Explorer to connect to a share on MAC2, her request is authenticated between explorer.exe on MAC1 and services.exe (the process that implements file and printer sharing) on MAC2. Because explorer.exe is running as Alice, her credentials are used for that request.

Figure 12.1 Security principals and processes

We also see the operating system itself (some service hosted in services.exe on MAC1) making a request to MAC2. It's not Alice, though! It's the operating system of MAC1 (that's what SYSTEM represents), so this request will use MAC1's domain credentials and will be seen as DOM\MAC1 by the server. Finally, MAC1 is running SQL Server under a custom service account called DOM\SQL, so any requests from that process will be seen as DOM\SQL. Bear in mind that at any given time there will very likely be several different principals operating on any given machine. Oh, and if you've heard that SYSTEM has no network credentials, please check out HowToChooseAnIdentityForADaemon for clarification.

Each security principal is issued an account via an authority. An authority is an entity that maintains an account database, which includes such basic information as the name of the principal, the groups (WhatIsAGroup) in which the principal is a member and, arguably the most important thing of all, a master key for the principal calculated by hashing the password for the account. To learn more about how the master key is used during authentication, check out WhatIsKerberos.

There are two types of authorities in Windows: local and domain. In the example just described, we were using a domain. A domain authority stores the accounts database in Active Directory, and each domain controller for a given domain has a replicated copy of that database. A local authority (called the Local Security Authority, or LSA for short) exists on each machine and stores its account database in the registry (this is sometimes referred to as the SAM, or Security Accounts Manager).

Local accounts aren't used much in domain environments, but on a standalone machine that isn't part of a domain they’re the only security authority you've got and they work quite well protecting the local machine. Local accounts can even be used (some would say "abused") to authenticate network requests between machines by adding the same local account (user name and password) to several machines. Windows will use an older authentication protocol called NTLM (you may have heard it called challenge-response) to authenticate these principals over the network (Brown 2000), but it's a bad idea to rely too much on this because the master key for the account must be kept on every machine that needs to authenticate that principal. This makes administration tough (just try to change your password!) and exposes the key to offline brute force and dictionary attacks from anyone who administers any of the workstations on which the account exists. Domain accounts, on the other hand, centralize these keys in Active Directory, which is hosted only by domain controllers and can therefore be more easily physically secured from attack. You can lock your domain controller up in a closet, but that won’t fly for the secretary’s workstation.

To see a list of security principals in a domain, you'll need to use an MMC snap-in called "Active Directory Users and Computers." If you drill down into a domain and into a folder called Users, you'll see a list of user principals and domain groups. If you sidestep over into a folder called Computers, you'll see a list of machine principals. These are first-class security principals, each with its own master key. Machines can be made members of groups just like users can. They log in to the domain just as users do by proving knowledge of their master key, which each machine that is a member of a domain stores in its registry ¹.

¹ If you don't believe me, run the registry editor as SYSTEM (the easiest way to do this is from an administrative command prompt; type at 9:23am /interactive regedit.exe, substituting whatever time is appropriate: Make it one minute in the future). Once regedit fires up, carefully look at the subkeys under HKLM/Security/Policy/Secrets. You're looking at the machine's password stash, more formally known as the LSA private data store, and if the machine is a domain member, you should see a subkey called $MACHINE.ACC, where the machine's master key lives. You won't be able to view the key with regedit.exe, but at least now you have some evidence that it exists. Now close that copy of regedit.exe before you break something!

PortedBy Aldo Prinzi