Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Security Components

Windows security relies on several fundamental elements. It's important to understand how each of these elements are derived and how they fit together. This gives you the basis for evaluating practical security options. This section covers these elements:

• Access tokens




• SIDs




• Security descriptors




• Access control lists




• Passwords

Access Tokens

The information in an access token essentially defines two P's:

• Permissions.
  The access token contains all necessary information for the system to evaluate which resources a user can touch and what the user can do with those resources.




• Privileges.
  The access token contains a list of rights that determine which core system functions the user can call upon. For instance, a user with SeBackupPrivilege is permitted to run processes that make use of the system backup functions.

Table 11.1 lists the contents of an access token. This gives you an idea of the information used by the system to make its security decisions.

Permissions

When a user process touches an object, the Security Reference Monitor matches up SIDs in the access token with SIDs in the object's Access Control List (ACL). There are two possibilities:

• If there is no match, the user is denied access. This is called

  implicit deny .




• If there is a match, the user is given the permissions associated with the entry in the ACL. This could be an Allow permission or a Deny permission.

For example, the Allow Read permission assigned to SID S-1-1-0 (Everyone) would give any user permission to read the contents of a security object. A Deny Read permission assigned to SID S-1-5-2 (Network Users), on the other hand, would deny access to users who connect to the server across the network.

