Last month, in "Understanding Well-Known Security Principals, Part 1," InstantDoc ID 47857, you learned that Windows well-known security principals (a special category of security principals that the Windows security subsystem predefines and controls) are powerful tools for managing and maintaining security. You saw how these wellknown security principals control and simplify administering access to Windows resources. Remember that Windows defines the well-known security principals: You can't create, rename, or delete them, and they're the same for all Windows systems. This month, we look at details of the individual well-known security principals. I'll show you the Windows features that use the well-known security principals and provide a few tips for how to use them effectively.
Authenticated Users and Everyone
The Authenticated Users well-known security principal includes all users that Windows authenticates through a valid set of user credentials at logon. Authenticated Users includes all users who have valid credentials in the forest and its domains, and users from other forests who access resources in the local forest through valid credentials and a forest or external inter-forest trust relationship.
The Everyone well-known security principal is a superset of Authenticated Users and includes Authenticated Users and the Guest account. Membership is complicated. Table 1 shows membership specifics for Authenticated Users and Everyone. You can see that for Windows XP and Windows 2000 Active Directory (AD), the Anonymous account is automatically a member of Everyone but not of Authenticated Users. For Windows Server 2003 AD and Windows XP Service Pack 2 (SP2), the Anonymous account is by default not a member of Everyone, but you can configure Anonymous for membership by enabling the Network Access: Let Everyone permissions apply to anonymous users security policy setting. You can also enable this setting by setting the value of the HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControl Set\Control\LSA\EveryoneIncludes Anonymous (REG_DWORD) registry entry to 1. Anonymous is not a member of Authenticated Users.
System, Local Service, and Network Service
In Win2K and earlier, Windows services and third-party applications typically run in the security context of the System well-known security principal (also called the Local System or LSA account). AD users know this as the Well-Known-Security-ID-System. System acts as the host computer account on the network and as such appears as the name Domain name\ machine name$ on the network. The local system name of the account is NT AUTHORITY\System. The account doesn't have a password that an administrator needs to manage: It uses the computer account credentials that Windows assigns and manages automatically.
System's powers are comparable to those of a UNIX system's root account. When you run a service or application in the security context of System, that service or application has almost unlimited privileges on a Windows system. For example, if a service logs on to a domain controller (DC) by using the System well-known security principal, the service has local system access on the DC. If the service were compromised, malicious users could then make changes to AD. Be careful—when you want to honor the principle of least privilege, avoid using System.
To honor that principle and avoid the risk inherent in using System, Windows 2003 and XP SP2 provide two alternatives: Local Service and Network Service. Local Service provides the least level of privilege for services that need to access only local resources. Smart Card, Remote Registry, and Telnet services use the Local Service account. A service that runs as Local Service accesses network resources as a null session, using Anonymous credentials. To configure a service to use Local Service, enter NT AUTHORITY\LocalService on the Alerter Properties dialog box's Log On tab. You don't need to supply a password.
Network Service provides the least level of privilege for services that need to access other computers on the network. Like a service running with System, a service running as Network Service accesses network resources by using the credentials of the computer account. The Domain Name System (DNS) and Remote Procedure Call (RPC) services use Network Service by default. To configure a service to use Network Service, enter NT AUTHORITY\NetworkService on the Alerter Properties dialog box's Log On tab. You don't need to supply a password.
This Organization and Other Organization
Windows 2003 provides the This Organization and Other Organization wellknown security principals, which relate to a new inter-forest trust security feature called selective authentication, or authentication firewall. Selective authentication lets you define an additional layer of access control that determines inter-forest resource access. For example, you can use selective authentication to restrict initial logon to a computer and then to grant or deny access to objects within that computer.
You can configure selective authentication on both forest and external inter-forest trust relationships, and on external inter-domain trust relationships. You can set up forest trust relationships between the root domains of two forests that apply to all inter-forest authentication traffic. You can set up external trust relationships between any two domains in the two forests that then apply to the authentication traffic between these two domains.
You can use the Trust Wizard or the properties of the trust relationship to configure a forest or external trust relationship for selective authentication. To configure selective authentication from the trust relationship's Properties dialog box, select the Authentication tab, then choose Selective Authentication.
Note that you can set up selective authentication only when the domain or forest that has the outgoing trust defined is at a Windows 2003 functional level. You can also set up selective authentication when you're configuring trust for a Windows NT 4.0 domain and want to restrict access to the resources hosted in a Windows 2003 domain.
When a forest or external trust relationship has selective authentication and a user tries to access a resource in the other forest (crossing the inter-forest trust relationship), Windows adds the Other Organization well-known security principal to the user's access token. Users accessing resources in the inter-forest trust relationship have the This Organization well-known security principal in their access token by default. When a user crosses a forest or external inter-forest trust link relationship that doesn't have selective authentication, Windows adds This Organization to the user's access token. In this case, membership of This Organization is the same as membership of Authenticated Users.
When a user's access token has the Other Organization well-known security principal, resource servers check whether the user requesting access has been granted Allowed-to-Authenticate permission on the resource server. You can set Allowed-to-Authenticate permissions from the ACL editor on a computer object. If the user has Allowed-to-Authenticate permission, inter-forest authentication succeeds. In the authorization phase, the resource server checks whether specific permissions are set for Other Organization, and then grants or denies resource access accordingly.
Restricted Code
Windows adds the Restricted Code well-known security principal to a user's access token when you run RunAs with the Run this program with restricted access option in Windows 2003 or the Protect my computer and data from unauthorized program activity option in XP. RunAs offers high-privilege accounts (e.g., administrators) a convenient way to switch to the security context of a least-privileged user when executing a program, thus limiting the exposure to malware inherent in their high-privilege security context. For more information about RunAs, see "Learn to Be Least," October 2005, InstantDoc ID 47622.
When the user's access token has the Restricted Code well-known security principal, Windows eliminates all rights held by the user except for Bypass Traverse Checking, prevents the application from accessing the user's profile, and allows only Read access to the HKEY_LOCAL_ MACHINE and HKEY_CURRENT_ USER registry hives.
Restricted Code provides a convenient way to honor least privilege without having to remember two user accounts and two passwords. Instead of using RunAs to switch to the security context of a least-privilege account, you can use RunAs to switch to a locked-down version of the account's current security context— without entering the credentials of a second account. For more information about the RunAs feature and its use of Restricted Code, see Aaron Margosis' article "Running Restricted" at http://blogs.msdn.com/aaron_ margosis/archive/2004/09/10/227727 .aspx.
Logon-and Authentication-Type
The Windows 2003, XP, and Win2K OSs include well-known security principals that Windows adds to the access tokens of other well-known security principals based on the principal's logon type. These logon-type well-known security principals are Batch, Dialup, Interactive, Network, Service, and Terminal Server User. (Terminal Server User is for all users logged on using Terminal Services 4.0 application compatibility mode.)
Windows 2003 and XP SP2 add the Remote Interactive Logon wellknown security principal, which identifies users who log on using the Windows 2003 or XP versions of Terminal Services or a Remote Desktop connection. For more information about logon types, see "Logon Rights: The Heart of Windows Access Control," August 2005, InstantDoc ID 46870.
Windows 2003 also adds three authentication-type well-known security principals—NTLM Authentication, SChannel Authentication, and Digest Authentication. These wellknown security principals reflect the authentication protocol that a principal used to authenticate to Windows in the principal's access token. Note that Microsoft hasn't provided principals to represent Kerberos and basic authentication.
You can use both the logon-and authentication-type well-known security principals to gain a more granular level of control over authorization. These new well-known security principals let you give users different levels of access to a resource depending on the authentication protocol (e.g., NTLM, Digest, SSL) and logon type (i.e., from the console, using Terminal Services).
Self, Creator Owner, and Creator Group
Windows includes several hierarchical object structures (including AD, the registry, and the file system) that support permission inheritance. You define permissions on a parent object, then these permissions are automatically applied to its child objects. Windows provides the Self, Creator Owner, and Creator Group wellknown security principals that administer the permissions in these hierarchical structures.
Typically, you add all three of these well-known security principals to the ACL of a parent object, then the child objects inherit these principals in the following way:
- Child objects inherit permissions given to the Creator Owner on a parent object in such a way that the account that creates the child object is set as owner on the object and gets those specific permissions as explicit permissions on the child object. For example, if the AD administrator sets Write permission on certain user-object properties for the Creator Owner on an organizational unit (OU), when a user creates a new user object in that OU, that user gets Write permission on those user-object properties.
- The Creator Group functions similarly to Creator Owner, but instead of adding permissions to the child object for the Creator Owner, you grant or deny permissions to the Creator Group, which then adds permissions for the primary group of the object owner to the child object.
- Self acts as a placeholder for the object. Say, for example, an AD administrator adds permission to write the postalAddress user-object attribute for Self to the ACL of an OU. When you create a new user object called Jan in that OU, user Jan will have Write permissions for his postalAddress attribute (Jan will be allowed to maintain his proper postalAddress data in his AD user object). Note that the same Self permissions on another user object won't allow Jan to edit the other user's postalAddress, because that Self permission is unrelated to Jan's user account.
By default, Windows grants Self read permissions on the memberattribute of a group. This means that all members of a group can see who else belongs to the group. Because AD also grants Authenticated Users read access to a group's member list, Authenticated Users can see the same.
Powerful but Complex
You've seen the power of Windows well-known security principals and learned a bit about the complexity behind administering access to Windows resources. Seeing the wellknown security principals added in Windows 2003 and considering the growing importance of delegated and self-service administration, you can expect that Windows will provide even more well-known security principals in the future.
