Understanding Well-Known Security Principals, Part 1

If you haven't used Windows well-known security principals, you might not realize how powerful and complex they can be. Because Microsoft added new well-known security principals to Windows Server 2003, getting up to speed on using these entities to administer the access control settings of Windows resources is a good idea. But before I go into detail about their administration, I want to briefly review security principals generally and well-known security principals specifically. Part 2 of this article will explore the details of administering these complex entities.

A Windows security principal is an authenticated entity that uses the resources (e.g., files, printers), applications, or services that a Windows computer hosts. A security principal can be a user, computer, or group of users or computers. Each security principal has a unique identifier that's known as a SID. For an introduction to fundamental Windows security concepts, see "A Matter of Trust," July 2005, InstantDoc ID 46591, and "Logon Rights: the Heart of Windows Access Control," August 2005, InstantDoc ID 46870.

Well-known security principals are a special category of security principals. They represent special entities that the Windows security subsystem predefines and controls. Popular examples include Everyone, Authenticated Users, System, Self, and Creator Owner.

Unlike typical security principals, you can't rename or delete well-known security principals. You can't create your own well-known security principals; they're the same on every Windows system, although the list of available well-known security principals varies slightly by OS version. A well-known security principal also has the same SID on every Windows system. For example, SID S-1-5-10 always represents the Self well-known security principal, and SID S-1-3-0 always represents the Creator Owner principal.

A Well-Known Security Principals Overview
Table 1 lists the well-known security principals that are available in Windows 2003, Windows XP Service Pack 2 (SP2), and Windows 2000. Table 2 lists the new well-known security principals that Microsoft introduced in Windows 2003; an asterisk indicates ones that are also supported in XP SP2. For each well-known security principal, the table also lists the corresponding SID. You can also find a list of all the well-known Windows SIDs in the Microsoft article "Well-known security identifiers in Windows operating systems" at http://support.microsoft.com/?kbid=243330. I explain most of the well-known security principals listed in Table 1 and Table 2 in part 2 of this article.

In Windows 2003, Microsoft added the Local Service, Network Service, Digest Authentication, NTLM Authentication, Remote Interactive Logon, SChannel Authentication, Restricted Code, Other Organization, and This Organization well-known security principals. These new principals show up in Active Directory (AD) only when the domain controller (DC) that holds the PDC emulator Operations Master role is running Windows 2003. In a domain that contains both Windows 2003 and Win2K DCs, you must first transfer the Operations Master role to a Windows 2003 DC. This information is documented in the Microsoft article "Local Service and other well-known security principals do not appear on your Windows Server 2003 domain controller" at http://support.microsoft.com/?kbid=827016. This limitation should have little effect on your AD infrastructure because many of the new features that use the new Windows 2003 well-known security principals require Windows 2003's functional level.

You can view most of the well-known security principals listed in Table 1 and Table 2 (e.g., Everyone, Authenticated Users) as well-known security principal groups. Unlike typical groups, the OS—not an administrator—automatically controls their memberships, which depend on certain conditions. For example, in XP and Win2K, the OS automatically assigns a user to the Interactive group if the user is physically sitting at the computer where the resource resides or if the user is logged on to that computer via an RDP connection. In Windows 2003, the user is added to the Remote Interactive Logon group.

You can also refer to these well-known security principal groups as dynamic groups because the OS determines their memberships in a dynamic way. They shouldn't be confused with the dynamic LDAP query-based groups that Microsoft introduced in the Windows 2003 Authorization Manager (AzMan).

An interesting characteristic of well-known security principals is the way they're replicated between AD instances. Although they might apply to thousands of AD objects, only their names are replicated, not their memberships. As a result, you can't use classical AD query and administration tools to query their memberships. Because of the way you use well-known security principals, you don't need to store their memberships. Well-known security principals' primary role is to provide a SID that you can add to a user's access token when a user logs on to a system or accesses a resource. The presence of a particular well-known security principal in the access token gives the user certain privileges on the system or resource. To view an access token's content, use the WhoAmI tool with the /all switch (WhoAmI comes with Windows 2003 and with the Microsoft Windows 2000 Resource Kit) or a freeware tool such as SecTok (which you can download from http://www.joeware.net), as Figure 1 shows.

Administering Well-Known Security Principals
Well-known security principals are available on all Windows OSs, whether they're installed in domain or standalone mode. However, not all well-known security principals are added to standalone machines. Also, as I previously explained, the list of available well-known security principals varies slightly by OS version.

In a Windows domain environment, AD objects that represent the well-known security principals are stored in the WellKnown Security Principals container beneath the Configuration container. You use the Microsoft Management Console (MMC) ADSIEdit snap-in to view the container's content, as Figure 2 shows. On a standalone machine, well-known security principals are stored in the local security database (Security Account Manager—SAM).

You can add well-known security principals to other groups and to Windows objects' ACLs. In AD, you can even delegate permissions to well-known security principals. Confusingly, the first time you try to add a well-known security principal to another group, you won't find it in the MMC Active Directory Users and Computers snap-in. You must know the correct name of the well-known security principal; you can't use the Active Directory Users and Computers snap-in's object picker to browse for the object. Even the advanced query options in the object picker won't help you if you don't know the correct name. This happens because the Active Directory Users and Computers snap-in concentrates on managing the data in the AD domain naming context, and well-known security principals are stored in the AD configuration naming context. The same problem occurs when you use the MMC Local Users and Groups snap-in, in which case the well-known security principals are invisible to hide their complexity from nonprofessional Windows users.

In the Active Directory Users and Computers snap-in, as soon as you use a well-known security principal, it will show up in the ForeignSecurityPrincipals container. For example, when you add the Authenticated Users well-known security principal to the Print Operators group, an entry for Authenticated Users will be added to the ForeignSecurityPrincipals container, as Figure 3 shows. Note that most well-known security principals reference NT AUTHORITY in their readable names. NT AUTHORITY is the security authority in the built-in Windows security domain that exists on every Windows machine.

You can also use the command line to add well-known security principals to other groups or to a resource's ACL. To add them to a group, you can use the Net Group and Net Localgroup commands. For example, to add the Interactive group to the Backup Operators local group, enter

net localgroup "Backup Operators" Interactive /add

at the command line.

You can use the Microsoft Windows Server 2003 Resource Kit's subinacl.exe utility to add well-known security principals to an ACL's resource from the command line. (You can also download the tool from http://www.microsoft.com/downloads/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b&displaylang=en.) For example, to give the Local Service principal group read access to the MyApplication registry key, enter

subinacl /keyreg MyApplication /grant="Local Service"=r

at the command line.

Powerful Principals
I've barely scratched the surface of the power behind Windows well-known security principals. Part 2 of this article will look more closely at the individual principals, the Windows features that use them, and tips for working with them.