How Windows Security Works

To understand how NTFS permissions control access to resources, you must understand the symphonic relationship of the various mechanisms involved with Windows security. When a security principal (i.e., user, group, computer, or service account) attempts to access a protected Windows resource (be it a file, folder, share, printer, or some other resource), it must prove to Windows that it has the necessary permissions to access the resource.

Access Control Phases

The process of a security principal (often called a subject in theory discussions) attempting to access a protected object is called access control. Regardless of the operating system, access control has four distinct phases:

• Identification

• Authentication

• Authorization

• Accounting/Auditing

Identification

Identification is the method a security principal uses to identify itself to an operating system. In Windows, this is done by the security principal submitting a unique name or value (in the case of smart cards or other security tokens). The submitted identity must be unique in the authentication database. In Windows, local security principal accounts are stored in a local database file called the Security Accounts Manager (SAM). Domain accounts are stored either in a SAM database on an NT domain controller or in the Active Directory database file (Ntds.dit) stored on Windows 2000 and later domain controllers. Each security principal in a Windows namespace must have a unique identity-unique friendly name, a unique GUID number, and a SID number (more on these numbers below). The key is that the security principal must be able to hand the authentication database a label or number that uniquely identifies it.

Creating identity labels takes more sophistication than just randomly making names. First, identity names should use a common naming convention. For users, it is often something like the user's first name initial followed by their last name. Many organizations use identity labels to represent the security principal's role or location (e.g., DallasAdmin, SouthVALegalPrintManager, etc.) As Chapter 2 shared, for security reasons, highly privileged identity names should not specifically identify the role the security principal fulfills in an enterprise. Lastly, identity labels should be documented and a centralized, secure process used for their issuance and removal.

Authentication

Once the security identity is handed over, the authentication database needs to prove that the submitting entity really "owns" the identity. To do that, the security principal must submit information that only the authentication database and it knows. Most often, this information is a password, but it could be a smart card, a security token, or biometric credentials. If the security principal successfully submits the expected confidential information proving ownership of its identity, the security principal is authenticated. We will cover the authentication process in detail in Chapter 4.

Authorization and Accounting

It's important to note that once the security principal's identity has been authenticated, the other access control mechanisms often can reliably take the identity's credentials without having to re-verify them. In practice, some authentication mechanisms do rely on the initial authentication and don't ever re-verify identity, and other access control schemes re-verify each access request. Thereafter, whenever the security principal wants to access an object, it submits its previously verified identity to the access control mechanism, along with its security credentials. The security credentials contain the permissions the security principal is given by the operating system. In Windows, the owner of the resource being accessed has previously assigned permissions to the appropriate security principals. In theory discussions of access control, this is known as the discretionary access control (or DAC) method.

The access control mechanism, called the security reference monitor, determines whether or not the security principal obtains access, and what type of access, to the requested object. If the security principal's request is successful, the request is authorized. Lastly, the request and its subsequent success or failure can be logged in a process called accounting or auditing. All Windows security principals must submit themselves to the process of access control, as shown in Figure 3-1.

Figure 3-1

The phases of access control listed previously are not unique to Windows. Most popular computer operating systems use a similar set of mechanisms. Now we can discuss each of the phases in more detail as it pertains to Windows.

GUIDs and SIDs

Although we humans track security principal accounts using their common or friendly name (e.g., Linda Smith), Windows tracks security principals using their permanently assigned Globally Unique Identifier (GUID) or Security Identifier (SID) numbers. Because of this, even when the security principal's name changes, the principal is still correctly tracked in Windows. If you rename a Windows security principal account, the new name will appear in most of the necessary dialog boxes and windows automatically.

GUIDs

Each Windows security principal and object has a unique 128-bit GUID number. GUIDs are assigned by the operating system to nearly every Windows object possible, including users, computers, groups, objects, programs, data elements, and programming components. Many programs referenced in the registry are identified by their GUID. Per Microsoft, the GUID should be unique to every Windows object in the universe. It is calculated using a formula involving the time, the date, network information, and a random routine that uses cycle frequencies from the computer's clock chip. An example GUID looks something like this:

Once you are aware of GUIDs, if you weren't before, you will notice them everywhere. They are all over the registry, identify specific programs, identify ActiveX controls, and can be used as data in databases. However, trying to find a user object's GUID can be difficult. Oftentimes, the GUID will be revealed when using a troubleshooting tool, but in order to specifically list a particular object's GUID takes special utilities or coding. You can use the Ldp.exe program or Adsiedit.msc console located at \Support\Tools\Support.cab on the Windows XP or Windows Server 2003 installation CD-ROM discs to query GUIDs stored in Active Directory.

Note 

GUIDs exist in many operating systems, not just Windows.

Figure 3-2 shows a user account's GUID (and SID) using the Adsiedit console tool. Unfortunately, GUIDs are stored in hexadecimal string form in Active Directory and must be converted to a string-formatted GUID to be read correctly. The Microsoft Knowledge Base article located at http://support.microsoft.com/default.aspx?scid=kb;en-us;325648 contains a VBS conversion script. Sometimes being able to convert a GUID to an object's name is helpful. For example, when searching in the registry for malware, you may come across an unfamiliar GUID. You can use Microsoft's Guid2obj tool (www.microsoft.com/windows2000/techinfo/reskit/tools/existing/guid2obj-o.asp) to do the conversion. Unfortunately, the Guid2obj tool works only on objects registered in Active Directory, not on objects registered locally.

Figure 3-2

For instance, on a user's workstation I found the following GUID being executed as an Explorer Shell (see Table 1-1 for more details):

 {} 

The Guid2obj tool could not convert the GUID to its common name. This meant the object wasn't registered in Active Directory. Then I used the Find feature in the Registry Editor tool (Regedit.exe) to search on the value. In a few seconds it found the value and its associated common name of Microsoft Antispyware in two registry locations, including registry key location HK_LM\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellExHooks. This is an expected behavior of the software as it tries to intercept malware.

Note 

Program GUIDs are also known as Class IDs or CLSIDs. CLSIDs are frequently found in the registry and in HTML coding (e.g., CLSIDs identity the ActiveX control being executed).

Overall, finding and locating GUIDs can be hard work. Fortunately, an object's SID is usually more important to security administrators and easier to get than the GUID. GUIDs were discussed here so you would know that most objects have both a GUID and a SID and that they are different, and because GUIDs can be important when tracking down objects in the registry.

SIDs

All security principals have one or more SIDs but not all objects. For example, printer objects don't have SIDs. In Windows, only security principals (i.e., users, groups, computers, and service accounts) have SIDs, and they are assigned when the object is first created. SIDs are variable-length numbers with one or more dashes separating different numeric values. SIDs are guaranteed to be unique only in the domain, unlike GUIDs, which are guaranteed to be unique in the universe. It is the SID that most administrators and security processes are most interested in.

Note 

If you delete and re-create a security principal, even if it has the same name, it will have a different SID.

An example SID is

 S-1-5-21-3333797343-2748683396-701768906-1111 

All SIDs begin with S-1- and then are followed by a sequence of numbers separated by dashes. The next number following the 1- is called the SID Top-Level Authority value. It is usually a number between 0 and 5.

For local account SIDs, the number will be 2. For domain security principals, it will be a 5 (in Windows 2000 and later domains and workgroups). After this value, the SID will be composed of one or more 32-bit fields separated by dashes. The middle values usually indicate the domain in which the security principal is located. The domain portion will be identical for all objects in the same domain. The last value is called the Relative Identifier (RID). The RID is generated at the time the object is created. Built-in security principals (e.g., Administrator, Everyone, Guests, etc.) have well-known RIDs that are identical for every similar security principal in every domain. Non-default security principals have RIDs starting with 1003, and the RID value is incremented for every security principal created. Most manually created security principals have RIDs beginning at 1100 and on up. A SID's format looks something like this:

 S-1-X-X-X-X-RID 

Because of the well-known SIDs and RIDs, it is possible to identify many security principals, no matter what they are named, based upon the SID or RID. Table 3-1 lists the well-known SIDs and RIDs. The values most important to security administrators are in bold. Each user and group is explained in more detail in Table 3-2.

Table 3-1

