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.
Prev. page
[1]
2
next page 
