• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    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.

    Viewing Access Token Contents

    If you want to know more about access tokens, I highly recommend the book Programming Server-Side Applications for Windows 2000 by Jeffrey Richter and Jason D. Clark. Don't let the name fool you. Even if you never write a single line of code, this book is still worthwhile reading. The book comes with a CD that has several handy tools. One of these, Tokenmaster, displays the contents of the access token for any process running on a server.

    Table 11.1. Access Token Contents and Functions



    User's SID

    The security system identifies users by number rather than by name, much the same as the Social Security Administration. The SID is a combination of the Relative ID (RID) assigned to the user and the SID of the domain or (in the case of local logons) the computer.

    Group SIDs

    The SID for each group that has the user as a member. This includes domain groups and groups on the local machine where the user logs on.

    Logon SID

    A unique and temporary SID that represents an individual logon session. If a user makes multiple connections to a server, such as from different machines, each session gets a different logon SID.

    User privileges

    These are system privileges such as the ability to change the system time, to do a backup, and so forth.

    Default owner SID

    This SID is used to mark the ownership of any security objects created by the user. Except for members of the Administrators group, this SID matches the user's SID. For members of the Administrators group, this SID matches the SID of the Administrators group.

    Default group SID

    Useful only for POSIX and Services for Macintosh (SFM), this SID matches the primary group SID selected in the user's account attributes.

    Default DACL

    Every system object has a security descriptor that contains a Discretionary ACL, or DACL. The DACL defines who can access the object and what they can do. If the process that creates an object does not specify the contents of the DACL, the system uses this default DACL.

    Originating Process

    The name of the system process that created the access token.

    Token type

    When a user logs on from the console, she gets a primary access token. A user logging on across the network gets an impersonation access token.

    Impersonation level

    There are four impersonation levels. Anonymous (no client information available), Identification (client identified but not impersonated), Impersonation (client identified and able to run local processes but not able to connect to other machines), and Delegation (client process can connect to other machinesrequires Kerberos authentication).

    Restrictive SIDs

    This feature, introduced in Windows 2000, enables a developer to block a user's privileges without modifying the user's group membership.


    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.)


    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.

    New Well-Known SIDS

    In classic NT and Windows 2000, the Local System account, SID S-1-5-18, provides the security context for nearly all services. This account is highly privileged and using it for common services represents a security vulnerability.

    Windows Server 2003 attempts to minimize this vulnerability by introducing two additional well-known SIDS that provide a security context for services: LocalService and NetworkService.

    There are two major advantages to using standard accounts to run services rather than Local System. First, these accounts have a SID and therefore can present Kerberos or NTLM credentials when accessing resources on other servers. The Local System account cannot do this and must use an anonymous logon session to access network resources.

    The second advantage involves Public Key Infrastructure (PKI). The new service accounts each have a local profile and can therefore obtain PKI certificates. This helps identify the services if you implement digital signing in your system, such as for IPSec or secure email.

    If you scan the list of services on Windows Server 2003 using Task Manager, you'll see that the two new service accounts own only a few of the background processes. Still, it's a start. They are especially valuable for IIS, where they are used to control access to the worker processes that own web sites.

    Table 11.2. Well-Known SIDs and Their Functions




    A memberless group used to represent an account with no known SID. This is also called a null session SID. Windows Server 2003 severely curtails the circumstances where a null session SID can be used to access resources.


    This is the World SID, known in Windows as the Everyone group. All users except anonymous users get this SID in their access token.


    The Local group. This group identifies users who have physically logged on to the console of a computer.


    The Creator/Owner group. This acts as a placeholder in ACLs. It is replaced with the SID of the actual creator-owner when the security descriptor is enumerated. For instance, if user bbrown created a folder that has SID S-1-3-0 on the ACL, this entry would be replaced with bbrown's SID when she accesses the object.


    The Primary group. This is another placeholder SID. It is replaced with the user's primary group when it appears on an ACL. Primary groups only have meaning to POSIX and Services for Macintosh. The default primary group for users of a standalone machine is Users. The default primary group for users in a domain is Domain Users.


    The NT Authority.










    Session Logon ID.




    Anonymous Logon. Assigned to any user who does not present credentials when accessing a system.


    Proxy (not used).


    Enterprise Controllers. Includes all domain controllers in an Active Directory forest.


    Self. A placeholder for a user identified by a specific SID in an access token.


    Authenticated user. Added in NT4 SP3 to differentiate users who have received network authentication from the S-1-1-0 Everyone group.


    Reserved for future use.


    Terminal server users.


    Local System. Provides a security context for system processes.


    Local Service (new in Windows Server 2003). Provides a less privileged security context for services that control local processes.


    Network Service (new in Windows Server 2003). Provides a less privileged security context for services that control network access.


    Non-unique RIDs. Used as a prefix to domain and workstation SIDs.


    Builtin Local groups. Identifies members of the Builtin database in the SAM (or Builtin container in Active Directory). This includes groups such as Administrators and Power Users.

    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.

    Table 11.3. Well Known RIDs and Their Function




    Administrator account.


    Guest account.


    KRBTGT, the account used to encrypt Kerberos ticket-granting tickets.


    Domain admins.


    Domain users.


    Domain guests.


    Domain computers.


    Domain controllers.


    Cert publishers.


    Schema admins. This SID is on the ACL for the Schema container. Users assigned this SID have read/write/create permission for objects in the Schema.


    Enterprise admins. This SID is on the ACL for the Configuration container and every Domain container in a forest. Users assigned this SID have full control permissions for all objects in those containers.


    Group policy creator owners. This SID is on the ACL for the cn=Policies,cn=System container in each domain. Users assigned this SID have the ability to create new group policy containers.


    RAS and IAS servers. This SID is on the RAS and IAS Servers Access Check container. Servers assigned this SID can verify user and group information in Active Directory.








    Power users.


    Account operators.


    Server operators.


    Print operators.


    Backup operators.




    RAS servers.


    Pre-Windows 2000 Compatible Access.


    Remote desktop users (new in Windows Server 2003).


    Network configuration operators (new in Windows Server 2003).


    Incoming forest trust builders (new in Windows Server 2003).


    Performance monitor users (new in Windows Server 2003).


    Performance log users (new 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.

    Figure 11.2. Block diagram of security descriptor.


    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
    READ_CONTROL               0x20000
    SYNCHRONIZE                 0x100000

    Table 11.4. Access Masks and Their Functions

    Generic Access Masks




    Delete (applies to entire object, including security descriptor)


    Read_Control (read security descriptor)


    Write_Dac (modify security descriptor)


    Write_Owner (change ownership)


    Synchronize (process level permission)

    Table 11.5. Specialized Access Masks




    Registry Keys

    Active Directory Objects

    Service Objects























































    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.

    Figure 11.3. Security properties for a user object in Active Directory.


    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.

    Figure 11.4. Advanced security descriptor view of an Active Directory user object.


    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.

    Figure 11.5. Properties view of a security descriptor.


    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.


    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:

    C:\>subinacl /service lanmanworkstation
    +Service lanmanworkstation
    /owner             =system
    /primary group     =system
    /audit ace count   =1
    /aace =everyone         SYSTEM_AUDIT_ACE_TYPE-0x2
    /perm. ace count   =4
    /pace =authenticated users      ACCESS_ALLOWED_ACE_TYPE-0x0
            SERVICE_QUERY_CONFIG-0x1           SERVICE_QUERY_STATUS-0x4 
            SERVICE_INTERROGATE-0x80           READ_CONTROL-0x20000 
    /pace =builtin\power users      ACCESS_ALLOWED_ACE_TYPE-0x0
            SERVICE_QUERY_CONFIG-0x1           SERVICE_QUERY_STATUS-0x4 
            SERVICE_START-0x10                 SERVICE_INTERROGATE-0x80 READ_CONTROL-0x20000  
    graphics/ccc.gif             SERVICE_USER_DEFINED_CONTROL-0x0100
    /pace =builtin\administrators   ACCESS_ALLOWED_ACE_TYPE-0x0
    /pace =system   ACCESS_ALLOWED_ACE_TYPE-0x0
            SERVICE_QUERY_CONFIG-0x1           SERVICE_QUERY_STATUS-0x4 
            SERVICE_START-0x10                 SERVICE_STOP-0x20 SERVICE_PAUSE_CONTINUE-0x40  
    graphics/ccc.gif      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
                                                      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
                      NT AUTHORITY\INTERACTIVE:(OI)(CI)(special access:)

    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:

    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
        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 
            WRITE_DAC-0x40000           WRITE_OWNER-0x80000         SYNCHRONIZE-0x100000
    /pace =authenticated users      ACCESS_ALLOWED_ACE_TYPE-0x0
        Type of access:
        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
        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_WRITE_ATTRIBUTES-0x100 READ_CONTROL-0x20000        SYNCHRONIZE- 0x100000

    Scripting and Security Descriptors

    If you decide that you need to modify security descriptors in your scripts, you'll need lots of references and examples.

    I highly recommend the book ADSI Scripting for NT/Windows 2000 System Administrators by Tom Eck for example scripts and a very clear explanation of security descriptor operations.

    You should also consider purchasing third-party COM objects to simplify security descriptor operations. Take a look at the Ntsec library at www.pedestalsoftware.com/ntsec.

    Windows Server 2003 includes new standard API calls that simplify security descriptor operations. Review the details on these new function calls in the Platform SDK, downloadable from www.microsoft.com or available in the MSDN library.

    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.

    Assigning Allow and Deny Permissions

    Each ACE in a DACL is classified as an Allow ACE or a Deny ACE. This means you cannot mix Allow permissions and Deny permissions in the same access mask.

    If you use the ACL Editor to check permissions in both the Allow and Deny columns for a single security principal, the editor creates two separate ACEs, one for the Deny permissions and one for the Allow permissions.

    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.

    Figure 11.6. Advanced view of ACL Editor showing ACE groupings based on inheritance.


    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.

    Exceptions to Canonical Sorting

    It is possible to override canonical sorting of ACEs programmatically. This enables a developer to take advantage of the way the SRM evaluates individual permissions only once in an ACE scan.

    For example, in Exchange 2000, the members of a distribution group can be hidden from view. This requires placing the Everyone group on the DACL in a Deny Read ACE.

    If the DACL were subject to normal canonical sorting, this would block the Exchange service from seeing the contents. Access tokens for all accounts except Anonymous Logon automatically include the Everyone group. Exchange overcomes this problem by overriding the canonical sorting to give the Exchange service Full Control access before putting the Deny ACE for Everyone.

    Because the SRM only evaluates permissions once, this non-canonical sorting gives full control to the Exchange service while denying access to everyone else. If you open the ACL Editor, you get a warning that the ACEs are not sorted in standard order.

    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.

    Blocking Permission Inheritance

    When you choose to block permission inheritance at an object, the system prompts you to either Copy or Remove the inherited ACEs from the DACL. I recommend always copying the ACEs. You can then select which ACEs to remove and which to retain. This helps avoid accidentally disabling access to folders or objects further down the tree that might have been relying on an inherited ACE that you removed.

    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 places a security descriptor in each object. If a change is made to the ACL in a parent object such as a file folder, the system has to open the security descriptor on each child object and update the ACL.

    If you're an administrator on a classic NT file and print server and you've ever made a change to the root folder of a large NTFS volume, you know the time and resources that are involved in updating the ACLs on all the subfolders and files. The versions of NTFS that ship with Windows 2000, Windows Server 2003, and Windows XP handle permissions much more efficiently. Rather than put a security descriptor in each object, the file system maintains a table of security descriptors in a hidden database under the $Secure metadata folder. Each file and folder has a reference to a security descriptor in the table.

    When you modify the DACL of a folder, all the child folders linked to that security descriptor get the new entry automatically. If you block inheritance at a folder, a new security descriptor is created in the database and the references in the subfolders are changed to point at the new security descriptor. This dramatically reduces the time and resources required to modify permissions. (For more information on NTFS security descriptor handling, see 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.

    Figure 11.7. ACL Editor showing resultant set of permissions.


    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 START | PROGRAMS | ADMINISTRATIVE TOOLS | LOCAL SECURITY POLICY.

    • 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.


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

    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"  
    [Group  8] = "COMPANY\Enterprise Admins"  S-1-5-21-2942328611-473866232-3689853989-519
    [Group  9] = "LOCAL"  S-1-2-0
    [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
      GPO: Default Domain Controllers Policy
          Policy:            DenyBatchLogonRight
          Computer Setting:  N/A
      GPO: Default Domain Controllers Policy
          Policy:            BackupPrivilege
          Computer Setting:  Server Operators
                             Backup Operators

    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:
    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
          COMPANY\Schema Admins
          COMPANY\Domain Admins
          COMPANY\Group Policy Creator Owners
          COMPANY\Enterprise Admins
          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

    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
    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.

      Previous Section Next Section