SID	Description
S-1-0	Null Authority
S-1-0-0	Nobody or Anonymous Null Session ID. Assigned when a security principal or its SID can't be identified or is non-existent.
S-1-1	World Authority
S-1-1-0	Everyone group
S-1-2	Local Authority
S-1-2-0	Local group
S-1-3	Creator Authority
S-1-3-0	Creator Owner group
S-1-3-1	Creator group.
S-1-3-2	Creator Owner Server, not used in Windows 2000 and later
S-1-3-3	Creator Group Server, not used in Windows 2000 and later
S-1-4	Non-unique Authority
S-1-5	NT Authority
S-1-5-1	Dialup group
S-1-5-2	Network group
S-1-5-3	Batch group
S-1-5-4	Interactive group
S-1-5-5-X-X	Logon session; X-X is a random unique number assigned to a particular logon session.
S-1-5-6	Service group
S-1-5-7	Anonymous Logon or null session
S-1-5-8	Proxy SID; not used in Windows 2000 and later
S-1-5-9	Enterprise Domain Controllers group
S-1-5-10	Self
S-1-5-11	Authenticated Users group
S-1-5-12	Restricted Code group
S-1-5-13	Terminal Server Users group
S-1-5-14	Remote Interactive Logon group
S-1-5-15	This Organization group
S-1-5-18	LocalSystem (or System) account
S-1-5-19	LocalService
S-1-5-20	NetworkService
S-1-5-21	Non-unique; SIDs are not unique
S-1-5-32	Built-in Domain
S-1-5-1000	Other Organization group
S-1-5-64-10	NTLM Authentication protocol
S-1-5-64-14	SChannel Authentication protocol
S-1-5-64-21	Digest Authentication protocol
S-1-5-x-x-x-500	Local or Domain Administrator
S-1-5-x-x-x-501	Local or Domain Guest
S-1-5-x-x-x-502	Krbtgt
S-1-5-x-x-x-512	Domain Admins
S-1-5-x-x-x-513	Domain Users group
S-1-5-x-x-x-514	Domain Guests group
S-1-5-x-x-x-515	Domain Computers group
S-1-5-x-x-x-516	Domain Controllers group
S-1-5-x-x-x-517	Cert Publishers group
S-1-5-x-x-x-518	Schema Admins group
S-1-5-x-x-x-519	Enterprise Admins group
S-1-5-x-x-x-520	Group Policy Creator Owners group
S-1-5-x-x-x-553	RAS and IAS Servers group
S-1-5-x-x-x-544	Administrators group
S-1-5-x-x-x-545	Users group
S-1-5-x-x-x-546	Guests group
S-1-5-x-x-x-547	Power Users group
S-1-5-x-x-x-548	Account Operators group
S-1-5-x-x-x-549	Server Operators group
S-1-5-x-x-x-550	Print Operators group
S-1-5-x-x-x-551	Backup Operators group
S-1-5-x-x-x-552	Replicator group
S-1-5-x-x-x-553	RAS Servers group
S-1-5-x-x-x-554	Pre-Windows 2000 Compatibility Access group
S-1-5-x-x-x-555	Remote Desktop Users group
S-1-5-x-x-x-556	Network Configuration Operators group
S-1-5-x-x-x-557	Incoming forest trust builders group
S-1-5-x-x-x-558	Performance monitor users group
S-1-5-x-x-x-559	Performance log users group
S-1-5-x-x-x-560	Windows Authorization Access group
S-1-5-x-x-x-561	Terminal Server License Servers group
S-1-5-x-x-x-562	Distributed COM Users group
S-1-6	Site Server Authority
S-1-7	Internet Site Authority
S-1-8	Exchange Authority
S-1-9	Resource Manager Authority
Where shown in Table 3-1, x-x-x represents the domain or workgroup SID.
Well-known SIDs were gathered from the author's own research and several published resources, including Microsoft documentation located at: www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prnc_sid_cids.asp, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/well_known_sids.asp, http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q243330, and Jan De Clercq's Windows Server 2003 Security Infrastructures (Elsevier Digital Press, 2004).

Table 3-2
Open table as spreadsheet

Domain Mode/Feature Server 2003	Mixed Mode (default)	Windows 2000 Native and Windows
Security groups supported	Local, Domain Local, Global	Local, Domain Local, Global, Universal
Distribution groups supported	Local, Domain Local, Global, Universal	Local, Domain Local, Global, Universal
Group nesting allowed	Global into Global, Global into Local or Domain Local	All types of nesting allowed except a Global group cannot contain a Universal group

Table 3-1 can be helpful when Windows displays the SID instead of the common name. For instance, I often see SID S-1-5-32-547 displayed when looking at NTFS permissions in the default security templates (covered in Chapter 14) on Windows Server 2003. Table 3-1 tells me this is the Power Users group, and the problem Windows Explorer is having is that Windows Server 2003 removes the Power Users group during a domain controller promotion.

Note 

The Power Users group is present in Windows Server 2003 non-domain controllers and in previous versions of Windows for backward compatibility, but it contains no members. Microsoft plans to remove the Power Users group in Windows Vista.

SID Viewing Tools

You can use several software utilities to view security principal SIDs, including the following:

• Whoami.exe

• Sid2user.exe and User2sid.exe

• Psgetsid.exe

There are a lot of Whoami program versions in the world, but the version that displays Windows SIDs is included in Windows XP Pro and Windows Server 2003 (the W2K3 version, which is more functional, can be copied and run on Windows XP Pro as well). If you type Whoami by itself, it returns only the currently logged in user's name preceded by their domain or workgroup name:

 Example\ScottLovell 

If you type Whoami /user, you'll get the current user's SID, looking something like this:

 Q:\WINDOWS\system32>whoami /user USER INFORMATION ---------------- User Name      SID ============== ============================================= example\scottlovell S-1-5-21-3334797343-2748683396-701868904-1111 

If you type Whoami /user /groups, you'll get a listing of the user and all the groups, and the related SIDs, to which the user belongs. For example:

 USER INFORMATION ---------------- User Name      SID ============== ============================================= example\mattlovell S-1-5-21-3334797343-2748683396-701868904-1114 GROUP INFORMATION ----------------- Group Name                         Type             SID              Attributes =================== ============================================================ Everyone                             Well-known group S-1-1-0                     Mandatory group, Enabled by default, Enabled group BUILTIN\Administrators               Alias            S-1-5-32-544                     Mandatory group, Enabled by default, Enabled group, Group owner BUILTIN\Users                        Alias            S-1-5-32-545                     Mandatory group, Enabled by default, Enabled group NT AUTHORITY\INTERACTIVE             Well-known group S-1-5-4                     Mandatory group, Enabled by default, Enabled group NT AUTHORITY\Authenticated Users     Well-known group S-1-5-11                     Mandatory group, Enabled by default, Enabled group LOCAL                                Well-known group S-1-2-0                     Mandatory group, Enabled by default, Enabled group EXAMPLE\Data                   Group            S-1-5-21-3334797343-274868 3396-701868904-1131 Mandatory group, Enabled by default, Enabled group EXAMPLE\Group Policy Creator Owners Group            S-1-5-21-3334797343-274868 3396-701868904-520  Mandatory group, Enabled by default, Enabled group EXAMPLE\Domain Admins               Group            S-1-5-21-3334797343-274868 3396-701868904-512  Mandatory group, Enabled by default, Enabled group EXAMPLE\Enterprise Admins           Group            S-1-5-21-3334797343-274868 3396-701868904-519  Mandatory group, Enabled by default, Enabled group 

Note 

The preceding examples are shown using the W2K3 version of Whoami. The XP version of Whoami uses the /all parameter to display the user's personal and group SIDs.

This is an excellent example of a user's SIDs. Pay special attention to the next few paragraphs because what they contain is essential to learning about Windows security. When a user logs on to a Windows computer, after the authentication is successful, the local machine or domain controller (if in a domain) queries for and gathers all the SIDs for the groups to which the user belongs. If the user is in a domain environment utilizing universal groups (i.e., groups available throughout the forest) the domain's global catalog is queried to return those groups as well. The domain controller queries itself for domain local and global groups (covered below).

The SIDs are collected together and become part of the security principal's security token. When the user wants to access an object, the Windows security reference monitor (SRM) asks for the user's security token, which is akin to asking the user what groups they belong to. In this example, the user belongs to the following groups: Everyone, Administrators, Users, Interactive, Authenticated Users, Local, Data, Group Policy Creator Owners, Domain Admins, and Enterprise Admins. This user has a lot of access. The user isn't the original Administrator account because his RID is 1114 and not 500. However, because he belongs to Administrators, Domain Admins, and Enterprise Admins groups, this user has almost as much access.