If a user were a member of both the Everyone and the Network Users groups in this example, the user would be denied Read access because Deny permissions take precedence over Allow permissions if both permissions have been directly assigned to the object. (Later, we'll see that inherited permissions are treated a little differently.)

SIDs

A typical user SID looks like this: S-1-5-21-1683771067-1221355100-624655392-1001. The format follows this pattern:

S-R-IA-SA-SA-RID . Here are the terms and their functions:

• S represents a

  SID identifier .
  This flags the number as a SID rather than some other kind of long, obscure number.




• R represents the

  Revision .
  All SIDs generated by Windows use a revision level of 1.




• IA represents the

  issuing authority .
  Nearly all SIDs in Windows specify the NT Authority, ID number 5, as the issuing authority. Exceptions include SIDs that represent well-known groups and accounts.




• SA represents a

  sub-authority .
  The SA designates special groups or functions. For example, 21 indicates that the SID was issued by a domain controller or standalone machine. The long number, 1683771067-1221355100-624655392, is the SA for the issuing domain or machine.




• RID is the

  Relative ID, a unique, sequential number assigned by the issuing SA to represent a security principal such as a user, computer, or group.

Functions of SIDs

If you're new to Windows system administration, this business of SIDs and RIDs might seem like geek-level stuff that no one really cares about. Nothing could be further from the truth. Understanding how SIDs are generated, stored, and manipulated is absolutely vital to managing a Windows system.

For instance, after you know that the system relies on the SID to uniquely identify a user, you won't be surprised that you can change a user's name without affecting the user's access permissions. You can take advantage of this in situations where a new user joins the company to replace a user who has left. You can simply rename the old user's account to the new user's name and retain the old account's access permissions and group memberships.

Knowing how the system uses SIDs also helps you to plan for moving accounts from one domain to another when you migrate an NT or Windows 2000 domain to a Windows Server 2003 domain. For example, when you copy a user account from one domain to another using the Active Directory Migration Tool (or a third-party equivalent), the user's SID in the classic NT domain is retained in a special SID History attribute so that the user can still access resources in the old domain when logged on to the new domain.

Well-Known SIDs

Not all SIDs represent specific user, group, and computer accounts. Certain SIDs have been set aside by Microsoft to represent standard accounts and groups. These are called

well-known SIDs . For example, if you log on at the console of a Windows machine, your access token is assigned the SID S-1-5-4, which is the well-known SID for the Interactive group.

Table 11.2 lists the well-known SIDs and their functions. The UI displays accounts and groups represented by well-known SIDs with a special icon that includes a small red up-arrow.

Well-Known RIDs

RIDs assigned to users, computers, and groups start at 1000. A set of RIDs between 500 and 999 is set aside to represent accounts and groups that every Windows computer and domain have in common. These are called

well-known RIDs .

Some well-known RIDs are appended to a domain SID to form a unique identifier. Others are appended to the Builtin SID, S-1-5-32, indicating that they are Builtin accounts that may have special privileges hard-coded into the operating system or assigned in the security database.

You can use these well-known accounts and groups to control access to resources. For instance, let's say a user who shares a computer wants to limit access to certain files on her local drive to users who share the computer. She could place the Network group on the ACL for the files with Deny Full Control permissions. This blocks access to any user who connects to her machine across the network while retaining access for users who log on at the console.

Table 11.3 lists the well-known RIDs and their functions. Domain SIDs are represented by an ellipsis <...>. The last few entries on the list are new well-known RIDs in Windows Server 2003.

Security Descriptors and Access Control Lists

As system administrators, we're faced every day with access management decisions. It's important to understand how the system implements our decisions so we can be sure that users don't get inappropriate permissions.

All NT-derived Windows platforms use a similar method for controlling access to security objects like files, folders, Registry keys, Active Directory objects, and services. Each of these security objects has a special data structure called a

security descriptor . Figure 11.2 shows a block diagram of the six components of a security descriptor:

• Header.
  This describes the contents of the security descriptor. It also contains a control structure that defines whether the object can inherit permissions from the security descriptor of its parent.




• Owner SID.
  Except for administrators, the owner of an object is the user who created it. Objects created by any member of the Administrators Builtin group are assigned the Administrators group as the owner.




• Primary group SID for the owner.
  This identification is used for POSIX and Macintosh support only.




• Discretionary access control list (DACL).
  This list defines the security principals who have been granted access or denied access to the object. The "discretionary" in DACL means that owners and administrators can make changes to the list.




• System access control list (SACL).
  This list defines users who will be logged by the auditing system when they access or fail to access an object. The ability to modify a SACL should be strictly controlled to prevent a bad guy from disabling auditing while he does dirty deeds.

Access Control Entries

An access control list contains one or more

access control entries (ACEs). An ACE consists of two parts:

• A SID representing a security principal




• An access mask defining permissions for that security principal

Table 11.4 and Table 11.5 list the access permissions associated with each access mask entry. The system evaluates these bits differently depending on the type of security object. This information is important when you use tools or scripts that expose a security descriptor without interpreting the contents.

FILE_READ_DATA             0x1
FILE_WRITE_DATA            0x2
FILE_APPEND_DATA           0x4
FILE_READ_EA               0x8
FILE_WRITE_EA              0x10
FILE_EXECUTE               0x20
FILE_READ_ATTRIBUTES       0x80
FILE_WRITE_ATTRIBUTES      0x100
READ_CONTROL               0x20000
SYNCHRONIZE                 0x100000

The access mask in an ACE is the sum of all the permissions assigned to the user identified in the ACE. Here's an example of how this works. Let's say you give the Administrators local group (SID S-1-5-32-544) permission to read and execute a file. The ACE mask associated with that entry would be the sum of these elements:

The access mask in the ACE for this entry would be 1021BF. When the ACL Editor displays the entry, it calculates the constituent permissions and displays them to you.

Viewing and Modifying ACEs

The Security tab of an object's Properties window displays an

ACL Editor . The ACL Editor shows several different views of the security descriptor. The first view, displayed in Figure 11.3, shows a consolidated list of ACEs and their generic access permissions.

If non-generic permissions have been assigned to an ACE, the permissions list shows a checkmark in the Special Permissions block.

If you click the Advanced button, you'll see a more detailed view of the security descriptor. Figure 11.4 shows an example.

This view lists each ACE on the DACL and the permissions assigned to it. If you highlight an entry and click Edit, the ACL Editor lists the full set of permissions for the ACE as shown in Figure 11.5. If an ACE has been assigned multiple individual permissions, you must use the Edit window to view the specific permissions.

Managing Object Ownership

The Advanced view of the ACL Editor has an Owner tab that displays the name of the user who created the object. Objects created by an administrator are assigned the Administrators local group as the owner.

If you have the Take Ownership system privilege, you can replace an object's current owner with your account. Because an object's owner has full access to any of the object's properties, the Take Ownership privilege should never be given to average users.

You cannot

transfer ownership to another user using the ACL Editor. There are several command-line tools available for transferring ownership:

• SUBINACL.
  This tool is in the Resource Kit. The syntax for transferring ownership is: subinacl /file

  <file_name> /setowner=<

  account_name >.




• CHOWN.
  The Resource Kit has a CHOWN utility as part of the POSIX suite of tools. It requires running the POSIX subsystem, which is not supplied in Windows Server 2003. (You can purchase a POSIX-compliant package called Interix from Microsoft. Some references suggest avoiding POSIX because it was not included in the evaluation that certified the operating system's Common Criteria compliance.) The syntax is chown <

  owner > <

  file >. This utility does not permit transferring ownership to a group. If you need that function, take a look at the CHOWN utility that comes in the Services for UNIX (SFU) toolkit. SFU tools cost over $300, making it a fairly expensive option.

Managing Security Descriptors with Command-Line Tools

The ACL Editor is the most flexible way to view and modify the contents of a security descriptor, but there are many situations where a command-line tool is more useful. For instance, you may want to modify the permissions of an object using a script or a batch file or you may only have Telnet access or a remote shell connection to a server.

You have a variety of command-line tools at your disposal to view and modify the contents of a security descriptor. I've broken them down by object class: services, Active Directory objects, and NTFS files and folders.

Services

You can use SUBINACL to view and modify the security descriptor for a service. (The Resource Kit documentation lists a utility called SVCACLS for setting permissions on service security descriptors, but this utility was pulled from the product because the features were duplicated in SUBINACL.) Here is an example SUBINACL listing for the LanMan Workstation service:

[View full width]
C:\>subinacl /service lanmanworkstation
===========================
+Service lanmanworkstation
===========================
/owner             =system
/primary group     =system
/audit ace count   =1
/aace =everyone         SYSTEM_AUDIT_ACE_TYPE-0x2
FAILED_ACCESS_ACE_FLAG-0x80    FAILED_ACCESS_ACE_FLAG-0x0x80
SERVICE_ALL_ACCESS
/perm. ace count   =4
/pace =authenticated users      ACCESS_ALLOWED_ACE_TYPE-0x0
SERVICE_QUERY_CONFIG-0x1           SERVICE_QUERY_STATUS-0x4 
SERVICE_ENUMERATE_DEPEND-0x8
SERVICE_INTERROGATE-0x80           READ_CONTROL-0x20000 
SERVICE_USER_DEFINED_CONTROL-0x0100
/pace =builtin\power users      ACCESS_ALLOWED_ACE_TYPE-0x0
SERVICE_QUERY_CONFIG-0x1           SERVICE_QUERY_STATUS-0x4 
SERVICE_ENUMERATE_DEPEND-0x8
SERVICE_START-0x10                 SERVICE_INTERROGATE-0x80 READ_CONTROL-0x20000  
             SERVICE_USER_DEFINED_CONTROL-0x0100
/pace =builtin\administrators   ACCESS_ALLOWED_ACE_TYPE-0x0
SERVICE_ALL_ACCESS
/pace =system   ACCESS_ALLOWED_ACE_TYPE-0x0
SERVICE_QUERY_CONFIG-0x1           SERVICE_QUERY_STATUS-0x4 
SERVICE_ENUMERATE_DEPEND-0x8
SERVICE_START-0x10                 SERVICE_STOP-0x20 SERVICE_PAUSE_CONTINUE-0x40  
      SERVICE_INTERROGATE-0x80
READ_CONTROL-0x20000               SERVICE_USER_DEFINED_CONTROL-0x0100

Active Directory Objects

For Active Directory objects, you can use a utility called DSACLS from the Resource Kit to view the contents of an Active Directory object's security descriptor. Here is partial DSACLS listing for the domain object Company.com:

C:\>dsacls dc=company,dc=com
Access list:
Effective Permissions on this object are:
Allow Everyone                                    SPECIAL ACCESS
READ PROPERTY
Allow NT AUTHORITY\Authenticated Users            SPECIAL ACCESS
READ PERMISSONS
LIST CONTENTS
READ PROPERTY
LIST OBJECT
Allow COMPANY\Domain Admins                       SPECIAL ACCESS
READ PERMISSONS
WRITE PERMISSIONS
CHANGE OWNERSHIP
CREATE CHILD
LIST CONTENTS
WRITE SELF
WRITE PROPERTY
READ PROPERTY
LIST OBJECT
CONTROL ACCESS
Allow BUILTIN\Administrators                      SPECIAL ACCESS
DELETE
READ PERMISSONS
WRITE PERMISSIONS
CHANGE OWNERSHIP
CREATE CHILD
LIST CONTENTS
WRITE SELF
WRITE PROPERTY
READ PROPERTY
LIST OBJECT
CONTROL ACCESS
Allow NT AUTHORITY\SYSTEM                         FULL CONTROL
Allow COMPANY\Enterprise Admins                      FULL CONTROL

NTFS File and Folders

To view the contents of the security descriptor for an NTFS file or folder, you can use the CACLS or XCACLS utilities. XCACLS has more options and comes in the Support Tools. You can also use the SUBINACL utility from the Resource Kit. Of the three utilities, XCACLS is the handiest but SUBINACL has the most features. For a read-only tool, there is also SHOWACLS from the Resource Kit.

Here is an example XCACLS listing for a file that has three ACEsAuthenticated Users, Administrators, and the well-known SID for the Interactive group:

C:\test>xcacls test.txt
C:\test\test.txt NT AUTHORITY\Authenticated Users:R
BUILTIN\Administrators:(OI)(CI)F
NT AUTHORITY\INTERACTIVE:(OI)(CI)(special access:)
READ_CONTROL
SYNCHRONIZE
FILE_GENERIC_READ
FILE_GENERIC_WRITE
FILE_GENERIC_EXECUTE
FILE_READ_DATA
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_READ_EA
FILE_WRITE_EA
FILE_EXECUTE
FILE_READ_ATTRIBUTES
FILE_WRITE_ATTRIBUTES

Here's a SUBINACL listing for the same file. As you can see, you get a lot more information, perhaps more than you really want:

[View full width]
C:\test>subinacl /file test3.txt
========================
+File C:\test\test.txt
========================
/owner             =builtin\administrators
/primary group     =cx612097-b\none
/audit ace count   =0
/perm. ace count   =3
/pace =builtin\administrators   ACCESS_ALLOWED_ACE_TYPE-0x0
CONTAINER_INHERIT_ACE-0x2      OBJECT_INHERIT_ACE-0x1
Type of access:
Full Control
Detailed Access Flags :
FILE_READ_DATA-0x1          FILE_WRITE_DATA-0x2         FILE_APPEND_ DATA-0x4
FILE_READ_EA-0x8            FILE_WRITE_EA-0x10          FILE_EXECUTE-0x20 
FILE_DELETE_CHILD-0x40
FILE_READ_ATTRIBUTES-0x80   FILE_WRITE_ATTRIBUTES-0x100 DELETE-0x10000 
READ_CONTROL-0x20000
WRITE_DAC-0x40000           WRITE_OWNER-0x80000         SYNCHRONIZE-0x100000
/pace =authenticated users      ACCESS_ALLOWED_ACE_TYPE-0x0
Type of access:
Read
Detailed Access Flags :
FILE_READ_DATA-0x1          FILE_READ_EA-0x8            FILE_EXECUTE-0x20
FILE_READ_ATTRIBUTES-0x80   READ_CONTROL-0x20000        SYNCHRONIZE-0x100000
/pace =interactive      ACCESS_ALLOWED_ACE_TYPE-0x0
CONTAINER_INHERIT_ACE-0x2      OBJECT_INHERIT_ACE-0x1
Type of access:
Special acccess :  -Read  -Write  -Execute
Detailed Access Flags :
FILE_READ_DATA-0x1          FILE_WRITE_DATA-0x2         FILE_APPEND_ DATA-0x4
FILE_READ_EA-0x8            FILE_WRITE_EA-0x10          FILE_EXECUTE-0x20 
FILE_READ_ATTRIBUTES-0x80
FILE_WRITE_ATTRIBUTES-0x100 READ_CONTROL-0x20000        SYNCHRONIZE- 0x100000

Access Permission Evaluation

We have finally arrived at the nitty-gritty of Windows authorization, the mechanism used by the system to determine whether or not to grant access for a particular object to a user. When a user process accesses a security object, the Security Reference Monitor (SRM) scans the DACL in the object's security descriptor looking for any SIDs that match SIDs in the user's access token.

When the SRM encounters a match, it evaluates the permissions in the ACE mask against the permissions requested by the process presenting the access token. If one of the permissions matches, the entire access mask is extracted from the ACE and added to a consolidated access mask for the user process.

If a user is granted permission by an ACE, that particular permission is not evaluated again. Keep this in mind as we trace an evaluation transaction. If a user is not explicitly granted access permissions by any ACE in a DACL, the user is denied access. This is called

implicit deny .

Cumulative Allow Permissions

Permissions granted by Allow ACEs are cumulativethat is, permissions granted to the same user by different ACEs are collected together to form a single set of access permissions. Here's an example of how the system evaluates Allow ACEs to achieve this cumulative permission set.

Consider a process owned by user Jane. A thread from this process opens a file for Read and Write access. Jane has two ACEs in the DACL for the file, one with an Allow Write access mask and one with an Allow Read access mask. The thread has Jane's access token attached. When the thread attempts to access the file object, the SRM scans the file's DACL and finds an ACE containing Jane's SID.

The SRM compares the permissions requested by the thread (Read and Write) with the permissions in the access mask of the ACE (Read_Data) and finds a match on the Read permission in the Allow ACE.

Because there is a SID match and a permissions match, the SRM adds the access mask in the ACE to a consolidated access mask for the thread and continues scanning the DACL.

It then encounters the second ACE with Jane's SID. During the permission comparison, it determines that the Write permission requested by the thread matches the Write_Data permission in the access mask for the Allow ACE. The SRM adds the access mask to the consolidated mask and continues scanning.

Because Jane has not been explicitly granted Allow permissions for any other permission, the final contents of the consolidated mask gives the thread Write and Read access to the file but nothing else.

Evaluation of Deny Permissions

Deny permissions take precedence over Allow permissions. Let's change the example a bit to see how. In the new example, a Deny ACE has been added for the Write permission.

When the thread owned by Jane touches the file, the SRM begins scanning the DACL and encounters an ACE containing Jane's SID. During the permission comparison, the SRM finds a match between the requested permissions (Read and Write) and the Write_Data permission in the access mask for the Deny ACE.

Because there is a SID match and a permissions match, the SRM adds the Deny access mask for Write_Data to a consolidated access mask for the thread and continues scanning the DACL.

The SRM then encounters a second ACE with Jane's SID. During the permissions comparison, it determines that the Read permission requested by the thread matches the Read_Data permission in the access mask for the Allow ACE. The SRM adds the Read_Data access mask to the consolidated mask and continues scanning.

The SRM then encounters a third ACE with Jane's SID. During the permissions comparison, it determines that the Write permission requested by the thread has already been evaluated in a previous ACE. It takes no further action and resumes scanning. Remember, once a permission has been assigned, it is not evaluated again.

Based on the final contents of the consolidated mask, the thread representing Jane gets Read access. She was explicitly denied Write access and all other permissions are implicitly denied.

It's important to note that the precedence of Deny over Allow relies on two key operational features:

• Deny ACEs are sorted to appear before Allow ACEs in a DACL. This is called

  canonical sorting.




• After the SRM has evaluated a permission, that particular permission is not evaluated again.

Windows automatically sorts ACEs in canonical order, but it plays favorites. Try an experiment. Open the Advanced view of the ACL Editor on a file object. This view lists the ACEs in the order they are evaluated by the SRM. Figure 11.6 shows an example of a user in an OU that sits three levels deep in Active Directory. Each OU has an administrative group assigned to it, so the user object ends up inheriting all three groups.

In the Advanced view of the ACL Editor, find a column labeled Inherited From. You'll notice that inherited ACEs are grouped below the directly applied ACEs in the list. This means that directly applied ACEs take precedence over inherited ACEs. The reason for this, and the mechanisms underlying permission inheritance, are explained in the next section.

Permissions inheritance makes it possible to quickly and easily modify the permissions of very large structures without actually modifying the security descriptor of every element in that structure. Inheritance also overcomes a problem in classic NT where an update to an ACL for a directory high in a structure would overwrite the ACLs in all the security descriptors underneath.

Permissions Inheritance

Permissions inheritance takes advantage of a new way of managing security descriptors that was introduced in Windows 2000. The exact mechanism for this is covered in the section titled "Operational Description of Permission Inheritance" later in this chapter. Rather than place security descriptors on every object, the system maintains a separate database of security descriptors that the objects reference. (This is not true of Registry keys, though. Updating the DACL on an upper Registry key still involves changing the DACL on every child key.)

The ACL Editor has an option to block inheritance. Choosing this option creates a new security descriptor in the database and changes the pointers of the child descriptors. This mechanism retains the speed and efficiency of the classic NT SRM evaluation process with the flexibility of dynamic inheritance.

ACE Evaluation with Inheritance

ACEs that are directly applied to a DACL take precedence over ACEs that are inherited from a parent object. Also, ACEs applied at each tier of the file system or Active Directory take precedence of permissions applied higher in the tree. The system achieves this by sorting the ACEs based on their origin. Here is the sort order:

• Directly applied Deny ACEs are sorted to the top of the DACL.




• Directly applied Allow ACEs are placed next in line.




• Inherited Deny ACEs , if any, are placed here.




• Inherited Allow ACEs are evaluated last.

This means a directly applied Allow ACE takes precedence over an inherited Deny ACE. This is non-intuitive. Here's an example to demonstrate how it works.

Consider a user who is a member of two groups. Group A has been directly assigned to the DACL of a file with Allow Read/Write/Execute access permissions. Group B has been inherited from the parent folder with Deny Read/Write permissions.

The SRM only evaluates individual permissions once during an ACE scan. Because the first ACE in the scan has an access mask for Read_Data, Write_Data, and Execute, these permissions are not evaluated again when they appear in the Deny mask in the next ACE. The consolidated access mask assigned to the thread would have Allow Read/Write/Execute permissions.

Keep this behavior in mind as you define access permissions for security objects:

• Don't assume that you block access to an entire subdirectory by assigning a Deny ACE at an upper folder.
  Another administrator, or the owner of a subfolder, can block inheritance lower in the tree or directly apply an Allow ACE that overrides your Deny ACE. The same caution applies to Active Directory objects. An OU administrator can block permissions inheritance and stage a virtual coup.




• Don't place an administrative group on a DACL with an Access Denied ACE.
  You might accidentally lock yourself and your colleagues out of an important folder or container. Fortunately, the Administrators group owns all of the Directory objects, so you can change the ACL back if you make a mistake.




• Don't associate an Access Denied ACE with the Everyone group.
  If you lock out Everyone, you lock out yourself and your fellow administrators, as well. You even lock out the local system. This same caution applies to other well-known groups such as Interactive or Network or LocalService or NetworkService. If you don't want everyone to have access to an object, remove the Everyone group from the ACL and rely on implicit deny to keep out unwelcome intruders.

Operational Description of Permission Inheritance

Classic NT Chapter 16, "Managing Shared Resources.")

Assigning Inheritance Settings

The inheritance setting for each individual ACE in a DACL is separately flagged. You can configure the inheritance setting using the Advanced view of the ACL Editor.

When you click Add or Edit on an ACE in Advanced view, the Permission Entry window opens with an Apply Onto box that lists the inheritance options. Here are the options for NTFS objects:

• This folder only




• This folder and all subfolders and files




• This folder and subfolders




• This folder and files




• Subfolders and files only




• Subfolders only




• Files only

Here are the inheritance options for Active Directory objects:

• This object only




• This object and all child objects




• Child objects only

Active Directory objects have additional inheritance settings for selecting the class of objects that inherit a particular ACE. The Delegation Wizard simplifies the selection process. See Chapter 13, "Managing Active Directory Security," for details.

Viewing Consolidated Permissions

A user's access token contains the SID of every group that has the user as a member. It also contains the SID of every group that has those groups as members, and so on. It can sometimes be a challenge to determine the exact permissions a particular user has for a particular object.

You can view a resultant set of permissions for a specified user or group on a particular object using the ACL Editor. Figure 11.7 shows an example of an administrator who is in a group with Full Control permissions delegated to the OU containing a User object. The permissions can be viewed using the steps in Procedure 11.1.

Procedure 11.1 Viewing a Resultant Set of Permissions

1. Open the Properties window for a security object.

2. Select the Security tab.

3. Click Advanced.

4. Select the Effective Permissions tab.

5. Click Select. The Select User, Computer, or Group window opens.

6. Enter the name of the user or group you want to evaluate.

7. Click OK. The Effective Permissions field populates with a checkmark for each permission available to the user.

System Privileges

So far, we've seen how the SRM controls access to security objects based on access tokens and security descriptors. There is an additional set of controls that define which users and groups can access basic system services such as the capability to perform a Backup/Restore or change the system time. These are called

system privileges . Here is a quick list of the system privileges in Windows Server 2003 (privileges associated strictly with developers tools are not included):

• Add workstations to domain




• Adjust memory quotas for a process




• Back up files and directories




• Bypass traverse checking




• Change the system time




• Create a paging file




• Debug programs




• Enable accounts to be trusted for delegation




• Force shutdown from a remote system




• Impersonate a client after authentication (new in Windows Server 2003)




• Increase scheduling priority




• Load and unload device drivers




• Manage auditing and security log




• Modify firmware environment values




• Perform volume maintenance tasks




• Profile single process




• Profile system performance




• Remove computer from docking station




• Replace a process level token




• Restore files and directories




• Shut down the system




• Take ownership of files or other objects

These privileges are assigned via policies set either at a local machine or downloaded from a domain controller as part of a Group Policy Object (GPO):

• Local security policies are stored in the Secedit.sdb database. The database is located in \Windows\Security\Database. Local security policies are configured with the Group Policy Editor (Gpedit.msc), which can be launched from S

  TART | P

  ROGRAMS | A

  DMINISTRATIVE T

  OOLS | L

  OCAL S

  ECURITY P

  OLICY .




• Group security policies are linked to a particular Site, Domain, or OU in Active Directory. For example, domain controllers download their group security policies from the Default Domain Controller group policy object that is linked to the Domain Controllers OU. Group policies override local policies in the Secedit.sdb database. The group policies that control system privileges are located under Computer Configuration | Windows Settings | Security Settings | Local Policies | User Rights Assignment.

Security policies can be assigned directly to a user or to a group containing the user. In either case, the privileges associated with a user become part of the user's access token. They are evaluated whenever the user process attempts to perform a privileged system operation.

Viewing System Privileges

Several command-line utilities list the system privileges assigned to a user. These are useful when you are trying to troubleshoot why a particular user is not able to perform a certain task.

WHOAMI

The WHOAMI tool from the Resource Kit lists a user's groups and security privileges. Here's a sample listing (syntax: whoami /all):

[View full width]
C:\>whoami /all
[User]     = "COMPANY\Administrator"  S-1-5-21-2942328611-473866232-3689853989-500
[Group  1] = "COMPANY\Domain Users"  S-1-5-21-2942328611-473866232-3689853989-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] = "COMPANY\Schema Admins"  S-1-5-21-2942328611-473866232-3689853989-518
[Group  6] = "COMPANY\Domain Admins"  S-1-5-21-2942328611-473866232-3689853989-512
[Group  7] = "COMPANY\Group Policy Creator Owners"  
S-1-5-21-2942328611-473866232-3689853989-520
[Group  8] = "COMPANY\Enterprise Admins"  S-1-5-21-2942328611-473866232-3689853989-519
[Group  9] = "LOCAL"  S-1-2-0
[Group 10] = "NT AUTHORITY\REMOTE INTERACTIVE LOGON"  S-1-5-14
[Group 11] = "NT AUTHORITY\INTERACTIVE"  S-1-5-4
[Group 12] = "NT AUTHORITY\Authenticated Users"  S-1-5-11
(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
(O) SeEnableDelegationPrivilege     = Enable accounts to be trusted for delegation
(O) SeAssignPrimaryTokenPrivilege   = Replace a process level token
(O) SeMachineAccountPrivilege       = Add workstations to domain

Notice that, according to WHOAMI, the Administrator account apparently does not have the SeBackupPrivilege, which is required to perform a backup. Yet, we know that the Administrator account can perform this function. This is because WHOAMI only reports on the privileges directly assigned to the user, not those assigned to groups that have the user as a member. The GPRESULT utility gives a more complete report.

GPRESULT (Standard Utility)

You'll get a more accurate picture of a user's true privileges using GPRESULT, which comes with a standard installation of Windows Server 2003 and XP. The listing includes all policies, not just system privileges. Here is an excerpt (syntax: gpresult -v):

GPO: Default Domain Controllers Policy
Policy:            CreatePagefilePrivilege
Computer Setting:  Administrators
GPO: Default Domain Controllers Policy
Policy:            EnableDelegationPrivilege
Computer Setting:  Administrators
GPO: Default Domain Controllers Policy
Policy:            DebugPrivilege
Computer Setting:  Administrators
GPO: Default Domain Controllers Policy
Policy:            SystemTimePrivilege
Computer Setting:  Server Operators
Administrators
GPO: Default Domain Controllers Policy
Policy:            DenyBatchLogonRight
Computer Setting:  N/A
GPO: Default Domain Controllers Policy
Policy:            BackupPrivilege
Computer Setting:  Server Operators
Backup Operators
Administrators

As you can see, this listing is more accurate than WHOAMI because it includes privileges obtained by dint of group membership, but the listing is not as easy to work with because you must sift though each privilege.

GPRESULT (Windows 2000 Resource Kit)

You can get a privilege list that is easier to scan with the GPRESULT tool from the old Windows 2000 Resource Kit. Here's a sample (syntax: gpresult /v):

User Group Policy results for:
CN=Administrator,CN=Users,DC=company,DC=com
Domain Name:          COMPANY
Domain Type:          Windows 2000
Site Name:            Default-First-Site-Name
Roaming profile:      (None)
Local profile:        C:\Documents and Settings\Administrator
The user is a member of the following security groups:
COMPANY\Domain Users
\Everyone
BUILTIN\Administrators
BUILTIN\Users
COMPANY\Schema Admins
COMPANY\Domain Admins
COMPANY\Group Policy Creator Owners
COMPANY\Enterprise Admins
\LOCAL
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
The user has the following security privileges:
Bypass traverse checking
Manage auditing and security log
Back up files and directories
Restore files and directories
Change the system time
Shut down the system
Force shutdown from a remote system
Take ownership of files or other objects
Debug programs
Modify firmware environment values
Profile system performance
Profile single process
Increase scheduling priority
Load and unload device drivers
Create a pagefile
Adjust memory quotas for a process
Remove computer from docking station
Perform volume maintenance tasks
Enable computer and user accounts to be trusted for delegation
Replace a process level token
Add workstations to domain

SHOWPRIVS

If you want to see the users and groups that have been assigned a particular privileges, use the SHOWPRIVS utility from the Resource Kit. Here's a sample (syntax: showprivs seshutdownprivilege):

C:\>showpriv seshutdownprivilege
5 account(s) with the seshutdownprivilege user right:
BUILTIN\Backup Operators
BUILTIN\Print Operators new name
BUILTIN\Server Operators
BUILTIN\Account Operators
BUILTIN\Administrators
All accounts enumerated

Security Policies

In addition to group policies that affect fundamental system privileges, Windows has a long list of group policies that are used to manage security at a higher level. The policies affect Registry settings, not entries in the Secedit.sdb database. The policies are located in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options.

Here is a list of the commonly used security policies along with their associated Registry keys and a description of the policy function:

• Allow system to be shutdown without having to log on .
  (HKLM\Software\ Microsoft\Windows NT\CurrentVersion\Winlogon\ShutdownWithoutLogon) When you press Ctrl+Alt+Delete to log on, the Welcome to Windows window has a Shutdown button that permits shutting down the machine without logging on. For an XP desktop, this is acceptable, although it could result in data loss for other users if Fast User Switching is enabled. Servers should not be shut down from the logon window because users may have connections to the server. For this reason, running Windows Server 2003 have a local policy that disables ShutdownWithoutLogon.




• Audit the access of global system objects .
  (HKLM | System | CurrentControlSet | Control | Lsa | AuditBaseObject) The interior of Windows Server 2003 is a little like the Pentagon. Most of the secret places are fairly dull, even if you have the clearance to see them. For this reason, enabling auditing does not ordinarily reveal access to many obscure internal objects. Enabling this option adds the internal objects to the audit report. For the most part, this option is only useful to system-level programmers.




• Audit the use of all user rights including backup and restore .
  (HKLM | System | CurrentControlSet Control | Lsa | FullPrivilegeAuditing) Under normal circumstances, if you enable auditing of access to privileged objects, the Security log would fill as soon as you performed your first backup. This is because you would be exercising your Backup Operator privilege over and over and over again. For this reason, backup and restore auditing is ordinarily bypassed. Only enable this option when you think someone is misusing his or her backup and restore privileges. Be sure to make the Security log very large to accommodate the entries and be prepared for a very slow backup.




• Rename Administrator account [Guest Account] .
  (Registry or Directory entry locked) The Administrator account is like a J.R.R. Tolkien wizard. It wields powerful devices that are hidden to mere users. This makes the Administrator account a favorite object of hack attempts. This policy renames the Administrator (and Guest) account to help obfuscate the accounts. Unfortunately, there are some very simple API calls that reveal the identity of the Administrator account regardless of its name, so this policy will not trip up a sophisticated intruder.




• Clear virtual memory pagefile when system shuts down .
  (HKLM | System | CurrentControlSet | Control | Session Manager | Memory Management | ClearPageFileAtShutdown) Clearing out the paging file at each shutdown is a good way to enforce security by preventing storage of potentially sensitive information in the paging file. If you choose to deploy such a policy, the users will need this system privilege.




• Shut down system immediately if unable to log security audits .
  (HKLM | System | CurrentControlSet | Control | Lsa | CrashOnAuditFail) If you choose to audit a system, you may want to ensure that the auditing system catches every event you are monitoring. If the log fills, you will lose events. Therefore, you may want to force the system to shut down if the log gets full. An account with Administrator privileges can log on to save and clear the Security file.




• Do not allow enumeration of account names and shares by anonymous users .
  (HKLM | System | CurrentControlSet | Control | Lsa | RestrictAnonymous) This policy prevents users without credentials from getting the names of shares on a server. See the "Anonymous Logon" section for more information.




• Disable Ctrl+Alt+Del requirement for logon .
  (HKLM | Software | Microsoft | Windows NT | CurrentVersion | Winlogon |DisableCAD) This policy gives users who are not members of a domain the ability to get right to the Explorer shell without a logon. It should never be enabled.




• Do not display last username in logon screen .
  (HKLM | Software | Microsoft | Windows NT | CurrentVersion | Winlogon |DontDisplayLastUserName) It's handy to have your username displayed when you press Ctrl+Alt+Del to log on, but security-conscious administrators object to exposing a name so that all a bad guy needs to do is guess the password.




• Secure channel: digitally sign secure channel .
  (HKLM | System | CurrentControlSet | Services | Netlogon | Parameters | SealSecureChannel) This and the following two settings are designed to deal with a very specific potential security breach in Windows Server 2003. Member workstations and servers communicate to their domain controllers over a secure RPC link. This link is not checked for integrity, so a bright bad guy could conceivably impersonate a machine on the wire and divert secure traffic. The digital signing identifies each packet coming over the secure link. It slows down communications somewhat. (I do not have statistics.)




• Secure channel: digitally encrypt all secure channel data .
  (HKLM | System | CurrentControlSet | Services | Netlogon | Parameters | SignSecureChannel) Same as the preceding description, but with the addition of encryption for all traffic, not just passwords.




• Secure channel: digitally encrypt or sign secure channel .
  (HKLM | System | CurrentControlSet | Services | Netlogon | Parameters | RequireSignOrSeal) Same as preceding description, but forces secure traffic instead of letting the members auto-negotiate. Only set this option if every domain controller is set the same way.




• Encrypt files in the offline folders cache .
  (HKLM | Software | Microsoft | Windows | CurrentVersion | NetCache | EncryptEntireCache) Client-side caching speeds network communication by holding copies of executables and other read-only files at the local machine. A bad guy could conceivably nab these saved files and steal valuable secrets. Encrypting the files slows performance, but improves security. You may have noticed a trend.




• Automatically log off users when logon time expires .
  (HKLM | System | CurrentControlSet | Control | Session Manager | ProtectionMode) You can define a specific time of day after which a user or group of users is denied access. This is useful when you have a group of users who have specific duties from 8 to 5, but should not be messing around on the network after hours. This policy affects network access only, not the ability to log on to a local desktop.




• Message text for users attempting to log on .
  (HKLM | Software | Microsoft | Windows NT | CurrentVersion | Winlogon |LegalNoticeText) This and the next option define parameters for a special window that appears after the user presses Ctrl+Alt+Del but before the Winlogon credentials window. It is most often used to display boilerplate Human Resources text like "You are using COMPANY equipment and must obey COMPANY policies that are available in COMPANY offices."




• Message title for users attempting to log on .
  (HKLM | Software | Microsoft | Windows NT | CurrentVersion | Winlogon | LegalNoticeCaption) This option specifies the title bar text in the window configured by LegalNoticeText.




• Number of previous logons to cache .
  (HKLM | Software | Microsoft | Windows NT | CurrentVersion | Winlogon | CachedLogonsCount) If a workstation cannot contact its domain controller, a user can still be logged on via cached credentials. The cache is set for 10 by default. If you have a workstation at which many people log on, some of them may have been aged out of the cache. You can set this option to as many as 50 logons.




• Restrict CD-ROM access to locally logged-on user only .
  (HKLM | Software | Microsoft | Windows NT | CurrentVersion | Winlogon | AllocateCDRoms) C2 security requirements include a specification to exclude removable media from network access.




• Restrict floppy access to locally logged-on user only .
  (HKLM | Software | Microsoft | Windows NT | CurrentVersion | Winlogon | AllocateFloppies) See preceding item.




• Send unencrypted password to connect to third-party smb servers .
  (HKLM | System | CurrentControlSet | Control | Lsa | LmCompatibilityLevel) If you are using older Samba servers, they cannot use NTLMv2 password hashes. Setting this policy allows you to connect using LanMan (LM) password hashes. This policy should not be enabled. Instead, upgrade your Samba servers.