Note 

The original Administrator account is afforded a few other niceties that newly made administrators don't have. For example, on domain controllers, Windows will periodically (within a few hours) re-add the original Administrator back to any objects or resources to which their permissions were removed. Also, the original Administrator account cannot normally be locked out by Account lockouts (although you will learn how in Chapter 4).

This user will have every permission and privilege that is assigned to his listed groups, along with whatever is assigned to his individual user account. Note that the user belongs to many more groups than average administrators think they belong to. Besides the obvious groups manually assigned by an administrator, the user belongs to many built-in and action-oriented groups (covered below). It is the accumulation of permissions from all groups, assigned, built-in, and action-oriented, that gives the user his or her NTFS permissions. Often, when an administrator can't figure out why a particular user has different effective permissions than the administrator intended, look into each group the user belongs to, not just the obvious ones.

Viewing the current logged on user's SID is easy enough with Whoami, but it takes different tools to research a SID of a user who isn't the currently logged on user. Probably the most well-known SID query tools are Sid2user (which converts a given SID to the user, group, or computer account common name and User2SID (which converts a given security principal's common name to its SID). Programmer Evgenii B. Rudnyi wrote both utilities as companions to each other and they work well. For reasons unknown to me, he allows only the source code to be downloaded. To download it in compiled form to run in Windows, you can search any Internet search engine for Sid2user or download it from www.wrox.com.

You need to be an authenticated user in Windows XP or later to successfully run the utilities, and you need to run the utilities locally or have a NetBIOS connection already established to the computer. Prior to XP, you only needed to have a drive mapped by a null session user (no name, no password). This is still true of Windows 2000 and Windows Server 2003 domain controllers, a point hackers love to exploit. Here's an example of User2sid and Sid2user:

 Q:\>user2sid TonyaLovell S-1-5-21-3334797343-2748683396-701868904-1117 Number of subauthorities is 5 Domain is EXAMPLE Length of SID in memory is 28 bytes Type of SID is SidTypeUser Q:\>sid2user 5 21 3334797343 2748683396 701868904 500 Name is BillLovell Domain is EXAMPLE Type of SID is SidTypeUser 

Note that Sid2user has a slightly different SID format than you would expect. You must leave out the S-1- prefix and put spaces instead of dashes between the numeric values. The Sid2user outcome reveals a RID of 500, which means this user is the original Administrator account. This tactic, called SID enumeration, is often mentioned by security administrators as the primary reason for not renaming their highly privileged accounts. If the hacker has the appropriate access (an authenticated user on Windows XP and later or anonymous on a domain controller or Windows 2000 and earlier), he can use a SID enumeration tool and quickly find the highly privileged accounts. True, it's that easy. However, most hackers don't use SID enumeration, it isn't easy to do across the Internet (the hacker needs to map a drive or have access to the RPC or NetBIOS ports, which most firewalls block), and no automated malware I've ever seen does it. One day a hacker may build an automated tool that is incorporated into a worm or trojan to do SID enumeration (heck, Rudnyi's source code is widely posted on the Internet) but none do now. You can significantly increase your computer defenses by renaming your highly privileged accounts to something less notable.

You can also use Sysinternal's Psgetsid (www.sysinternals.com/Utilities/PsGetSid.html) utility. It works locally or remotely on Windows NT 4 and later. Although you still need NetBIOS access to the remote computer to run the utility remotely, you don't have to manually establish a drive mapping. Psgetsid will install itself as a service, using administrative credentials you must provide. It will return the user or computer's SID. I'm sure Microsoft probably has a few SID viewing tools in one of their Windows Resource Kits as well.

SIDHistory

Every security principal also has a field called SIDHistory. The SIDHistory field was originally created to allow smoother Windows upgrades and domain migrations. When a security principal is imported into another domain, its SIDs must change. Remember that most individual SIDs, as shown in Table 3-1, contain the security principal's domain in the SID. After a successful migration, the object's original SIDs can be moved to the SIDHistory field. During many security operations, the SIDHistory field can be checked, and the SIDHistory's SIDs used in security operations just as if the old SID were a current SID.

Hackers learned that they could programmatically add any SID they wanted to the SIDHistory field. There was never any authentication done or any validity checking mechanism enabled. Thus, the hackers could add highly privileged SIDs from the domain they were joining or becoming a part of through a Windows trust, and their new object would suddenly be elevated to the same status as the forged highly privileged account. Microsoft turned on SID filtering, in which the accepting domain filters out any SIDs in the SIDHistory field that claim to be part of the domain they are joining, in Windows Server 2000 Service Pack 2 and Windows Server 2003. It makes sense. Why would an object joining a domain already be a part of it? Unfortunately, the SIDs in the SIDHistory field also make up a part of a security principal's access token (covered below). You should make sure SIDHistory filtering is enabled in your environment, which it is by default.

Delegation and Impersonation

Two other poorly understood issues that impact Windows security are delegation and impersonation. Impersonation is another process acting on behalf of the user. In Windows, the security principal never accesses a resource or object directly. Instead, the program or process that the security principal used (e.g., Windows Explorer) impersonates the security principal (using the security principal's security token) to access the object. When a program or process impersonates a security principal, it means the process or program is operating in the security context of the end user. This is the way Windows works.

It can also lead to some strange security interactions. Over the years, Microsoft has had to deal with more than a few bugs because the impersonation process did not function correctly. In both examples that I can think of, it led to the end user having System-level access. In the first example, Microsoft Office 2003 had a bug whereby when the user went to open a file and got the normal File Open dialog box, it would enable the user to explore mapped drives and areas to which end users would not normally have access. The second example is still a problem currently (as this chapter is being written), whereby even when an end user has been purposefully prevented from modifying Internet Explorer's security settings (normally end users can modify IE's security settings, but this can be prevented using NTFS permissions, group policy, or the Internet Explorer Administration Kit [IEAK]), the user can access IE's security settings through the security settings feature of Microsoft Media Player. In both instances, the processes were impersonating the System account (as processes often do), instead of switching to impersonating the user.

Impersonation can be turned off and on per security principal account by setting the Impersonate client after authentication privilege in group policy or local computer policy. By default, service accounts and most Windows programs have this privilege. This privilege was introduced in Windows 2000 Service Pack 4 because of malicious use of impersonation. Occasionally, impersonation will need to be given to a program (e.g., a patch management program pushing out patches) if the service account it is using was not already allowed to impersonate.

Impersonation Levels

Actually, Windows 2000 and later has several impersonation levels, including the following:

• Anonymous

• Identify

• Impersonate

• Delegate

The levels reflect the authentication used between a security principal, a service, and the resource the service is accessing on behalf of the user. The first three impersonation levels allow a process to impersonate a user account for access to a local object; the last option deals with access to remote objects. We've already talked about the normal impersonation scenario in which the process impersonates the security principal using it. Anonymous impersonation means the process impersonates the anonymous user (i.e., the null session) and not the end user. The Identify level allows the process to access other local objects using the security principal's access control permissions, but it is not actually impersonating the security principal. In Identify mode, the service or process can identify the security principal to the SRM for the purpose of accessing the object, but the service or process does not "become" the security principal. The net effect is that the Identify level is more restrictive than the Impersonate level, and many access requests will fail. For that reason, most services and processes use the Impersonate level. Unfortunately, impersonation only works on local resources, not remote ones.

You can view impersonation on your system in real time using Sysinternal's TokenMon utility (www.sysinternals.com/Utilities/Tokenmon.html). It will reveal the processes using impersonation and what security principal accounts are being used (see Figure 3-3). If you use TokenMon, it will generate hundreds of entries in a few seconds. In this example, you can see the Microsoft Antispyware program (gcasDtServ.exe) impersonating the Banneret\Roger user account. You can also see that much of the impersonation is a process impersonating the System account. Every process in Windows manipulates objects in the security context of a security principal, although it is often the System account behind the scenes.

Figure 3-3

A service trying to use impersonation to access a remote resource will end up sending the anonymous credentials (i.e., unauthenticated) for the logon attempt, which will cause many failures. Delegation is the process of a service impersonating the security principal to a remote server or resource. Delegation requires Active Directory and domain accounts, and only works on Windows 2000 and later computers located in the same forest. When delegation is enabled, a server or service can send the security principal's credentials to log on to the remote service. The remote service thinks the logon is coming directly from the security principal. Delegation is a good thing and is required in order for several services to work with remote clients (EFS, IIS's Integrated Windows Authentication, etc.).

For example, suppose you have a front-end web server connected to a back-end SQL database that requires the user to use his normal Windows user account to access the data. This is a very common scenario. Without delegation, the front-end web server would not be able to pass the user's logon credentials to the back-end database. In most of these cases, programmers were stuck with creating a single "master account" that was used to interface between the front-end web server and the back-end database (see Figure 3-4). This approach has several weaknesses, not the least of which is a single point of failure and a lack of individual accountability. With delegation, you can mark any Windows 2000 or later computer or service as trusted for delegation. When delegation is allowed, the in-the-middle front-end web server can impersonate the user and pass along their logon credentials to the back-end database (refer to Figure 3-4). Windows KB article#262291 (http://support.microsoft.com/kb/q262291) covers the various levels. Prior to Windows 2000, "identify" and impersonate were the only supported impersonation levels.

Figure 3-4

Any other impersonation level besides Delegate will prevent the impersonating service from sending your network credentials to any remote service or server, even those marked trusted for delegation in Active Directory. Delegation can be enabled or disabled by user or computer. By default, user accounts can be used in delegation by any computer enabled for delegation. You can prevent an account from being delegated by opening the account in Active Directory Users and Computers and selecting the Account tab (see Figure 3-5). There you can enable the Account is sensitive and cannot be delegated option.

Figure 3-5

Computers (usually servers) can be enabled or disabled for using delegation by opening the computer account in Active Directory Users and Computers and choosing the Delegation tab (see Figure 3-6). There you can disable the computer's capability to use delegation (i.e., the Do not trust this computer for delegation option), enable any service on the computer to use delegation (i.e., the Trust this computer for delegation to any service (Kerberos only) option) or specify which services and protocols can use delegation (i.e., the Trust this computer for delegation to specified services only option). The latter option, known as constrained delegation, is new in Windows Server 2003 and does not exist in Windows 2000 domains. It allows you to selectively choose which remote servers and services (as identified by their service account's service principal name, or SPN) can be sent delegated credentials. You can also use the three other authentication protocols (i.e., LM, NTLM, and NTLMv2) instead of Kerberos, if so desired. In Windows 2000, when a computer is trusted for delegation, it can impersonate a user to any other service on any other computer in the domain. Constrained delegation allows an administrator to significantly minimize a hacker's attack space on a server with delegation.

Figure 3-6

Note 

In order for an application to use an authentication protocol other than Kerberos in delegation, the application must specially be written to use the other protocols. Most applications, including Internet Explorer, only allow Kerberos delegation.

Delegation is turned on by default for domain controllers but not member servers. Consider disabling delegation on highly privileged user and service accounts that do not require delegation. On Windows Server 2003 servers required to use delegation, enable constrained delegation.

Groups

All Windows security principals are members of one or more groups. These groups can be built-in to Windows or manually added by administrators. Windows built-in groups can be added or modified by the operating system as the need arises. For example, promoting a member server to a domain controller causes all the local groups to be converted to domain groups, all the local user and group accounts to be deleted, and two new local user accounts to be created (Directory Services Restore mode Administrator and Guest). Installing new features and software to a computer often adds new groups. For example, adding Microsoft Exchange, DNS, DHCP, WINS, and Certificate Services adds new groups that are required for the software to function correctly.

Note 

If you haven't noticed already, Windows groups usually have a name that ends with an "s" in order to make it easier to immediately identify whether the security principal you are viewing is a user account or group. For instance, there is an Administrators group and an Administrator user account.

Action-Based Groups

Some of the built-in Windows groups are very special in that membership changes based upon security principal actions and behaviors. For example, logging in to a computer using the local keyboard automatically makes the user a part of the Local group. Simply logging on and authenticating makes the user a member of the Everyone, Authenticated Users, Domain Users, This Organization, Interactive, and Users groups.

A security principal becomes a member of an action-based group simply because it or a process impersonating it did something. When the action is over, the security principal is moved out of the group. Other than stopping the action that places a security principal in a particular action-based group, there isn't any way to prevent a security principal from being in a particular group. It's in the group because of the action done. However, and this is important, you can still modify the permissions that an action-based group has to a particular resource. For example, an administrator can't stop a user account from being in the Everyone group. It was placed there simply by being created and logging on, but the permissions that the Everyone group gets to an object can be modified.

Here are the various action-based groups (see Table 3-3 for more detail on what each represents):

• Anonymous Logon

• Authenticated Users

• Batch

• Creator Owner

• Dialup

• Domain Computers

• Domain Controllers

• Domain Users

• Everyone

• Interactive

• Local

• Logon session X-X

• Network

• Other Organization

• Self

• This Organization

• Users

Table 3-3
Open table as spreadsheet

Account Name	Description
Administrator	Local or domain Administrator, depending on where found Local Administrator Has full access to all local resources and is a member of the local Administrators group, and cannot be removed Domain Administrator Domain administrator, usually has Full Control permissions to all domain resources. Can be renamed, but not deleted or disabled. Is a member of Administrators (cannot be removed), Domain Admins, Domain Users, and Group Policy Creator Owners groups by default. In the first domain in a new forest (i.e., the forest root domain), the Administrator is also a member of the Enterprise Admins and Schema Admins groups. This means the administrator of a forest root domain is significantly more powerful than other domain administrators in the same forest.
	In a domain, the Administrator account is created and its password set when you install Active Directory on the first domain controller. The first Administrator account in each domain is also a Data Recovery Agent (DRA) for EFS for that domain. Note: The local administrator account can be disabled in Windows XP and non-domain controller Windows Server 2003 servers. During a DCPromo, a server's local Administrator account is copied up to the domain and deleted in the local SAM.
Directory Services Restore Mode Administrator (named Administrator)	During a DCPromo, a server's local Administrator account is copied up to the domain and deleted in the local SAM. A new local Administrator account is created in the local SAM and is known as the Directory Services Restore Mode Administrator. It is named Administrator by default. Its password is set during the DCPromo. Account can only be used in Directory Services Restore mode. Account name and password is also used in Recovery Console operations This account is not replicated to other computers. Can change password using Netdom, Setpw.exe (in W2K, see KB article #239803), Ntdsutil (in W2K3), Dsrm, or Net Use.
Guest	Every computer has a local Guest account and every domain has a Guest account. Default account for guest logins. When used, will create a new local profile and remove the profile when the Guest user logs out. When used, does not need a password. Must be enabled for some legacy applications and functionality. If enabled, provides an avenue for malicious hackers to implement a privilege escalation attack. Disabled by default in Windows XP and later Local Guest account is a member of the Everyone and Guests groups, Domain Guest account is a member of Domain Guests and Domain User groups. Disabled by default. Can be renamed but not deleted.
HelpAssistant	Created when Remote Assistance is enabled and a remote assistance session is requested. Will be deleted if no remote assistance requests are pending. Has limited access to the desktop environment.
IUSR_<computername>	Not a default account, but added if Internet Information Server (IIS) is added. Used as the security principal account for all users connecting anonymously to an IIS web site. Member of the Domain Users and Guests groups by default, which can indirectly give more permissions than is necessary for the web site alone. In IIS, default anonymous account (IUSR_) can be changed to another security principal account.
IWAM_<computername>	Not a default account, but added if Internet Information Server (IIS) is added. This account is used for web sites running "out-of-process," which is used more often in previous versions of IIS. Member of the Domain Users and IIS_WPG groups.
Krbtgt	Kerberos-related account, appearing only on domain controllers. Disabled by default. Kerberos authentication is achieved by using tickets that are enciphered with a symmetric key that is derived from the password of the server or service to which access is requested. To request such a session ticket, a special ticket called the Ticket Granting Ticket (TGT) must be presented to the Kerberos service itself. The TGT is enciphered with a key derived from the password of the KRBTGT account, which is known only by the Kerberos service. Should not be deleted or modified.
Local Service	New security principal in XP, lesser-privilege account intended for use with service accounts. Account has same permissions given to the Users group. Accesses network services with anonymous credentials.
Network Service	New security principal in XP, lesser-privilege account intended for use with service accounts. Account has same permissions given to the Users group. Accesses network services with the same credentials given to its local machine account.
Support_<number>	Microsoft vendor support account. Disabled by default, it is part of the HelpServicesGroup group. It is intended as a default account for remote support through the Help and Support center.
System (also known as Local System)	Highest privilege account on the local computer — even more powerful than the administrator. Most of the operating system and kernel-mode applications run with the privileges of this security principal. Any Windows service running within the System context probably needs to stay that way, but each non-Windows service should be strictly evaluated before assigning it the Local System account. If a hacker gains control or buffer overflows a service running in the System context, they are all-powerful on the computer.
	Any process with the System SID is also made a member of the local Administrators group. When a system process accesses a network resource, it also picks up any SIDs belonging to the local computer account (e.g., Domain Computers and Authenticated Users)

Administrators need to pay special attention to these action-oriented groups because they are often the cause for incorrect permissions being applied. Unless you are aware of all the action-based groups that might be appended to a security principal's security token, you might be stumped in a permissions problem.

Group Types and Scopes

There are two types of groups: security and distribution. Security groups are a traditional type of group most Windows administrators think about. You put security principal members inside of a group and apply security permissions to the group. All the members in the group inherit the permissions given to the group. Distribution groups are list groups. They can contain members but cannot have security permissions attached to them. The most common distribution group is the Global Address List (GAL) installed by Microsoft Exchange server. In Active Directory native-mode and higher, you can switch group types back and forth. However, if you switch a security group to a distribution group, it loses all its attached permissions permanently (unless re-applied by the administrator). There are no default distribution groups in Windows.

Groups have scopes that determine what types of members they can contain and what types of groups they can be members of. The Active Directory domain level has an impact on group scopes as well. A domain in mixed-mode can only have Local, Domain Local, and Global groups. A native-mode or higher domain mode level allows an additional security group called Universal.

Note 

In Active Directory mixed-mode, you can have a Universal distribution group.

Local groups are managed using the Local Users and Groups console and are used to give permissions to local resources. Local group information is stored only on the local computer's SAM database, but each local group can contain members from the local computer, any domain, and any group within a reachable domain.

Domain Local groups are just like regular local groups, except they reside in domains and can be managed by the Active Directory Users and Computer console. Global groups exist in domains, and can contain any security principal in the current domain, or any group from any domain in the forest. For this reason, global groups are often thought of as domainwide groups. Universal groups were introduced with Active Directory in Windows 2000 and are considered a forestwide group. They can contain members from any domain in the forest and can contain any of the other types of groups. Universal groups and their memberships are stored on domain controllers hosting the global catalog function.

Groups can often be placed inside other groups, depending on the domain-mode, and this is called group nesting. In mixed mode, global groups can be members of other global groups, local groups, and domain local groups. In native mode and above, local, global, and universal groups can also be members of universal groups. The only group nesting not allowed in native and above mode is a universal group being a member of a local group (but a local group can be a member of a universal group). Table 3-2 summarizes this.

When a security principal logs on to their computer, the local computer, the domain controller, and the global catalog are all queried to provide a complete list of groups to which the user belongs in order to create the security token.

AGULP Method

With all these group scopes, you might wonder how to appropriately set NTFS permissions. Glad you asked. Since the introduction of Windows NT, Microsoft has been teaching and promoting a method called AGLP, or now with the introduction of Universal groups, AGULP. It is taught to every beginning Windows administrator. They learn it, test on it, and then forget it, which is sad, because it is the way security permissions should be set in Windows. Or let me be stronger: If you or your administrator is not setting security permissions this way, then you are doing it wrong. The AGULP method is the right way to set security permissions, the most efficient way to set permissions (is speeds up Active Directory replication and the SRM), and is probably the only way an organization can keep track of its permissions. The most secure organizations in the world use the AGULP method. Conversely, organizations not using it probably really don't understand what their permissions are, and hackers and penetration testers like organizations with a poor understanding of their security permissions.

The AGULP method says that whenever you are setting up security permissions to a resource (e.g., file, folder, share, printer, etc.), you should assign permissions like this:

1. Create a local (or domain local if you have a domain) group for that resource.

2. Assign the security permissions from the object to the local (or domain local) group.

3. Create a global group and add to it all the security principals desiring access to the resource as members.

4. Place the global group in the local (or domain local) group as a member.

Optionally, in a multi-domain environment, you can put the global groups into a universal group, and the universal group into the local (or domain local) group.

This is where the AGULP acronym comes from: security principal Accounts go into Global groups, which go into either Universal or (Domain) Local groups. The (Domain) Local group has all the Permissions to the local resource (see Figure 3-7).

Figure 3-7

The efficiency of this design is that all the assigned permissions are always assigned to the (domain) local groups. When auditing a network, an administrator doesn't have to query every group type in the domain and figure out which group trumps the other group. Allowing security permissions to be set on each of the group scopes is a management nightmare. The mess is sure to lead to a security hole that a hacker can exploit. If the AGULP method is used, then an audit can query just the one set of groups and find out all the security permissions in a domain.

Some administrators will call the AGULP method crazy and cumbersome, worsened by the fact that you need a separate (domain) local, universal (if needed), and global group for each type of permission you need to give. For instance, if you want to give some users Full Control-Allow permissions and another set of users just Read and Write permissions, you'll need two sets of AGULP groups. In my experience, once administrators get used to the AGULP method, it takes an extra two minutes longer than most organizations' random permission assigning method. Some administrators say it takes too long to set up and is too confusing. I say, if you don't follow the AGULP method, you aren't setting up permission correctly and you are building in a security exploit disaster! Not using AGULP makes your security infrastructure too complex to manage, so you won't really be managing it. Is the AGULP method adding too much time to your security infrastructure or saving you time by letting you manage it effectively for the first time?

If you don't use the AGULP method now, stop all your other security projects, take a "stand down" week, and get your security house in order. Getting your NTFS permissions correctly defined and managed is one of the most significant security benefits you can make to any environment. While other organizations are spending money on advanced security products that often don't work, you can get more bang for the buck by refocusing on the basics.

Built-in Users and Groups

Like well-known SIDs and RIDs, Windows comes with dozens of built-in users and groups. Understanding what each does and what permissions and privileges each has is key to understanding Windows security. Table 3-3 lists all the built-in Windows users, and Table 3-4 lists all the built-in groups. Review all of them, but pay the most attention to (read the details about) the underlined users and groups.

Table 3-4
Open table as spreadsheet

Group Name	Type	Description
Account Operators	Domain Local	Relatively powerful group that mimics a lower-privilege administrator Exists only on domain controllers No default members. Members can view and manage user, group, and computer accounts (except for objects in the Domain Controllers and Built-in containers). Can view, but not modify, high-privilege accounts. Cannot change group member-ship of highly privileged built-in groups. Can logon locally to domain controllers (which normal users cannot do).
Administrators	Domain Local or Local	Members have Full Control of local server(s)/domain controller(s) in the domain and any related security principal accounts The Administrator and System accounts are the only default members (you can't see the System account usually). This membership cannot be changed. Any object created by a member of this group is owned by the group, not the member. When a computer joins a domain, the Domain Admins group is added as a member of the local Administrators group. When a server becomes a domain controller, the Enterprise Admins group is also added. These memberships can be changed.
Anonymous Logon (also known as the Anonymous session, null session, etc.)	Action-based	Security principals connecting anonymously (they access resources over a network connection by using a null user account name, domain, and password) are added as members to this group. Resources must specifically allow the Anonymous security identifier (SID) allowed in order for anonymous users or connections to access. Anonymous users are important to the operation of Windows, and if completely disallowed would cause service disruptions. In Windows Server 2003 and XP, the Every-one group does not contain this group as a member. In previous versions of Windows, anonymous users could access the same resources as the Everyone group, which caused potential security issues. Note: The Anonymous Logon security group is not related to the IIS anonymous user account.
Authenticated Users	Action-based	Includes all currently logged on users (interactive or network) who have authenticated with a logon name and password. Does not include the guest account, or in XP and later, the anonymous user account. The Authenticated Users group is a member of the Users group. The Authenticated Users group should be preferred over the Everyone group when assigning new permissions unless unauthenticated access is desired. Authenticated users from other trusted domains or forests are also placed in this group.
Backup Operators	Domain Local or Local	Members can back up and restore files regardless of other security permissions. They can also log on locally to domain controllers and shut down computers. Has no default members Administrators also have the same restore and backup rights without belonging to this group. Tape backup service accounts should belong to this group instead of belonging to the Administrators group, if possible.
Batch		Includes all security principals logged on to the computer through a Windows batch queue facility (e.g., Task Scheduler). The security principal must have Logon as batch job privilege.
Cert Publishers	Domain Local	Members of this group are allowed to publish user and computer digital certificates to Active Directory. Usually contains computer accounts. Computers with Microsoft Certificate Services installed in Enterprise mode are automatically added to this account in their own domain, but may need to be added to other domains' or forests' Cert Publishers group if Certificate Services is to publish certificates to areas outside its home domain. No default members until Certificate Services is installed.
CERTSVC_DCOM_ACCESS	Domain Local	Installed with enterprise Microsoft Certificate Services. Default members are Domain Users and Domain Computers.
Creator	Action-based	This is a placeholder group that is replaced with the owner's primary group after the creation operation is complete.
Creator Owner	Action-based	This is a placeholder group that is replaced with the owner's account (not always the same as the creator's) after the creation operation is complete. This group is getting its own Access Control Entry (ACE) in NTFS DACLS permissions in Windows Vista (more on this below).
DHCP Administrators	Domain Local	Installed with Microsoft DHCP service, contains no default members. Members can configure DHCP using the GUI or the Netsh command, but cannot perform other administrative tasks on the server.
DHCP Users	Domain Local	Installed with Microsoft DHCP service, members of this group have read-only access to the DHCP service. No default members.
Dialup	Action-based	Includes all security principals logged onto the computer by means of a dial-up connection
Distributed COM Users	Domain Local or Local	Members can execute DCOM applications on the local computer No default members
DNS Admins	Domain Local	Only available, by default, in domains or forests using Microsoft DNS. Members of this group have Full Control of all zones and zone records in the domains in which they contain members. No default members.
DnsUpdateProxy	Global	Members are allowed to perform DNS dynamic update on behalf of other clients. Normally only used if Microsoft DHCP servers are installed in a domain. By default, DHCP clients have their DNS records registered by DHCP, which then becomes the owner. If the DHCP server goes down, the client may have trouble updating its own DNS host records. By placing the DHCP computer accounts in this group, client host records are not secured and can be updated by other computers. Has no members by default.
Domain Admins	Global	Members are domain administrators, with Full Control to all domain resources. The Domain Admins group is the default owner of all domain objects created by any member of the group. The domain Administrator is a default member of this group. This group is a member of the local Administrators group on all domain computers.
Domain Computers	Global	Group contains all computer accounts of computers joined to the domain, except domain controllers. Allows a computer to create a secure channel between itself and another computer for privileged communications (but communications are not encrypted by the channel itself).
Domain Controllers	Global	Group contains the computer accounts of domain controllers joined to the domain.
Domain Guests	Global	Any member it contains has Guest privileges. Contains only one member by default, the domain Guest account. A member of the Guests group.
Domain Users	Global	Group contains all user accounts created in the domain. Permissions given to this group are extended to all users in the same domain. Most new and built-in user accounts are part of this group, including Administrator, krbtgt, Support_#, and the IIS default user accounts. In Windows Server 2003, Everyone and anonymous are not part of this group.
Enterprise Admins	Universal in native mode domains, Global in mixed-mode domains	Members of this group have Full Control permissions to all resources in the forest. Can make forest changes, such as adding, deleting, and modifying domains, configuring sites, authorizing DHCP servers, and installing enterprise Certificate Authorities. By default, Administrator of first domain in the forest (i.e., forest root domain) is a member of this group. This group only exists in the forest root domain. By default, this group is a member of the Domain Admins group of all domains in the forest.
Enterprise Domain Controllers	Universal accounts in the forest	Includes all domain controller computer
Everyone	Action-based	This group includes all authenticated users and computers plus the members of the Guests group, (but not the anonymous null session by default in XP and 2003).
Exchange Domain Servers	Global	Added with Microsoft Exchange, only Exchange domain servers need to be added.
Exchange Enterprise Servers	Domain Local	Added with Microsoft Exchange, only Exchange enterprise servers need to be added.
Group Policy Creator Owners	Global	Members can create and modify group policy objects. By default, Administrator of first domain in the forest (i.e., forest root domain) is the only member of this group. This group only exists in the forest root domain. Objects created by members of this group are owned by the member.
Guests	Domain Local or Local	Members have the same permissions and access as members of the Users group (although the Guest account is further restricted). Members of this group will have a temporary profile created during logon, deleted during logoff. Default members are Guest and IIS anonymous user accounts, IUSR_computername, and IWAM_computername (if IIS is installed). When a server becomes a domain controller, the Domain Guests group becomes a member of Guests local group.
HelpServicesGroup	Domain Local or Local	This group allows administrators to set rights common to all support applications. The Support_# user account and any Remote Assistance user will be added to this group.
IIS_WPG	Domain Local	New group in IIS 6.0 used for worker processes. Members of this group usually serve as identities for specific namespaces and/or application pools. Application pool identities should belong to this group. The only default member is IWAM_<computername>, and this is only true if IIS is installed.
Incoming Forest Trust Builders	Domain Local	Members of this group can create one-way forest trusts to the forest root domain. No default members.
Interactive	Action-based	Includes all security principals logged on to the computer directly at the keyboard (i.e., local), using a Remote Desktop connection, or using a remote shell such as Telnet.
Local	Action-based	Includes all security principals logged on locally at the keyboard. Mutually exclusive from the Network group.
Logon session X-X	Action-based	X-X is a random unique number assigned to a particular logon session. Can be used to identify a particular logon session.
Network	Action-based	Members include anyone accessing the computer over a network connection (except Terminal Server users). Mutually exclusive of local, interactive, or dial-up groups.
Network Configuration Operators	Domain Local or Local	Members of this group can make changes to the network configuration settings (most often TCP/IP) and renew and release DHCP lease settings. No default members. Author had problems with this group during testing. It would not allow non-admin members to modify network settings correctly.
Other Organization	Action-based	Added to all users accessing a computer resource from another forest's domain across a forest selective trust. New in Windows Server 2003, mutually exclusive of the This Organization group.
Performance Log Users	Domain Local or Local	Members of this group can manage and create performance counters, alerts, and logs, without being members of the Administrators group. No default members.
Performance Monitor Users	Domain Local or Local	Members of this group can view performance counters, alerts, and logs, without being members of the Administrators group. No default members.
Power Users	Local	Members of this group can install software, create security principal accounts, and modify and delete the accounts they have created. They can create local groups and then add or remove users from the local groups they have created. They can also add or remove users from the Power Users, Users, and Guests groups. Members can create shared resources and administer the shared resources they have created. They can start, but not stop, services. They cannot take ownership of files, back up or restore directories, load or unload device drivers, or manage security and auditing logs. No default members, unless the computer was upgraded from Windows NT 4.0, in which case it will contain the Interactive group. Does not exist on domain controllers and is being discontinued in Longhorn
Pre-Windows 2000	Domain Local	Members of this group have Read access to Compatible Access user and group objects in Active Directory. Exists only on Windows 2000 and later domain controllers By default, either the Authenticated Users or the Everyone group is a member, and is determined during a domain controller promotion (dcpromo.exe). If Permissions compatible with pre-Windows 2000 servers is selected, the Everyone group is added; otherwise, the Authenticated Users group is added. Essentially, the former selection can allow anonymous session connections (i.e., the null session) and read domain information. Provided for backward compatibility with legacy systems. You may need to add users and computers to this group if they are running legacy systems. Domain Controllers and Exchange Enterprise Servers groups may be added as members by Active Directory.
Print Operators	Domain Local or Local	Members of this group can create, manage, and share printers, plus log on locally to domain controllers and load and unload device drivers. There are no default members.
RAS Servers	Domain Local or Local	Used for backward compatibility with NT 4.0 RAS servers
RAS and IAS Servers	Domain Local	Members of this group, usually server computer accounts, can read Account Restrictions, Remote Access Information, and Logon Information of user accounts. No default members. Pre-Windows 2000 RRAS and IAS server computer accounts should be added.
Remote Desktop Users	Domain Local or Local	Members of this group are granted the right to log on remotely. Does not exist in Windows 2000 or before No default members, and administrators do not have to belong. Equivalent to Terminal Server Users group on prior Windows versions
Remote Interactive Logon	Action-based	Includes all security principals logged on to the computer using a Remote Desktop session (Remote Assistance, Remote Desktop, Terminal Services, etc.). This group was added in Windows XP and later. Security principals in this group will automatically be members of the Interactive group, too.
Replicator	Domain Local or Local	Only used in NT 4.0 replication with File Replication Service. Usually should not be modified. Default member is domain user account used to log on to Replicator services on domain controllers.
Restricted Code	Action-based	Used by any process executed in a restricted security context. Can be used by users using RunAs. When added to a user's security token, it significantly limits what a program running in that user's context can do to the local system (see below for more details). Longhorn will use this SID more.
Schema Admins	Universal in native mode domains, Global in mixed-mode domains	Members are potentially the most powerful account in the forest, even more powerful than Enterprise Administrators. Can modify Active Directory schema. By default, only Administrator of first domain in the forest (i.e., forest root domain) is a member of this group. This group only exists in the forest root domain.
Self	Action-based	A placeholder group during security operations. Can represent the security principal requesting the access or the security principal being impersonated by an object.
Server Operators	Domain Local	Relatively powerful group that mimics a lower-privilege administrator. Members of this group can log on interactively, access administrative shares, create, delete, and manage resources, manage services, backup and restore files, change system time, manage disks and volumes, format the hard disk, and shut down the computer Exist only on domain controllers No default members
Service	Local	Contains all logged on accounts with the Logon as Service privilege. All service accounts must have this SID in order for the service to be started by the security configuration manager (scm) utility, as all services are.
TelnetClients	Domain Local or Local	Allows non-administrative members to log on to Telnet Server services
Terminal Server License Servers	Domain Local	Contains computer accounts of server(s) running Terminal Server License service
Terminal Server Users	Action-oriented	Includes all security principals logged on to the computer using a Terminal Services session In Terminal Services version 4.0 application compatibility mode (used for running Windows programs needing pre-Windows 2000 compatibility permissions).
This Organization		New to Windows Server 2003, identifies users who access resources locally within a trusting forest or across a trust that is not marked for selective authentication. New in Windows Server 2003, mutually exclusive of the Other Organization group.
Users	Domain Local or Local	Any user account created in the work group or domain becomes a member of this group. By default, Authenticated Users and the Interactive groups are members. Can perform common user tasks such as running previously installed applications and using local and network resources. Users can install applications only if the application supports per-user installation (which isn't common) and doesn't modify Windows system folders and registry locations. Initially the only member is the Authenticated Users group, but when a computer joins a domain, the Domain Users group is added to the local Users group on the computer.
Windows Authorization Access Group	Domain Local	Members can access the computed token GroupsGlobalAndUniversal attribute on User objects. This is necessary for some applications. Without this group, members would have to be added to the Pre-Windows 2000 Compatibility group. See Microsoft KB Article #331951 (http://support.microsoft.com/default.aspx?scid=kb;en-us;331951) for more details.
		Only exists on Windows 2003 and later domain controllers Only default member is the Enterprise Domain Controllers group
WINS Users	Domain Local	Only added when the WINS service is installed for the first time. Members have read-only access to WINS service.
WSUS Administrators	Domain Local	Only added when Windows Software Update Services (WSUS or WUS) is added for the first time. Members can administrate WUS servers.

You can see the groups you belong to using Windows Server 2003's Whoami.exe or Gpresult.exe. I prefer Gpresult for several reasons. First, although it doesn't show you the SIDs, its overall output is significantly more informative. Second, it will show you what groups your computer belongs to. Most administrators never consider the groups their computer belongs to.

Everyone Group and the Anonymous SID

In Windows XP and Windows Server 2003, the Everyone group does not contain the Anonymous SID (as it did in Windows 2000 and NT). Practically, this means that only objects that have explicitly allowed anonymous access can be accessed by the anonymous (i.e., null session) user. This change makes Windows significantly harder to hack. In previous Windows versions, anyone connecting as an anonymous user could access any resource to which the Everyone group had access. Hackers loved this because administrators often assign the Everyone group a wide range of rights and object permissions.

Anonymous users, if allowed, still contain the Anonymous Logon SID and their network logon type SID (usually Network). This means an anonymous user still has access to objects that explicitly allow the Anonymous Logon and Network SID. The Network SID is an action-based group and doesn't generally have a lot of default access alone. It was created so programs and processes could determine whether the connecting security principal was Local or Network, and make different security decisions based on the findings.

In Windows Server 2003 domains, there is a group called the Pre-Windows 2000 Compatibility Access group. When creating a new domain, the administrator running Dcpromo.exe is prompted whether to include the Everyone and Anonymous Logon groups to the Pre-Windows 2000 Compatibility Access group. The default is to add the Authenticated Users and the domain controller to the group. If you need backward compatibility with pre-Windows 2000 machines, consider adding the Anonymous Logon group back into the Pre-Windows 2000 Compatibility Access group. You can also enable the group policy setting Let Everyone permissions apply to anonymous users to accomplish the same task. But do either with caution because doing so significantly weakens a Windows computer. As noted above, domain controllers are automatically added to the Pre-Windows 2000 Compatibility Access group, which means anonymous users can connect to most domain controllers. Even though this weakens the domain controller, anonymous connections must be allowed to a domain controller in order for it to do its normal duties. Allowing an anonymous connection is how security principals can connect in the first place to become authenticated users.

Restricted Code

This is a newly added well-known SID that when added to any user's security token significantly limits what access a program running in the user's security context can do to the local system. It is used by programs such as RunAs. For example, if a user chooses Protect my computer and data from unauthorized program activity when executing RunAs.exe, instead of running as another user, the Restricted group SID will be added to the user's security token. The Restricted token removes all current privileges the user might have except Bypass Traverse Checking, removes write access to the registry, removes privileged group memberships (i.e., Administrators, Power Users), and removes all access to the user's profile (e.g., cookies, Temporary Internet Files, etc.). This is done to prevent malicious unauthorized manipulation of the local system. This SID would be good to add to any Internet Explorer browsing sessions. Windows Vista will use this SID to do exactly just that. Even when logged in users have administrative privileges, when they execute normal programs, such as Internet Explorer or Outlook Express, those programs will run in the Restricted security context. See http://blogs.msdn.com/aaron_margosis/archive/2004/09/10/227727.aspx for more details.

Creator Owner

The Creator Owner group isn't a real group. It is a placeholder account. When a security principal with permissions to create an object does so, they become the object's creator owner. The Creator Owner group is used by Windows when the object creation is started and is replaced by the real user or group when the creation action is finished. The Creator Owner has Full Control permissions (subfolders and files only) to most folders. This means that if a security principal can create an object, file, or folder, it has Full Control to it. Creator Owners can fully manipulate the object, including changing permissions. Windows tracks Creator Owners for a variety of reasons, including security and disk quota management.

There are two small caveats to remember. First, oftentimes when a user is the Creator Owner of an object, the object is owned by a group instead. For instance, by default, when any member of the Administrator's group creates an object, it is owned by the Administrators group, not the specific administrator who created the object. You can change this behavior using group policy. Second, although a user may not have elevated permissions to a particular area or folder, the Creator Owner often does have access. If the security principal can create an object, it will end up with Full Control permissions to a place it otherwise didn't have elevated permissions. In most instances, the user will not be able to create the object in the first place, but I have seen some deviations to the normal treatment (an example is covered below). Just be aware of the Creator Owner's default permissions.

Note 

If the Creator Owner group displays in the Security Settings dialog box but doesn't appear to have any permissions, more than likely it has permissions to folders and files inside the current folder.

The Creator Owner account will get its own DACLS access control entry (ACE) NTFS security permission in Windows Vista. This means that NTFS security permissions can be predefined on a folder or container and when an owner creates something, the new permissions can easily be predefined and viewed in Windows Explorer. The Creator Owner ACE will show up right next to the normal NTFS permissions, like Read & Execute.

The Creator Group is a related but different group from the Creator Owner. When rights are given to the Creator Group, when something is created by the user, permissions flow to the user's primary group, not to the user's individual accounts. This is the technique that allows any object created by an administrator to belong to the Administrator's group, instead of the individual administrator, thus preventing orphaned objects if the individual administrator is removed as a user account. Another related SID is Self. It acts as a placeholder so that permissions can be assigned to the parent of a newly created child object, before the parent is even defined.

Computer Accounts

Whenever a computer joins a domain, Active Directory creates a computer account (often called the machine account) for it. When the computer is turned on or reboots, the computer account logs on to the domain and goes through the same four access control phases listed at the beginning of this chapter. The computer account is named after your computer's name (it will have a $ at the end of the name in some utilities) and the password is set by the domain controller. The domain controller changes the password periodically, but you can force a password change using the Netdom.exe utility. There are two group policy settings that control computer account password changes, covered in Chapter 14.

Note 

Interestingly, if the computer and domain controller don't agree on the current password, then both will retry the authentication using the previous password.

If the computer and domain controller ever lose password synchronization, an administrator will need to reset the computer account in Active Directory Users and Computers. Then when you reboot the problematic machine, it should re-sync with the domain controller.

When a computer logs on, it creates a secure channel, as Microsoft calls it, between the computer and the domain controller. This secure channel is then used to allow the other security principals (i.e., user, group, and service accounts) a more secure network communications link for their authentication traffic. Computer accounts are often involved in Active Directory events, and its membership can significantly impact the security of your network. For instance, most security settings in Active Directory are applied to computer accounts, not user accounts. Understanding what groups your computer belongs to is essential to understanding Windows security. I used Gpresult.exe to give me a listing of groups my computer belongs to:

 The computer is a part of the following security groups: --------------------------------------------------------     BUILTIN\Administrators     Everyone     BUILTIN\Users     NT AUTHORITY\NETWORK     NT AUTHORITY\Authenticated Users     EXAMPLE_56978$     Domain Computers 

The results are common. In the typical domain environment, domain computers belong to the following groups:

• Everyone

• Users

• Network

• Authenticated Users

• Domain Computers

• Its own machine account (noted by the trailing $)

In this particular case, the computer was also a member of the Administrators group because the logged on user belonged to the Administrators group. Surprising to most students is the fact that domain computers belong to the Everyone, Users, and Authenticated Users groups as well. Besides the fact that if a hacker did compromise a machine account he would have a lot of access to a domain, the computer's "strange" group memberships allow most group policies (attached or inherited into an OU or container the computer is in) to apply to it by default. I suspect that if the group membership behavior wasn't as it is defined, many administrators would be wondering why their group policy objects were not applying. But since the Authenticated Users group has Apply Group Policy permissions, any computer-based group policy (appropriately placed) usually applies automatically to the computer hit by it.

Note 

Computer accounts are not created, or needed, until a computer joins a domain.

Domain controller computer accounts normally belong to the following groups:

• Administrators

• Everyone

• Pre-Windows 2000 Compatibility Access

• Windows Authorization Access Group

• Authenticated Users

• This Organization

• Computername$

• Domain Controllers

• Enterprise Domain Controllers (not always present)

You can see that the computer accounts (which most administrators don't even know exist) have a lot of security permissions and access. Thankfully, they are usually well protected and the passwords changed frequently and automatically by the domain controller.

Windows Trusts

In a multi-domain environment, Windows trusts also come into play. By default, all domains in a Windows 2000 and later forest have bidirectional, transitive trust to all other domains in the forest. In Windows 2003, in Windows 2003 forest functional level, you can also set up domain-to-domain trusts between forests. Other types of trusts and trust behaviors (e.g., nontransitive, external, etc.) are beyond the scope of this discussion, but two main questions need to be asked and answered:

1. What does a Windows trust really mean?

2. What permissions does a Windows trust give the trusted domain?

Note 

Remember that a trusted domain is the one being trusted by the resource domain. A trusted domain usually has the security principals wanting access to the trusting domain's resources.

On the first question, a Windows trust means that the trusting domain's SRM will trust the identity credentials and access token sent to it by the trusted domain. Effectively, the trusting domain is telling the trusted domain that it trusts the trusted domain controllers to do their identification and authentication phases so that when a security principal tries to access a resource in the trusting domain, the trusting domain's SRM will not redo the authentication. Conversely, if a Windows trust has not been set up between two domains, then the resource domain will ask the user domain security principal to authenticate again.

On the second question, people often hear that a Windows trust gives either no permissions or all permissions to the resources in the trusting domain. Here's the truth: The users in the trusted domain get the following group memberships in the trusting domain:

• Everyone

• Authenticated Users

• Users

• Interactive

• This Organization (unless from another forest using a selective trust)

Most obvious is that all users in the trusted domain immediately get access and permissions to whatever the Everyone and Authenticated Users group in the trusting domain has. In most domains, that's a lot of trust that just got transmitted. Be aware of this fact the next time you create a new Windows trust. Creating a new Windows trust is giving away a lot of trust!

Security Token

Now that you've got a better understanding of all the groups involved, we can focus our attention on the security token. As discussed before, after a security principal successfully logs on to a computer, the user and their group SIDs are collected for the security token (also known as an access token or security access token). The security token contains the following information:

• Security principal's account SID

• SIDs for groups to which the security principal belongs

• SIDs from the security principal's SIDHistory field

• A logon SID that identifies the current logon session (see Table 3-1)

• A list of the privileges held by either the user or the user's groups (covered in Chapter 14)

• An owner SID, which indicates what account or group becomes the owner of any object created by the security principal

• The SID for the primary group (used only in POSIX subsystems and indicated on the Users account information).

• A list of privileges given to the security principal and their status (i.e., enabled or disabled)

• The default NTFS permissions that the system uses when the user creates a securable object without specifying security permissions. The default permissions usually are the Creator Owner and System account having Full Control-Allow permissions.

• The source of the access token (i.e., Session Manager, LAN Manager, or Remote Procedure Call (RPC) server)

• Whether the token is a primary or impersonation token

• Current impersonation level (as discussed above)

• Session ID, indicating whether the access token is associated with a Terminal Services client session

• An optional list of restricting SIDs

• Other statistics

Every process working on behalf of the security principal (i.e., impersonation) has a copy of the security principal's access token. You can get a partial print out of a user's access token by using the Whoami/all command (the Windows Server 2003 version) on Windows XP and later. Here's example output:

 [User]    = "EXAMPLE\ErinLovell" S-1-5-21-3334797343-2748683396-701868904-1112 [Group 1] = "EXAMPLE\Domain Users" S-1-5-21-3334797343-2748683396-701868906-513 [Group 2] = "Everyone" S-1-1-0 [Group 3] = "BUILTIN\Administrators" S-1-5-32-544 [Group 4] = "BUILTIN\Users" S-1-5-32-545 [Group 5] = "NT AUTHORITY\INTERACTIVE" S-1-5-4 [Group 6] = "NT AUTHORITY\Authenticated Users" S-1-5-11 [Group 7] = "LOCAL" S-1-2-0 [Group 8] = "EXAMPLE\Data" S-1-5-21-3334797343-2748683396-701868904-1131 (X) SeChangeNotifyPrivilege         = Bypass traverse checking (O) SeSecurityPrivilege            = Manage auditing and security log (O) SeBackupPrivilege            = Back up files and directories (O) SeRestorePrivilege            = Restore files and directories (O) SeSystemtimePrivilege           = Change the system time (O) SeShutdownPrivilege           = Shut down the system (O) SeRemoteShutdownPrivilege      = Force shutdown from a remote system (O) SeTakeOwnershipPrivilege       = Take ownership of files or other objects (O) SeDebugPrivilege           = Debug programs (O) SeSystemEnvironmentPrivilege   = Modify firmware environment values (O) SeSystemProfilePrivilege       = Profile system performance (O) SeProfileSingleProcessPrivilege = Profile single process (O) SeIncreaseBasePriorityPrivilege = Increase scheduling priority (X) SeLoadDriverPrivilege           = Load and unload device drivers (O) SeCreatePagefilePrivilege       = Create a pagefile (O) SeIncreaseQuotaPrivilege        = Adjust memory quotas for a process (X) SeUndockPrivilege            = Remove computer from docking station (O) SeManageVolumePrivilege         = Perform volume maintenance tasks (X) SeCreateGlobalPrivilege         = Create global objects (X) SeImpersonatePrivilege          = Impersonate a client after authentication 

Under the privileges section, an (X) means the privilege is granted, an (0) means the privilege is not granted. The Local Security Authority (LSA) program (Lsass.exe) is the component in charge of generating the security token. Whenever a service (or process or server) impersonates a user to access a resource, it hands the SRM the token. The SRM is a kernel mode component in charge of determining which security principals get to access to what objects and what permissions are given. Along with the security principal's access token is an access mask. The access mask is the access the process is requesting on behalf of the security principal, so although a security principal may have Full Control-Allow permissions to the object being accessed, the process may only be asking for Read permissions for the current request. The access mask changes as needed. The SRM takes the access token and access mask and compares them to the object's defined security permission settings (more on this shortly). Figure 3-8 shows a simplistic representation of the transaction. The SRM returns the allowed permissions or restrictions.

Figure 3-8