Managing Authorization and Access Control

The Microsoft Windows XP Professional operating system includes a number of features that you can use to protect selected files, applications, and other resources from unauthorized use. These features, which include access control lists, security groups, and Group Policy, along with the tools that allow you to configure and manage these features, provide a powerful yet flexible access control infrastructure for your local resources and network. Understanding what these features are, why they are necessary, and how they function will help you to manage rights and permissions on network and local resources more effectively.

For information on how to obtain the Windows XP Professional Resource Kit in its entirety, please see https://www.microsoft.com/mspress/books/6795.asp.

Bb457115.3squares(en-us,TechNet.10).gif

On This Page

Related Information
Overview
User Accounts and Security Groups
Using Access Control Lists
Managing User Rights by Using Security Groups
Using Security Policy
Auditing and Analyzing Access Control
Additional Resources

  • For more information about the authentication process and how security contexts are created, see Chapter 16, “Understanding Logon and Authentication” in this book.

  • For more information about implementing security for Windows-based client computers and servers, see the Microsoft Windows Security Resource Kit.

  • For more information about authorization in Active Directory directory service environments, see “Access Control” in the Distributed Systems Guide of the Microsoft Windows 2000 Server Resource Kit.

Overview

Every user and computer has a specific role and purpose in an organization. To accomplish their goals, each user and computer must be able to access certain resources and perform specific tasks. However, allowing users and computers unlimited access to system and network resources and functionality can compromise an organization’s security and stability. The access control infrastructure of Windows XP Professional functions to balance the resource access and system security needs of an organization.

For example, Alice works in Accounting and needs to be able to view—but not create or modify—certain Personnel department files that are off-limits to other users in the organization. The Personnel department, which controls these files, uses access control to define which users can have Read-only access to Personnel files, which users can have Write and Modify access, and which users have no access to the Personnel share. Alice is given Read-only access to the Personnel files. Similarly, IT determines that prohibiting users such as Alice from making significant changes to their systems can reduce costs and improve security and supportability. IT makes Alice and other users members of the Users group, thus limiting their ability to install applications and reconfigure their operating system environments. In this way, Alice has the access to resources that she needs, the security of the organization is enforced, and the stability of the network is maintained.

Important Terms

To understand the basic principles of access control, it is necessary to understand how the following terms are defined in the context of the access control model for Windows XP Professional.

Security principal

In Windows XP Professional, any entity that can be authenticated. A user, group, computer, or service can be a security principal. Security principals have accounts. Local accounts are managed by the Local Security Accounts Manager (SAM) on the computer. If the account is in a Microsoft Windows 2000 or Windows Server™ 2003 domain, it is managed by Active Directory. If the account is in a Microsoft Windows NT version 4.0 domain, it is managed by a SAM database on the primary domain controller.

Security identifier (SID)

A value that uniquely identifies a user, group, service, or computer account within an enterprise. Every account is issued a SID when it is created. Access control mechanisms in Windows XP Professional identify security principals by SID rather than by name.

Security context

Information that describes a particular security principal’s identity and capabilities on a computer. In Windows XP Professional, all users in an organization exist in a specific security context that is redefined every time they log on. All activities, such as installing or running applications, take place in this security context. The security subsystem uses the security context to determine what a process and its threads of execution can do to objects on the computer, and who will be held accountable for what they have done.

Access token

A data structure containing the SID for a security principal, SIDs for the groups that the security principal belongs to, and a list of the security principal’s rights on the local computer. An access token is created for every security principal that logs on locally at the computer or remotely through a network connection. Each process has a primary access token that it inherits by default from its creating process. The access token provides a security context for the security principal’s actions on the computer. It also provides a security context for any application threads that act on the security principal’s behalf.

Object

Any resource that can be manipulated by a program or process. Objects include resources that you can see through the user interface, such as files, folders, printers, registry subkeys and entries, Active Directory objects, and the Microsoft Windows desktop. They also include resources that you cannot see, such as sessions, processes, threads, and access tokens. An object can function as a logical container for other objects.

Inheritance

A mechanism for propagating access control information down through a tree of objects. In Microsoft Windows NT, an object (such as a file) inherits access control information from its parent object (such as a folder) only when the object is first created. In Windows XP Professional, objects inherit access control information not only when they are created, but also when the parent object’s access control list changes.

Owner

The only security principal who has an inherent right to allow or deny permission to access an object. An object’s owner can give another security principal permission to take ownership. By default, the built-in Administrators group on a computer is assigned a user right that allows this group to take ownership of all objects on the computer.

Security groups

Groups that can be used to organize users and domain objects, thus simplifying administration. Security groups allow you to assign the same security permissions to a large numbers of users, such as employees in a single department or in a single location, ensuring that security permissions are consistent across all members of a group.

Security descriptor

A data structure containing the security information associated with a securable object. A security descriptor identifies an object’s owner by SID. If permissions are configured for the object, its security descriptor contains a discretionary access control list (DACL) with SIDs for the users and groups that are allowed or denied access. If auditing is configured for the object, its security descriptor also contains a system access control list (SACL) that controls how the security subsystem audits attempts to access the object.

Access control list (ACL)

An ordered list of access control entries (ACEs) that define the permissions that apply to an object and its properties. Each ACE identifies a security principal and specifies a set of access rights allowed, denied, or audited for that security principal.

Security settings

Security configuration settings that can be applied to individual computers. These settings can be configured locally on the computer by using the Local Security Policy administration tool, the Microsoft Management Console (MMC) Security Configuration and Analysis snap-in, or, if the computer is a member of an Active Directory domain, through the Security Settings extension to Group Policy.

Key Concepts

The security systems in Windows XP Professional are based on technologies originally developed for Windows NT. The access control models in Windows NT, Microsoft Windows 2000, Microsoft Windows Server 2003, and Windows XP Professional share the same key concepts and characteristics, which are described in the following sections.

Discretionary access to securable objects

The user who owns an object has ultimate control over who has permission to use it and in what way. An object’s owner can give permission for different kinds of access to particular users or groups of users. For example, the owner of a file object can give Read and Write permission to all members of one group while denying Write access to members of another group. In Windows XP Professional, owners can Allow or Deny other users access to individual properties of certain types of objects as well as to the entire object. The properties that can be delegated include permissions that Allow or Deny other users access to the object.

Inheritance of permissions

You can control permissions for new objects created in a container object by setting inheritable permissions on the container. The permissions that you set on a container are inherited by existing objects in the container, as well as by newly created objects. For example, the permissions that are set on an NTFS file system folder are inherited by new subfolders and files created within the folder.

Auditing of system events

You can use the auditing feature to detect attempts to circumvent protections on resources or to create an audit trail of administrative actions on the system. For example, you can audit failed attempts to open a file. You can also set security policy so that failed logon attempts are recorded in the security event log. If another administrator changes the auditing policy so that failed logon attempts are no longer audited, the log can record this event as well. In an Active Directory environment, you can use Group Policy to centrally control who is allowed to manage security logs on computers joined to a domain.

Rights and Permissions

Access control involves the configuration of rights and permissions, which apply to both the objects on the local computer or network and the potential users (including individuals, computers, and services) of those objects.

A right is authorization to perform an operation. From an administrator’s point of view, there are two types of rights: privileges and logon rights. In Windows XP Professional, only one user right is inherent—the right to allow or deny access to resources that you own. All other user rights must be granted, which means that they can also be withdrawn.

A permission is authorization to perform an operation on a specific object, such as opening a file. Permissions are granted by owners. If you own an object, you can grant any user or security group permission to do whatever you are authorized to do with it.

When permission to perform an operation is not explicitly granted, it is implicitly denied. For example, if Alice allows the Marketing group, and only the Marketing group, permission to read her file, users who are not members of the Marketing group are implicitly denied access. The operating system will not allow users who are not members of the Marketing group to read the file.

Permissions can also be explicitly denied. For example, Alice might not want Bob to be able to read her file, even though he is a member of the Marketing group. She can exclude Bob by explicitly denying him permission to read the file. In fact, this is exactly how explicit denials are best used—to exclude a subset (such as Bob) from a larger group (such as Marketing) that has been given permission to do something.

Each permission that an object’s owner grants to a particular user or group is stored as part of an ACE in a DACL that is part of the object’s security descriptor.

User-Based Authorization

Every application that a user starts runs in the security context of that user.

When a user logs on, an access token is created. The access token contains key security-related information, including the user’s SID, the SIDs of the groups to which the user belongs, and other information about the user’s security context. This access token is then attached to every process that the user runs during that logon session.

An application runs as a process with threads of execution. When an application performs an operation on a user’s behalf, one of the threads performs the operation. For example, when Alice opens a Word document, Microsoft Word, and not Alice, actually opens the file. More precisely, one of the threads of execution performs the operation.

For a thread to gain access to an object such as a file, it must identify itself to the operating system’s security subsystem. Threads and applications do not have a security identity, so they must borrow one from a security principal, such as Alice. When Alice starts an application, it runs as a process within her logon session. When one of the application’s threads needs to open a file, the thread identifies itself as Alice’s agent by presenting her access token. Alice is therefore ultimately responsible for anything that the thread does to the file or system on her behalf.

Before allowing the thread of execution to proceed, the operating system performs an access check to determine whether the security principal associated with the thread has the degree of access that the thread has requested. This access check involves the following steps:

  1. The security subsystem checks the file object’s DACL, looking for ACEs that apply to the user and group SIDs referenced in the thread’s access token.

  2. If a DACL does not exist, access is granted. Otherwise, the security subsystem steps through the DACL until it finds any ACEs that either allow or deny access to the user or one of the user’s groups.

  3. If a deny is found at the user or group level, the access is denied.

  4. If the security subsystem comes to the end of the DACL and the thread’s desired access is still not explicitly allowed or denied, the security subsystem denies access to the object. Therefore, if a DACL exists but is empty, access is by definition denied.

At the conclusion of this process, access is either allowed and the file is opened or access is denied, in which case the file remains closed and an “Access Denied” message is generated.

Figure 17-1 illustrates this process.

Figure 17-1 Validating a request for access

Figure 17-1 Validating a request for access

In the case of the Personnel files, Alice’s administrators set a DACL on the folders and files that she needs to work with to explicitly define the extent (Read) or limits (not Create or Write) of access that she as an individual or member of a security group has to those files.

Every computer and service on the network also has a security context that governs the resources that it is permitted to access and the actions that it is permitted to take.

Security Descriptors

Access control information is first written to an object’s security descriptor when the object is created. Then, when a user tries to perform an action with the object, the operating system examines the object’s security descriptor to determine whether the user is allowed to do what the user wants to do.

The information that is included in a security descriptor depends on the type of object in question and how it was created. In general, security descriptors can include the following information:

  • Which user owns the object

  • Which users and groups are allowed or denied access to the object

  • Which users’ and groups’ access to the object must be audited

This information can later be modified. In both cases, the information that goes into a security descriptor is supplied by one of the following:

  • The subject

  • The parent object

  • The object manager

When a subject creates a new object, it can assign the object a security descriptor. If the subject does not assign a security descriptor, the operating system uses access control information inherited from the parent object to create one. If no information is available to inherit, the operating system uses default access control information provided by the object manager for the particular type of object that the subject wants to create.

After an object is created, the object’s owner or any user who has the permission to change permissions can change information in the object’s security descriptor. The owner can assign the permission to change permissions to other users. Changes can also come from the parent object when that object’s owner modifies its security descriptor. This process is called inheritance. Every time the security descriptor on a container object is changed, the object manager propagates any changes marked as inheritable to all objects in the container, as long as those objects are not protected. For more information about managing inheritance, see “Modifying Inheritance of Permissions” later in this chapter.

Planning for Effective Access Control

Managing security groups, ACLs, and security settings requires careful planning. Developing an access control plan can help to prevent basic security problems, such as inadequately protected resources, users granted greater rights and permissions than they need to do their jobs, or ad hoc security configurations that are not based on a well-thought-out, manageable security plan. Ad hoc security management might provide adequate protection for small organizations, but it will quickly break down as the organization grows.

Although Windows XP Professional incorporates highly advanced security features, effective access control must combine the proper use of Windows XP Professional–based technologies with good planning. Security features are only as good as the methods used to employ and manage them.

Tip To improve the security of your network, provide each user, computer, and service with the least number of privileges needed to perform their tasks and run their applications. Windows XP Professional includes improved features—including well-defined default security groups, Restricted Software settings, and the Secondary Logon Service (SLS)—to make this possible. For information about SLS, see Chapter 16, “Understanding Logon and Authentication.” For information about Restricted Software settings, see “Software Restriction Policies” later in this chapter.

Consider developing an access control plan that describes how you will use Windows XP Professional features to establish a secure, usable environment. A typical access control plan might include the following sections:

  • Security goals.

    Define the resources and processes that you are protecting.

  • Security risks.

    Enumerate the types of security hazards that affect your enterprise, including what poses the threats and how significant these threats are.

  • Security strategies.

    Describe the general security strategies necessary to meet the threats and mitigate the risks.

  • Security group descriptions.

    Define the security restrictions or permissions that might apply to different groups of users and resources, and then create security groups to help you implement these sets of permissions and restrictions.

  • Security policy.

    If you add your Windows XP Professional–based clients to an Active Directory environment, you can use the Security Settings extension to Group Policy to define and enforce your security strategy on any number of computers.

  • Information security strategies.

    Define how you plan to implement information security solutions, such as an Encrypting File System (EFS), and access authorization by using permissions. For more information about EFS, see Chapter 18, “Using Encrypting File System.”

  • Administrative policies.

    Document policies for delegation of administrative tasks and monitoring of audit logs to detect suspicious activity.

Your access control plan can contain additional sections, but these are suggested as a starting point. If possible, test and revise all aspects of your access control plans by using a test laboratory that closely resembles your organization’s computing environment. Also, conduct pilot deployments to further test and refine your access control plans.

User Accounts and Security Groups

Creating and deleting user accounts and defining and using security groups are important security tasks. Defining the security restrictions or permissions that might apply to different groups of users and resources in your network will help to simplify the implementation and management of the permissions and restrictions in your organization. For example, you can create a Printer Operators group and give it precisely delineated administrative control over a finite group of printers.

For you to effectively manage security groups in your organization, you need to be familiar with the relationship between accounts, security groups, and built-in security principals. It is also important for you to become familiar with the techniques and tools available for managing group membership.

User Account Creation

Every user has an account containing unique credentials that allow the user to access resources on a local computer or domain. Accounts can be local to a computer or domain based. If the account is specific to a local computer, the user will not be able to access network-based resources unless the resources have been configured to allow Anonymous access. If the account is domain based, the user will be able to access network resources from the local computer. However, his or her permissions as a user of network resources might be quite different than his or her rights on the local computer. For more information about how accounts are authenticated, see Chapter 16, “Understanding Logon and Authentication.”

Two user accounts—Administrator and Guest—are created automatically when Windows XP Professional is installed. The Administrator account can be used to initially log on and configure the computer. For example, the Administrator can install software, configure printers, join the computer to a domain, and so on. After the computer has been configured, it is necessary to log on as Administrator only to perform administrative tasks.

Tip It is best if the Administrator account has a password that meets complexity requirements. You can also rename the Administrator account to make it more difficult for potential hackers to gain access to your system.

The Guest account can be used to allow different users to log on and access local resources without having to create an account for each user. The Guest account can also be enabled to simplify file and printer sharing with other Windows-based computers that are configured in a workgroup environment. Otherwise, it is recommended that you disable the Guest account.

Except for the Administrator and Guest accounts, local user accounts are not created automatically when Windows XP Professional is installed. Instead, local user accounts must be created by a member of the Administrators group after the installation is complete. In turn, only domain-level Administrators and Account Operators can create domain accounts.

User accounts—which include information such as the user’s name, alias, password, and unique security identifier (SID)—enable users to log on to the network or local computer and to access local and network resources. Any domain or local user can then manage permissions on resources on the local computer—as long as the user has change permission rights on the resource.

To create, delete, and manage user accounts, administrators can use User Accounts in Control Panel, the Local Users and Groups snap-in to the Microsoft Management Console (if the user account is local to a particular computer), or the Active Directory Users and Computers snap-in (if the account is to participate in a domain). For more information about creating, deleting, and managing user accounts, see “Local Users and Groups” in Windows XP Professional Help and Support Center.

Types of Security Groups

User accounts are also members of security groups. Depending on the organizational environment, groups used to administer security can be defined by their scope, their purpose, their rights, or their role. The scope of a security group can be a single computer, a single domain, or multiple domains within a forest. In general, Windows 2000, Windows Server 2003, and Windows XP Professional groups fall into one of several categories.

Computer local groups

Computer local groups are security groups that are specific to a computer and are not recognized elsewhere in the domain. These groups are a primary means of managing rights and permissions to resources on a local computer.

Domain local groups

Domain local groups are local to the domain in which they are created, and thus can be given permissions and user rights only to objects on computers within the domain.

Global groups

Global groups, which are also created on domain controllers, are used for combining users who share a common access profile based on job function or business role. Global groups can contain user accounts from the same domain and other global groups from the same domain, and they can be granted permissions to any computer running Windows NT 4.0, Windows 2000, Windows Server 2003, or Windows XP Professional in any domain in a forest.

Universal groups

Universal groups are used in larger, multidomain organizations where there is a need to grant access to similar groups of accounts defined in multiple domains in a forest. Universal groups are used only in multiple domain trees or forests that have a global catalog. They can contain groups from any Active Directory domain, and they can be used to grant access on any computers running Windows 2000, Windows Server 2003, or Windows XP Professional in any domain in the forest.

Built-in security principals

Built-in security principals, also called special identities, apply to any account that is using the computer in specified ways, such as for Anonymous and Remote logons. Unlike the other types of security groups, built-in security principals do not have specific memberships that you can view or modify, nor do you even see them when you administer groups. However, they are available for use when you assign rights and permissions to group members.

The scope of a group determines where in the network you are able to use the group and assign permissions, and the amount of network traffic the group creates. Using the most appropriate group for a task simplifies administration and, in a domain environment, reduces network traffic by reducing the amount of replication required. The following sections discuss the computer local and special identity groups in greater detail.

Computer Local Security Groups

Windows XP Professional includes a number of built-in computer local security groups. You can manage the membership of these groups by using the Local Users and Groups snap-in to the Microsoft Management Console (MMC) or by using User Accounts in Control Panel. However, if you are using Windows XP Professional in a stand-alone or workgroup configuration, by using User Accounts in Control Panel you can manage only three of these built-in security groups—Administrators, Users (which are also referred to as Limited users), and Guests. If you are using Windows XP Professional in a stand-alone or workgroup configuration and want to use other security groups in addition to these three, you need to manage them from the Local Users and Groups snap-in.

The following sections describe the roles and privileges associated with each computer local security group.

Administrators

Members of this group have total control of the local computer. The default Windows XP Professional security settings do not restrict administrative access to any registry object or file system object. Administrators can perform any and all functions supported by the operating system. Any right that Administrators do not have by default, they can grant to themselves.

Warning If a hacker or virus gains access to a computer while a member of the Administrators group is logged on, the hacker or virus can use the administrator’s security context to perform any task on the local computer—or, in the case of a network administrator, on the network—that the administrator can perform. Impress upon all members of the Administrators group the importance of minimizing the amount of time that they are logged on with these privileges.

Default members of the local Administrators group include the first account created on a clean installation, existing members of the local Administrators group in an upgrade, and members of the Domain Administrators group in a domain environment. Administrators can create or delete user accounts and modify permissions for users and resources. Administrative access to the system is ideally used only to:

  • Install the operating system and components (including drivers for hardware, system services, and so forth).

  • Install service packs and software updates.

  • Install Windows updates.

  • Upgrade the operating system.

  • Repair the operating system.

  • Configure critical computer-wide operating system parameters.

  • Take ownership of objects.

In some cases, administrative accounts must also be used to install and run legacy Windows-based applications.

Tip Limit the membership of the Administrators group. The greater the number of members in the Administrators group, the greater the number of accounts that a hacker or virus can potentially use to gain access to a computer.

Backup Operators

Members of this group can back up and restore files on the computer, regardless of the permissions that protect those files. They can also log on to the computer and shut it down, but they cannot change security settings.

Guests

By default, members of the Guests group are denied access to the application and system event logs. Otherwise, members of the Guests group have the same access rights as members of the Users group. This allows occasional or one-time users to log on to a workstation’s built-in Guest account and be granted limited abilities. Members of the Guests group can also shut down the system.

Note The Guest account, which is a member of the Guests group by default, is not an authenticated user. When logged on interactively, the Guest account is a member of both the Guests group and the Users group. However, when logged on over the network, the Guest account is not a member of the Users group.

HelpServicesGroup

Members of this group can use helper applications to diagnose system problems. This group, in conjunction with the Support and HelpAssistant accounts, can be used by members of Microsoft Help and Support Center to access the computer from the network and to log on locally.

Network Configuration Operators

Members of this group have limited administrative privileges that allow them to configure networking features, such as IP address assignment.

Power Users

Power Users have less system access than Administrators but more than Users. By default, members of this group have Read/Write permissions to other parts of the system in addition to their own profile.

The default security settings for Power Users are backward compatible with the default security settings for Users in the Windows NT 4.0 operating system. This allows Power Users to run legacy applications that are not certified for Windows XP Professional and therefore cannot be run under the more secure Users context.

Power Users can perform many system-wide operations, such as changing system time and display settings, and creating user accounts and shares. Power Users also have Modify access to:

  • HKEY_LOCAL_MACHINE\Software

  • Program files

  • %windir%

  • %windir%\System32

Although Power Users have Modify access to the %windir% and %windir%\System32 directories, they have Read-only access to the files that are installed in these directories during Windows XP Professional text-mode setup. This allows noncertified applications to write new files into the system directories but prevents Power Users from modifying the Windows XP Professional system files.

While Power Users have the permissions necessary to install most applications, not all application installations will succeed. For example, many applications check for explicit membership in the Administrators group before installing. Other applications attempt to replace operating system files, which Power Users cannot do. Finally, because Power Users cannot install services, they cannot install applications that have a service component.

To install local printer drivers, you need to be a member of the Power Users or Administrators group and have the Load and unload device drivers privilege assigned to you.

To add the Load and unload device drivers privilege for Power Users

  1. In Control Panel, click Performance and Maintenance, click Administrative Tools, and then double-click Local Security Policy.

  2. In the console tree, double-click Local Policies, and then double-click User Rights Assignment.

  3. In the right pane, right-click the Load and unload device drivers policy, and then click Properties.

  4. Click Add, enter the Power Users group, and then click OK.

Like Users, Power Users are not allowed to access data stored in other users’ profiles.

Replicator

Members of this group are allowed to replicate files across a domain.

Remote Desktop Users

Members of this group have the right to log on remotely.

Users

Unlike Administrators, Users have limited access on the system. By default, members of the Users group have Read/Write permissions only to their own profile.

Note Users are referred to as Limited users in stand-alone or workgroup installations of Windows XP Professional when viewed in User Accounts in Control Panel.

User security settings are designed to prohibit members of the Users group from compromising the integrity of the operating system and installed applications. Users cannot modify computer-wide registry settings, operating system files, or program files, and they cannot install applications that can be run by other Users. As a result, the Users group is secure to the extent that members also cannot run viruses or Trojan horse applications that affect the operating system or other users of the operating system.

Note Users can install peripherals, such as printers, only if the following three conditions are met: The driver package is already present on the system or available via a trusted path, the driver package is signed, and the driver package can be installed without any user interface. For more information about installing printers with Windows XP Professional, see Chapter 11, “Enabling Printing and Faxing.” For more information about installing other peripherals, see Chapter 9, “Managing Devices,” and Chapter 7, “Supporting Mobile Users.”

Only applications that are certified for Windows XP Professional under the Designed for Windows XP logo program are guaranteed to run successfully under the secure Users context. Many legacy applications were not designed with operating system security in mind, and as a result, members of the Users groups cannot run them.

The best way to increase the security and manageability of the operating system is to make all end users members of the Users group only, and deploy only applications that are certified for Windows XP Professional. For more information on the Designed for Windows XP logo program, see the Windows Catalog at https://www.microsoft.com/windows/catalog.

Warning To ensure that users can run all the applications they need to run, it is recommended that you test all your applications at the privilege levels of the users who need to run them.

About the Program Compatibility Wizard

Windows XP Professional includes a Program Compatibility Wizard that allows Users to run applications in a security context appropriate for legacy applications. Using the Program Compatibility Wizard, users can specify that individual applications run in a security context appropriate to the following operating systems:

  • Microsoft Windows 95

  • Windows NT 4.0 (Service Pack 5)

  • Microsoft Windows 98 or Microsoft Windows Millennium Edition (Me)

  • Windows 2000

    Caution The Program Compatibility Wizard is not intended to make it possible to run operating system–specific applications such as antivirus or backup software. Doing so can damage important system files and cause serious problems.

To open the Program Compatibility Wizard
  • Click Start, All Programs, Accessories, and then Program Compatibility Wizard.

For more information about using the Program Compatibility Wizard, see article 301911, “How to use the Program Compatibility Wizard in Windows XP,” in the Microsoft Knowledge Base at https://support.microsoft.com.

Domain Local Security Groups

Domain local versions of all groups except the Power Users and HelpServices groups—plus a number of additional server-specific built-in groups—are included on domain controllers. Users’ access to the local computer and network depends primarily on the computer local and domain local security groups to which their account belongs. In other words, users’ accounts identify who they are, and in some cases permissions and restrictions are set on an individual basis. However, the security groups to which the user belongs are primarily responsible for determining what permissions and restrictions govern his or her activities on the local computer and on the network.

For more information about the rights and permissions of computer local groups, see “Managing User Rights by Using Security Groups” later in this chapter.

Built-In Security Principals

Built-in security principals apply to any account that is using the computer in a specified way. Built-in security principals allow you to configure security based on the manner in which a resource is being accessed.

The following built-in security principals apply to any user account that is using a computer running Windows XP Professional in the ways specified:

Note Several additional built-in security principals are available on computers running Windows 2000 Server.

  • Anonymous Logon.

    Network logons for which credentials are not provided. Users cannot log on anonymously and interactively at the same time.

  • Authenticated Users.

    Any user, except a user of the Guest account, who is authenticated locally by a trusted domain controller. This identity provides users with the rights necessary to operate the system as an end user. (The Guest account is never treated as an Authenticated User.)

  • Creator Group.

    A placeholder in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID for the primary group of the object’s current owner.

  • Creator Owner.

    A placeholder in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID of the object’s current owner.

  • Dialup.

    Any user who accesses the computer over a dial-up connection.

  • Everyone.

    All users who access the computer, including Guests and Users from other domains. By default, Everyone includes Authenticated Users and Guests, but not Anonymous logons.

  • Interactive.

    Any user who logs on locally.

  • Network.

    Any user who logs on over the network.

  • Remote Interactive Logon.

    All users who log on to the computer by using a Remote Desktop connection.

  • Terminal Server User.

    Any user who accesses the computer by using a terminal server session.

The following security principals apply to any nonhuman user that is using the computer in a specified way:

  • Batch.

    Any batch process that is accessing a resource on the computer.

  • Local Service.

    Services that are local to the computer, have no need for extensive local privileges, and do not need authenticated network access. A service running as Local Service has significantly less authority than a service running as System, both locally and on the network. When services running as Local Service access local resources, they do so as members of the local Users group. When they access network resources, they do so as Anonymous users.

  • Network Service.

    Services that have no need for extensive local privileges but do need authenticated network access. A service running as Network Service has the same network access as a service running as System, but it has significantly reduced local access. When services running as Network Service access local resources, they do so as members of the local Users group. When they access network resources, they do so using the SID assigned to the computer.

  • Service.

    Any service.

  • System.

    The operating system.

Built-in security principals are used to manage the rights and restrictions that apply to users based on the type of logon session they have initiated. For example, suppose there is a file or share that you want Alice to be able to access—but only when she is logged on interactively. You can accomplish this by allowing Alice access to the resource but denying access to requests accompanied by access tokens that include the Dialup security principal.

The following security principles are available when a computer running Windows XP Professional is a member of a domain:

  • Enterprise Domain Controllers.

    Includes all domain controllers in a forest of domains.

  • Restricted.

    An identity used by a process that is executing in a restricted security context. When code executes at the restricted security level, the Restricted SID is added to the user’s access token.

  • Self.

    A placeholder in an ACE on a User, Group, or Computer object in Active Directory. When you grant permissions to Self, you grant these permissions to the security principal represented by the object. During an access check, the operating system replaces the SID for Self with the SID for the security principal represented by the object.

    Warning It is recommended that you not remove or change the permissions that pertain to the built-in security principals themselves.

Memberships Associated with Default Groups

In Windows NT 4.0, the Everyone group is used as a catchall for file system ACLs, registry ACLs, and user rights. An administrator cannot define who does and does not belong to the Everyone group. Instead, Windows NT 4.0 automatically controls the group membership so that everyone is a member of the Everyone group. If an administrator wants more granular access control, the default ACLs have to be modified in order to remove the Everyone group and add groups that the administrator can control.

In Windows 2000 and later, groups whose membership is automatically configured by the operating system, such as Everyone and Authenticated Users, are not used to assign permissions to file and registry objects. Only those groups whose membership can be controlled by an administrator—primarily Users, Power Users, and Administrators—are used to assign permissions. When users are members of a group, they automatically have the permissions that have been assigned to that group.

The users that constitute the default memberships in these groups are listed in Table 17-1.

Table 17-1 Default Group Memberships

Local Group

Default Workstation Members

Administrators

Administrator

Power Users

None

Users

Authenticated Users, Interactive

With a clean installation of Windows XP Professional, the Authenticated Users group and the Interactive group are added to the Users group. Thus, by default, any nonadministrative user accessing a Windows XP Professional–based system interactively is a member of the Users group. Because the Guest account and Anonymous logons are not considered to be authenticated, these users do not receive User-level access over the network.

On upgrades from Windows NT 4.0, the Interactive users group is added to the Power Users group. Because Windows XP Professional Power Users have the same file system and registry permissions that Windows NT 4.0 Users have, the Interactive group on Windows XP Professional–based computers that were upgraded from Windows NT 4.0 can run any application that Windows NT 4.0 Users could run.

Deploying certified applications and then removing Interactive from the Power Users group secures a Windows XP Professional–based workstation that was upgraded from Windows NT 4.0. In this way, nonadministrators who log on will be subject to the secure permissions granted to the Users group without having to change any file or registry ACLs.

For more information about security group permissions on systems that have been upgraded, see “Managing User Rights by Using Security Groups” later in this chapter.

Well-known SIDs

SIDs are associated with a user’s account, security groups, and security principals. Most of these SIDs are unique. However, the values of some specific SIDs are constant across all systems. These are called well-known SIDs because they identify generic users or generic groups. For example, well-known SIDs identify the following users and groups:

  • Everyone (S-1-1-0).

    The identifier authority value for this SID is 1 (World Authority). It has only one subauthority value, 0 (Null relative identifier (RID)).

  • Creator Owner (S-1-3-0).

    The generic user Creator Owner is a placeholder in an inheritable ACE. When the ACE is inherited, the system replaces the SID for Creator Owner with the SID for the object’s current owner. The identifier authority value for this SID is 3 (Creator Authority). It has only one subauthority value, 0 (Null RID).

  • Self (S-1-5-10).

    The generic user Self is a placeholder in an ACE on a User, Group, or Computer object in Active Directory. When you grant permission to Self, you grant it to the security principal represented by the object. During an access check, the operating system replaces the SID for Principal Self with the SID for the security principal represented by the object. The identifier authority for this SID is 5 (NT Authority). It has only one subauthority value, 10 (Self RID).

For information about other well-known SIDs, see the appendix “Well-Known Security Identifiers” in the Distributed Systems Guide. See also article 243330, “Well Known Security Identifiers in Windows Server Operating Systems,” in the Microsoft Knowledge Base at
https://support.microsoft.com/kb/243330.

Using Whoami

The Whoami utility, which is available in the \Support\Tools directory on the Windows XP Professional operating system CD, allows you to view the rights and permissions that apply to an individual user. This command-line tool returns the domain or computer name and the user name of the user who is currently logged on to the computer on which the tool is run, as well as the complete contents of the current user’s access token. It displays the user name and security identifiers (SIDs), the groups and their SIDs, the privileges and their status (for example, enabled or disabled), and the logon ID.

Note To install Whoami, double-click Setup.exe in the \Support\Tools directory on the Windows XP Professional operating system CD. Then complete the steps in the Support Tools Setup Wizard to complete the installation.

To view an individual’s user rights and permissions

  • At the command line, type Whoami

    You can use the following command-line options to customize the results you receive from whoami:

    • /ALL. Displays all information in the current access token.

    • /USER. Displays the user identified in the current access token.

    • /GROUPS. Displays groups listed in the current access token.

    • /PRIV. Displays privileges associated with the current access token.

    • /LOGONID. Displays the logon ID used for the current session.

    • /SID. Displays the SIDS associated with the current session (must be used in combination with the /USER, /GROUPS, /PRIV, or /LOGONID switches).

    • /NOVERBOSE. Displays minimal information (must be used in combination with the /USER, /GROUPS, /PRIV, or /LOGONID switches).

For example, on a clean installation of Windows XP Professional, whoami used with the /GROUPS option reveals that an Administrator user belongs to the following default groups:

Everyone 
Builtin/Administrators 
NT Authority/Users 
Local 
NT Authority/Interactive 
NT Authority/Authenticated Users

A Standard or Power User who runs whoami would generate the following group results:

Everyone 
Builtin/Power Users 
NT Authority/Users 
Local 
NT Authority/Interactive 
NT Authority/Authenticated Users

A member of the Limited or Users group who runs whoami would generate the following group results:

Everyone 
NT Authority/Users 
Local 
NT Authority/Interactive 
NT Authority/Authenticated Users

When used with the /USER /SID switches, whoami also allows you to identify the unique security identifiers that are associated with a given logon session, as the following output illustrates:

Note: The following code snippet has been displayed in multiple lines only for better readability. These should be entered in a single line.

 [User]= "HQ-RES-PRO-01\Limited" 
S-1-5-21-1454471165-1645522239-1547161642-1009

Managing Permissions by Nesting Groups

Nesting groups, or adding groups to other groups, can reduce the number of permissions that need to be assigned to users or groups individually. As you assign members of your organization to global groups to apply security settings based on a user’s job or business unit, you can nest the groups into the Users and Power Users groups, and in this way apply the security settings that are inherent to Users and Power Users to the members of the global groups contained within them.

For example, Alice and other employees in the Accounting department can be added to a group that is specific to that department. An administrator responsible for the Accounting department can control the membership of this group. The administrator can assign organization-wide security permissions to these users by making the Accounting department security group a member of the Users domain local group. The administrator thus only needs to configure the Accounting department security group to allow members access to the resources specific to the Accounting department.

This also facilitates the management of employees who are reassigned within an organization. It is much easier, for example, to move a user from the Accounting security group to the Marketing group than it is to reconfigure the many ACEs and ACLs required to permit the user to access the resources needed to perform the new job, and remove access to resources the user no longer needs.

Nesting Groups in Domain Environments

The process of creating groups across domains involves the following steps:

  • Administrators in each domain create global groups and add user accounts that have the same resource requirements to the global groups.

  • A domain administrator creates a domain local group for each resource that exists within a domain, such as file shares or printers, and then adds the appropriate global groups from each domain to this domain local group.

  • A domain administrator assigns the appropriate permissions for the resource to the domain local group. Users in each global group receive the required permissions because their global group is a member of the domain local group.

Effectively nesting groups in a multidomain environment reduces network traffic between domains and simplifies administration in a domain tree. The extent to which you can use nesting in your organization depends on whether you are operating in mixed mode or in native mode. In Windows 2000 mixed mode (which corresponds to Windows 2000 mixed functional level in domains running Windows Server 2003), only one type of nesting is available: global groups can be members of domain local groups. Universal groups do not exist in mixed mode. In Windows 2000 native mode (which corresponds to Windows 2000 native functional level or higher in domains running Windows Server 2003), multiple levels of nesting are available. The nesting rules for group memberships for Windows 2000 native mode domains (Windows 2000 native functional level or higher in domains running Windows Server 2003) are listed in Table 17-2.

Table 17-2 Nesting Rules for Group Memberships

Group Scope

Can contain

Can be a member of

Domain Local Group

User accounts, and universal and global groups from any trusted domain

Domain local groups from the same domain

Domain local groups in the same domain

Global Group

User accounts and global groups from the same domain

Universal and domain local groups in any domain

Global groups in the same domain

Universal Groups

User accounts, and universal and global groups from any domain

Domain local or universal groups in any domain

Using Access Control Lists

If you configure ACLs for resource groups or security groups and add or remove users or resources from the appropriate groups when your organization changes, it is easier to control and audit user rights and permissions and it reduces the need to change ACLs.

There are two types of ACLs—discretionary access control lists (DACLs), which identify the users and groups that are allowed or denied access, and system access control lists (SACLs), which control how access is audited. For more information about the use of SACLs, see “Auditing and Analyzing Access Control” later in this chapter.

Viewing ACLs

The access control list for an object is generally found on the Security tab of the object’s property sheet. This tab lists the groups and users that have access to this object, and it provides a summary of the permissions allowed to each group.

Note The Security tab for an object can be viewed only by users who have the appropriate permissions on the object. In addition, users on computers running Windows XP Professional in stand-alone or workgroup environments will not be able to view the security tab if simple file sharing has been enabled. For more information about simple file sharing, see “Managing Network Authentication” later in this chapter.

Figure 17-2 shows the Properties page with a number of ACEs visible.

Figure 17-2 Security Properties page for a Windows folder

Figure 17-2 Security Properties page for a Windows folder

The Group or user names box lists the security principals that have permissions assigned for this resource. The Permissions for box lists the permissions allowed or denied for the security principal highlighted in the Group or user names box. The Add and Remove buttons allow you to add new security principals for this resource or to delete existing principals from the list.

Note Generally, the Group or user names box includes the resolved network names for the security principal. If the name does not resolve—if the computer is disconnected from the network, for example—the user or group’s SID might appear instead.

To view the Security tab on your system
  1. Right-click an object such as a file, folder, or printer, and select Properties

  2. Click the Security tab.

Clicking the Advanced button opens the Advanced Security Settings page, which provides additional information about the permissions that apply to a user or group.

Figure 17-3 shows an example of an Advanced Security Settings page.

Figure 17-3 Advanced Security Settings for the Windows folder

Figure 17-3 Advanced Security Settings for the Windows folder

The Advanced Security Settings page allows you to use more advanced features for granting permissions, such as:

  • Modifying special permissions that apply to each user or group

  • Modifying access inheritance options for the object and any child objects

  • Auditing attempts to access the object

  • Modifying ownership information for the object and any child objects

  • Viewing effective permissions

    Note As long as settings are inherited from a parent object rather than explicitly defined on the object you are assessing, you have to go back to the source ACL to change access control settings on the child object.

The Permissions tab shows permissions that have been explicitly configured on the object, permissions that have been inherited, where inherited permissions are inherited from, and what child objects they apply to. A new advanced option in the Windows XP Professional, the Effective Permissions tab, allows you to see all the permissions that apply to a security principal for a given object, including the permissions derived from memberships in security groups. The Effective Permissions tab is illustrated in Figure 17-4.

Figure 17-4 Effective Permissions tab

Figure 17-4 Effective Permissions tab

To view the Effective Permissions for a user or group
  1. On the Effective Permissions tab, click the Select button to open the Select User or Group dialog box.

  2. In the Name box, type the name of the built-in security principal, group, or user, for which you would like to view Effective Permissions.

    – or –

    Click the Object Types button, and then select Built-in security principals, Groups, or Users.

  3. Click OK.

    Tip If the security principal is network based, you can click Locations and select a target, or you can type in the domain name together with the group name, such as reskit\users.

It is important to specify the correct object types and the locations for your search. Failure to do so will result in an error message and the suggestion that you refine your search before searching again.

Access Control Entries

Access control lists contain a wide variety of ACEs that can be viewed on the Permissions and Effective Permissions tabs. All ACEs include the following access control information:

  • A SID that identifies a user or group, such as Alice, the Accounting department, or users in the Denver office

  • A list of special permissions that specify access rights, such as List Folder/Read Data

  • Inheritance information that determines whether new files created in a particular folder will receive access permissions from the parent folder

  • A flag that indicates whether the ACE is an Allow or Deny ACE

To view a specific ACE
  1. Navigate to the Advanced Security Settings page for the file, folder, or object.

  2. Double-click the entry or entries you want to view in the Permission entries box.

Figure 17-5 shows the ACE that the Users group has for the Windows folder.

Figure 17-5 ACE that the Users group has for the Windows folder

Figure 17-5 ACE that the Users group has for the Windows folder

How Access Control Is Applied to New Objects

The operating system uses the following guidelines to set the DACL in the security descriptors for most types of new securable objects:

  1. The new object’s DACL is the DACL from the security descriptor specified by the creating process. The operating system merges any inheritable ACEs from the parent object into the DACL.

  2. If the creating process does not specify a security descriptor, the operating system builds the object’s DACL from inheritable ACEs in the parent object’s DACL. For example, in the case of a new file, this might be the inheritable ACEs from the folder in which the file is being created.

  3. If the parent object has no inheritable ACEs—for example, if the file is being created in the root directory—the operating system asks the object manager to provide a default DACL.

  4. If the object manager does not provide a default DACL, the operating system checks for a default DACL in the access token belonging to the subject (the user, for example).

  5. If the subject’s access token does not have a default DACL, the new object is assigned no DACL, which allows Everyone unconditional access.

    Warning Failure to set DACLs or setting DACLs improperly might have undesirable consequences. For example, an empty DACL, where neither Allow nor Deny has been configured, denies access to all accounts. On the other hand, if there is no DACL then all accounts have full access.

Modifying Inheritance of Permissions

Inheritance is one of the primary tools for managing access control. By default, permissions assigned to a parent folder are inherited by the subfolders and files that are contained in the parent folder. You can block inheritance, however, so that permission changes made to parent folders will not affect child folders and files. This is useful when permissions on individual files need to be more restrictive than the permissions that apply to a parent folder, for example.

To block permission changes made to parent folders from affecting child folders and files
  1. Open the Advanced Security Settings page for the file or folder.

  2. Click the Permissions tab.

  3. Clear the Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here check box.

  4. Click OK.

Permissions can also be denied. By denying a user or group permission to a folder or file, you are denying a specific level of access regardless of the other permissions assigned to the user or group. Even if a user has access permissions to the file or folder as a member of one group, denying permission to the user as a member of a second group blocks any other permissions the user has.

Managing Ownership Permissions

You can take ownership of a resource if you are a member of the Administrators group. It is important for administrators to take full ownership or reassign ownership for key resources so that if an employee creates a resource—such as a file share—and then leaves the organization, that resource remains accessible.

To view the ownership information associated with a resource
  1. Right-click the file or folder, and select Properties from the secondary menu.

  2. On the Security tab, click the Advanced button to view the Advanced Security Settings of the resource.

  3. Click the Owner tab.

    Note You must have Read permission on the object to view ownership data.

Figure 17-6 shows the Owner tab.

Figure 17-6 Owner tab

Figure 17-6 Owner tab

Every object has an owner, usually the user who created the object. The owner has an implied right to Allow or Deny other users permission to use the object. This right cannot be withdrawn. Owners can give other users permission to Change Permissions (WRITE_DAC). This permission, unlike the owner’s inherent right, can be withdrawn.

By default, a new object’s owner is the security principal identified as the default owner in the access token attached to the creating process. When an object is created, the SID stored in the access token’s Owner field is copied to the security descriptor’s Owner field. The default owner is normally an individual—the user who is currently logged on.

In Windows XP Professional, you can use Group Policy to modify this rule of object ownership as it pertains to members of the Administrators group. The Group Policy option allows you to reassign ownership of objects created by members of the Administrators group to all members of the group rather than to the individual who created the object.

To make the Administrators group the owner of all objects created by its members
  1. In Control Panel, click Performance and Maintenance, click Administrative Tools, and then double-click Local Security Policy.

  2. Under Security Settings, double-click Local Policies, and then click Security Options.

  3. Double-click the policy System objects: Default owner for objects created by members of the administrators group.

  4. In the drop-down list box, select Administrators group, and then click OK.

Owners of NTFS objects can allow another user to take ownership by giving that user Take Ownership permission. In addition, certain users can take ownership without having permission if they have been assigned the Take ownership of files or other objects (SeTakeOwnershipPrivilege) privilege. By default, this privilege is assigned only to the Administrators group.

Determining ownership of objects

You can use the dir command to determine the owners of objects in a share or folder. At the command line, type the dir command using the following syntax:

dir /q [share or folder name]

Default Permissions

Windows XP Professional offers a very fine degree of security control over access to a wide variety of objects. A local file folder, for example, has 14 available permissions, beginning with Read, Write, Modify, and Delete. Both basic and special permissions are available for files and folders.

Basic File and Folder Permissions

The number and type of permissions that are available for any object depend on the security context of the object. For example, the following permissions are available for folders on NTFS partitions:

  • Read.

    Allows a user to see the files and subfolders in a folder and view folder attributes, ownership, and permissions.

  • Write.

    Allows a user to create new files and subfolders with the folder, change folder attributes, and view folder ownership and permissions.

  • List Folder Contents.

    Allows a user to see the names of files and subfolders in the folder.

  • Read & Execute.

    Gives a user the rights assigned through the Read permission and the List Folder Contents permission. It also gives the user the ability to traverse folders. Traverse folders rights allow a user to reach files and folders located in subdirectories even if the user does not have permission to access portions of the directory path.

  • Modify.

    Gives a user the ability to delete the folder and perform the actions permitted by the Write and Read & Execute permissions.

  • Full Control.

    Allows a user to change permissions, take ownership, delete subfolders and files, and perform the actions granted by all other permissions.

The following basic permissions apply to files on NTFS partitions:

  • Read.

    Allows a user to read a file and view file attributes, ownership, and permissions.

  • Write.

    Allows a user to overwrite a file, change file attributes, and view file ownership and permissions.

  • Read & Execute.

    Gives a user the rights required to run applications and perform the actions permitted by the Read permission.

  • Modify.

    Gives a user the ability to modify and delete a file and perform the actions permitted by the Write and Read & Execute permissions.

  • Full Control.

    Allows a user to change permissions, take ownership, and perform the actions granted by all other permissions.

    Note Share permissions for NTFS volumes work in combination with file and directory permissions. By default, in Windows 2000 the permissions for a new share on an NTFS partition allow Everyone Full Control. In Windows XP, the default permissions for a new share have been tightened to Everyone Read for added security.

Advanced File and Folder Permissions

A number of more detailed permissions are available when you click the Advanced button on the Properties page; select a user, group, or security principal; and then click Edit. These permissions include:

  • Traverse Folder/Execute File.

    Allows or denies moving through folders to reach other files or folders even if the user has no permissions to the folders being traversed. (The permission applies only to folders.) Traverse Folder takes effect when a group or user is not granted the Bypass Traverse Checking user right in the Group Policy snap-in. (By default, the Everyone group is given the Bypass Traverse Checking user right.) The Execute File permission allows or denies running program files. (The permission applies only to files.)

    Note Setting the Traverse Folder permission on a folder does not automatically set the Execute File permission on all files within that folder.

  • List Folder/Read Data.

    Allows or denies viewing filenames and subfolder names within the folder. (The permission applies only to folders.) The Read Data permission allows or denies viewing data in files. (The permission applies only to files.)

  • Read Attributes.

    Allows or denies viewing the attributes of a file or folder (for example, the read-only and hidden attributes). Attributes are defined by NTFS.

  • Read Extended Attributes.

    Allows or denies viewing the extended attributes of a file or folder. Extended attributes are defined by programs and can vary by program.

  • Create Files/Write Data.

    Allows or denies creating files within the folder. (The permission applies only to folders.) Also, the Write Data permission allows or denies making changes to the file and overwriting existing content. (The permission applies only to files.)

  • Create Folders/Append Data.

    Allows or denies creating folders within the folder. (The permission applies only to folders.) The Append Data permission allows or denies making changes to the end of the file but not changing, deleting, or overwriting existing data. (The permission applies only to files.)

  • Write Attributes.

    Allows or denies changing the attributes of a file or folder.

  • Write Extended Attributes.

    Allows or denies changing the extended attributes of a file or folder. Extended attributes are defined by programs and might vary by program.

  • Delete Subfolders and Files.

    Allows or denies deleting subfolders and files, even if the Delete permission has not been granted on the subfolder or file.

  • Delete.

    Allows or denies deleting the file or folder. If you don’t have Delete permission on a file or folder, you can still delete it if you have been granted Delete Subfolders and Files permission on the parent folder.

  • Read Permissions.

    Allows or denies reading permissions of a file or folder, such as Full Control, Read, and Write.

  • Change Permissions.

    Allows or denies changing permissions on the file or folder, such as Full Control, Read, and Write.

  • Take Ownership.

    Allows or denies taking ownership of a file or folder. The owner of a file or folder can always change permissions on it, regardless of any existing permissions that protect the file or folder.

Many advanced permissions are already configured when you select certain basic permissions. As a result, in general, you do not need to manually configure advanced permissions to benefit from them. For example, Table 17-3 illustrates the links between basic and advanced permissions for folders.

Table 17-3 Advanced Folder Permissions

Special Permissions

Full Control

Modify

Read & Execute

List Folder Contents

Read

Write

Traverse Folder/Execute File

Yes

Yes

Yes

Yes

No

No

List Folder/Read Data

Yes

Yes

Yes

Yes

Yes

No

Read Attributes

Yes

Yes

Yes

Yes

Yes

No

Read Extended Attributes

Yes

Yes

Yes

Yes

Yes

No

Create Files/Write Data

Yes

Yes

No

No

No

Yes

Create Folders/Append Data

Yes

Yes

No

No

No

Yes

Write Attributes

Yes

Yes

No

No

No

Yes

Write Extended Attributes

Yes

Yes

No

No

No

Yes

Delete Subfolders and Files

Yes

No

No

No

No

No

Delete

Yes

Yes

No

No

No

No

Read Permissions

Yes

Yes

Yes

Yes

Yes

No

Change Permissions

Yes

No

No

No

No

No

Take Ownership

Yes

No

No

No

No

No

Table 17-4 illustrates the links between basic and advanced permissions for files.

Table 17-4 Advanced File Permissions

Special Permissions

Full Control

Modify

Read & Execute

Read

Write

Traverse Folder/Execute File

Yes

Yes

Yes

No

No

List Folder/Read Data

Yes

Yes

Yes

Yes

No

Read Attributes

Yes

Yes

Yes

Yes

No

Read Extended Attributes

Yes

Yes

Yes

Yes

No

Create Files/Write Data

Yes

Yes

No

No

Yes

Create Folders/Append Data

Yes

Yes

No

No

Yes

Write Attributes

Yes

Yes

No

No

Yes

Write Extended Attributes

Yes

Yes

No

No

Yes

Delete

Yes

Yes

No

No

No

Read Permissions

Yes

Yes

Yes

Yes

No

Change Permissions

Yes

No

No

No

No

Take Ownership

Yes

No

No

No

No

Note File and folder security permissions are available only with the NTFS file system. File and folder permissions are not available with the FAT or FAT32 file systems.

Applying Folder and Share Permissions at Setup

Default NTFS file and folder permissions for the installation partition are applied during setup by the Security Configuration Manager using the Setup security template (Setup security.inf).

The Security Configuration Manager also secures the root directory during setup if the current root security descriptor grants Everyone Full Control. This is a change from Windows NT and provides increased security for non-Windows directories that are created off of the root. Because of the ACL inheritance model, any non-Windows subdirectories that inherit permissions from the root directory will also be modified during setup. The new Windows XP Professional root ACL (also implemented by Format and Convert) is as follows:

  • Administrators, System: Full Control (Container Inherit, Object Inherit)

  • Creator Owner: Full Control (Container Inherit, Object Inherit, Inherit Only)

  • Everyone: Read & Execute (No Inheritance)

  • Users: Read & Execute (Container Inherit, Object Inherit)

  • Users: Create Directory (Container Inherit)

  • Users: Add File (Container Inherit, Inherit Only)

The Setup Security.inf template can be used to reapply default security settings. For more information about applying templates, see “Using Security Templates” later in this chapter.

Using CACLS

Although the Properties page is the basic user interface for viewing and modifying ACLs and ACEs, it is not usable for configuring security for all types of objects on a network or Windows XP Professional–based computer. In some cases, you can use the tool Cacls.exe to perform security configuration tasks.

Cacls.exe can be used to display or modify access control lists (ACLs) for one or more files at a time. It includes options that can be used to grant (/g), revoke (/r), replace (/p), or deny (/d) specific user access rights. For example, you can use the cacls command to grant an access right to a user. At the command line, type the cacls command using the following syntax:

cacls [filename]/g [username:right]

In this command, the user name of the user is followed by a colon and the specific user right that you want.

Managing User Rights by Using Security Groups

It is easier to manage groups than individual users. The rights granted to a user are based on the user’s security group memberships. For this reason, a significant portion of Windows XP Professional operating system security is defined by the default access permissions granted to the Administrators, Power Users, and Users groups. If you already have a managed user environment, or if you want to move to a managed user environment, consider the capabilities and restrictions that apply to each of these security groups. Also, determine which of your users require higher levels of permissions, and which users need fewer permissions.

Security Group Upgrade from Windows NT 4.0

In the case of an upgrade from Windows NT 4.0 to Windows XP Professional, existing Users automatically become members of the Power Users group. This is because the permissions that apply to Users in Windows XP Professional are more restrictive than the permissions that apply to Users in Windows NT 4.0. As a result, after upgrading to Windows XP Professional, certain applications might not run for users who are members of the Users group. Placing Windows NT 4.0 Users in the Power Users group enables them to continue to run noncertified applications.

From a security standpoint, deploying certified applications and placing users only in the Users group is preferred. The default access control settings for the Users group on NTFS systems prevents users (or malicious applications run by users) from compromising the operating system or other users’ data.

Note If you need to run uncertified applications but do not want to use the Power Users group, the Compatible security template (Compatws.inf) can be used to open up permissions for Users in a manner that is consistent with the access control requirements of most legacy applications. For more information about the Compatws.inf template, see “Security Templates” later in this chapter.

Security Group Creation in a Clean Installation

In a clean installation of Windows XP Professional, security group membership depends on how users are created:

  • If the user is a domain user logging on to the Windows XP Professional–based computer for the first time, the user becomes a member of the Users (Restricted) group on the local computer.

  • If the user is local and the account was created with the Local Users and Groups MMC snap-in, the user becomes a member of the Users (Restricted) group on the local computer.

  • If the user is local and the account was created with User Accounts in Control Panel, the user becomes a member of the Power Users (Standard) group on the local computer.

The Administrators, System, and Creator Owner groups are given Full Control on all file system and registry objects that exist at the beginning of GUI-mode setup.

Table 17-5 lists the default access permissions for Users in Windows XP Professional with Service Pack 2.

Table 17-5 Default Access Permissions for Users in Windows XP Professional

Object

Permission

Comment

HKEY_Current_User

Full Control

User’s portion of the registry.

%UserProfile%

Full Control

User’s Profile directory.

All Users\Shared Documents

Read & Execute

Shared Documents location.

All Users\Application Data

Read & Execute

Shared Application Data location.

%Windir%

Read & Execute

System files location.

%Windir%\Temp

Traverse Folder/Execute File, Create Folders/Append Data, Create Files/Write Data (subfolders only)

Per-computer temp directory. This is a concession made for service-based applications so that Profiles do not need to be loaded to get the per-User temp directory of an impersonated user.

Program Files

Read & Execute

Application files location.

\ (Root Directory)

Read & Execute, Create Folders/Append Data, and Create Files/Write Data (subfolders only)

Per share directory.

Table 17-6 lists the default user rights for clean-installed workstations with Windows XP Service Pack 2.

Table 17-6 User Rights for Clean-Installed Workstations

User Right

Default Workstation

Access this computer from the network

Administrators, Backup Ops, Power Users, Users, Everyone

Act as part of the operating system

Not assigned

Add workstations to the domain

Not assigned

Adjust memory quotas for a process

Administrators, Local Service, Network Service

Allow logon through Terminal Services

Administrators, Remote Desktop Users

Backup Files and Directories

Administrators, Backup Ops

Bypass Traverse Checking

Administrators, Backup Ops, Power Users, Users, Everyone

Change the system time

Administrators, Power Users

Create a Pagefile

Administrators

Create a Token Object

Not assigned

Create global objects

Administrators, Interactive, Service

Create Permanent Shared Objects

Not assigned

Debug Programs

Administrators

Deny access to this computer from the network

Support

Deny logon as a batch job

Not assigned

Deny logon as a service

Not assigned

Deny logon locally

Support, Guest

Deny logon through Terminal Services

Not assigned

Enable computer and user accounts to be trusted for delegation

Not assigned

Force shutdown from a remote system

Administrators

Generate Security Audits

Local Service, Network Service

Impersonate a client after authentication

Administrators, Service

Increase Scheduling Priority

Administrators

Load and Unload Device Drivers

Administrators

Lock Pages in Memory

Not assigned

Log On as a Batch Job

Support

Log On as a service

Network Service

Log On Locally

Administrators, Backup Ops, Power Users, Users, Guest

Manage auditing and security log

Administrators

Modify firmware environment variables

Administrators

Perform volume maintenance tasks

Administrators

Profile single process

Administrators, Power Users

Profile system performance

Administrators

Remove Computer from a Docking Station

Administrators, Power Users, Users

Replace a Process-Level Token

Local Service, Network Service

Restore files and directories

Administrators, Backup Ops

Shut down the system

Administrators, Backup Ops, Power Users, Users

Synchronize directory service data

Not assigned

Take ownership of files or other objects

Administrators

Managing Anonymous Logons

You should not grant access to Anonymous users unless you have specific reasons for doing so. To help you implement this restriction, when a Windows 2000–based system is upgraded to Windows XP Professional, resources with access control lists that grant access to the Everyone group (and not explicitly to the Anonymous Logon group) will no longer be available to Anonymous users.

In most cases, this is an appropriate restriction on Anonymous access. However, you might need to permit Anonymous access in order to support pre-existing applications that require it. In this case, you can explicitly add the Anonymous Logon security group to the access control lists for a specific resource and grant Anonymous users the right to access the computer over the network.

In some situations, however, it might be difficult or impossible to determine which resource on the computer running Windows XP Professional must grant Anonymous access, or to modify the permissions on all the necessary resources. If this is the case, you might need to force the computer running Windows XP Professional to include the Everyone group in the Anonymous Logon security token. You can do this through the Let Everyone permissions apply to anonymous users local security setting. The security setting can be set to either Enabled or Disabled. The default setting is Disabled.

To change whether Everyone permissions apply to anonymous users
  1. In Control Panel, click Performance and Maintenance, click Administrative Tools, and then double-click Local Security Policy.

  2. Under Security Settings, double-click Local Policies, and then click Security Options.

  3. Right-click Network Access: Let Everyone permissions apply to anonymous users, and then click Properties.

  4. To allow Anonymous users to be members of the Everyone security group, select Enabled. To revoke the Everyone security group security identifier in the Anonymous user’s access token (the Windows XP Professional default), select Disabled.

Managing Network Authentication

An increasing number of Windows XP Professional–based systems are connected directly to the Internet and participate in home or small business networks rather than in domains. To simplify the sharing and security model used in these nondomain environments, network logons performed against unjoined Windows XP Professional–based computers are automatically mapped to the Guest account by default. This simplifies the sharing of resources in home or small business networks by eliminating the need to synchronize user names and passwords across all computers in the network. Authenticating users logging on to the network as Guest can provide an additional measure of security for computers connected to the Internet by eliminating the ability to access the computer remotely by using administrative credentials.

Forcing network logons to authenticate as Guest does not affect the following:

  • Interactive logons.

    In addition to console logons, this also includes remote access sessions using Terminal Services or Telnet, which are essentially “remote” occurrences of interactive logon sessions.

  • Computers that are joined to a domain.

    This is not the default for Windows XP Professional–based computers that are joined to a domain because the domain provides single sign-on capabilities for all computers that are in the domain.

  • Outbound connections.

    The authentication and access control settings of the computer that you are attempting to access govern outbound connections.

While forcing network logons to authenticate as Guest can simplify the sharing of resources, it does not expose the detailed access control permissions that Windows XP Professional is capable of and that many advanced users might want. For example, requiring all users to authenticate as Guest means that all users must be granted the same level of permissions to the same resource. You cannot grant Alice Read-only access to one share while granting Bob Modify access to the same share, because both Alice and Bob authenticate as Guest user.

Note When Guest-only network logons are being used, Read-only and Modify are the only permissions that can be granted to shared files.

This also means that the actions performed remotely by Alice and Bob cannot be individually audited.

To ensure that remote administration of domain-based computers running Windows XP Professional is possible, you must include a domain-based account in the local administrators group.

You can use the Group Policy snap-in to select between the Classic and Guest-only security models that regulate the use of the Guest account and sharing behavior for Windows XP Professional in stand-alone and workgroup environments. The Classic model allows you to have explicit control over access to resources. Using the Classic model, you can grant different users different types of access to the same resource.

To select the Classic security model
  1. In Microsoft Management Console, open Group Policy and navigate to the Security Settings container.

    The file path is Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.

  2. Double-click Network access: Sharing and security model for local accounts, and then click Properties.

  3. Select Classic - local users authenticate as themselves, and then click OK.

The alternative policy setting, Guest only – local users authenticate as Guest, requires all users to be treated equally—that is, all users authenticate as Guest and thus receive the same level of access to a given resource. When the computer is not joined to a domain, this setting configures the file sharing and security tabs in Windows Explorer to correspond to the sharing and security model in use.

Caution When using the Guest-only model, any user who can access your computer over the network (including anonymous Internet users) will be able to access your shared resources. Therefore, it is important to have a firewall or similar device to protect your computer from unauthorized access. Similarly, when using the Classic model, it is important that local accounts be password protected; otherwise, those user accounts can be used by anyone to access shared system resources.

Sharing Files and Folders under the Guest-Only Option

The Guest-only security model is designed to simplify many details of security management for users, including the procedures used to share files and folders. This is apparent on the Sharing tab of a folder’s Properties page. When the Guest-only security model is used, the Sharing tab has only three options:

  • Share this folder on the network.

    Allows Everyone Read permissions on the folder and its contents.

  • Share name.

    The name of the share on the network.

  • Allow other users to change my files.

    Allows Everyone Full Control permissions on folders and Change permissions on files.

You can create a share at the root of the system drive; however, the default sharing model does not change the file permissions on shares created there. The Everyone group only has Read permissions on the root of the system drive, so sharing the root does not provide sufficient permissions for performing the majority of tasks associated with remote administration.

For more information about using the Network Setup Wizard to enable the Guest account for sharing files and folders, and ensuring that the personal firewall is properly configured, see Windows XP Professional Help and Support Center and Chapter 25, “Connecting Remote Offices” in this book. And for more information on simple file sharing and how to configure, use, or disable it, see the following articles in the Microsoft Knowledge Base at https://support.microsoft.com:

  • 304040, “How to configure file sharing in Windows XP”

  • 307874, “How to disable simplified sharing and set permissions on a shared folder in Windows XP”

Using Security Policy

By using Local Security Policy, you can modify numerous security-relevant settings, including file system ACLs, registry ACLs, service ACLs, and group membership. These settings can be used to manage a single computer or many computers at once. For computers that are not joined to an Active Directory domain, the Security Templates and Security Configuration and Analysis MMC snap-in components of Security Configuration Manager can be used to create security templates and apply them to individual computers.

Note Security settings that are defined via domain-based Group Policy always override security settings that are configured locally.

Windows XP Professional allows you to configure security settings in the following areas:

  • Account Policies.

    This includes password policies such as minimum password length and account lockout parameters.

  • Local Policies.

    This includes auditing policy, assignment of user rights and privileges, and various security options that can be configured locally on a particular Windows XP Professional–based computer.

  • Event Log Settings.

    This is used to configure auditing for security events such as successful and failed logon and logoff attempts.

  • Public Key Policies.

    These are used to configure encrypted data recovery agents, domain roots, and trusted certificate authorities.

  • Software Restriction Policies.

    This is a new Windows XP Professional policy-driven feature that allows you to prevent unwanted applications, such as viruses or other harmful software, from running.

  • IP Security Policies on Local Computer.

    This is used to configure network Internet Protocol (IP) security.

  • Restricted Groups.

    This is used to manage the members of built-in groups that have certain predefined capabilities. These groups include built-in groups such as Administrators, Power Users, Print Operators, Server Operators, and so on, as well as domain groups, such as domain Administrators. You can also add groups that you consider to be sensitive or privileged to the Restricted Groups list, along with their membership information. This allows you to track and manage these groups as part of system security configuration or policy.

  • System Services.

    This is used to configure and manage security settings for areas such as network services, file and print services, telephony and fax services, and Internet/intranet services. Security policy allows you to configure the service startup mode (automatic, manual, or disabled) as well as security on the service.

  • Registry.

    This is used to manage the security descriptors on registry subkeys and entries.

  • File System.

    This is used to configure and manage security settings on the local file system. The configuration file contains a list of fully qualified file or directory paths and security descriptors for each.

Administrators who have implemented an Active Directory domain structure can configure and apply additional security configuration options, such as Kerberos and Wireless Network (IEEE 802.11) policies, for their clients running Windows 2000 Professional and Windows XP Professional.

Note For information about the use and management of Group Policy in Active Directory environments, see “Group Policy” in the Distributed Systems Guide. For more information about individual policy settings, see the “Security Event Messages” document on the companion CD.

Software Restriction Policies

When users run applications, they do so in the security context defined by their rights and restrictions. For example, a user might have the right to view and edit documents by using Microsoft Word, but not have the right to install or modify the application itself. These rights and restrictions do not always prevent untrusted applications from taking advantage of the security contexts of trusted applications. The increasing number of “stealth” applications distributed through e-mail and the Internet create a need for a more precise level of administrative control over the relationship between applications and the user’s security context.

Software Restriction Policies are designed to assist you in regulating unknown or untrusted applications by allowing you to classify applications as trusted or untrusted. After trusted and untrusted applications have been identified, you can then apply a policy that regulates each application’s ability to execute. This policy can apply to an entire computer or to individual users.

How Software Restriction Policies Work

Software Restriction Policies includes two key items:

  • Security Levels, which define the default authorization level at which a user is allowed to run a piece of software

  • Additional Rules, which specify the maximum authorization level at which a piece of software is allowed to run on that computer

When a user attempts to run a software application, the computer uses the maximum values of these two components to determine the authorization level at which the application is allowed to run.

Security Levels

There are two default Security Levels, Unrestricted and Disallowed. You can use Unrestricted settings to define just the set of programs that are allowed to run. Disallowed can be used to specify only the programs that are forbidden to run.

Configuring applications as Disallowed is more secure than configuring applications as Unrestricted because it allows you to isolate specific unacceptable applications based on well-defined criteria. You can define default Security Level rules for each of the following criteria associated with an application:

  • Path.

    You can allow or disallow an application by creating a rule based on the application’s file path.

    When a path rule specifies a folder, it matches any program contained in that folder and any programs contained in subfolders. A path rule can use environmental variables, such as %WINDIR%. This makes the rule adaptable to a particular user’s environment. A path rule can also incorporate wildcards so that specifications such as *.VBS, for example, match all Visual Basic Script files.

  • Hash.

    You can allow or disallow an application based on the application’s hashed file contents.

    A hash is a fingerprint that uniquely identifies a file even if the file is moved or renamed. If software is renamed or moved, the hash rule will still apply because it is based on a cryptographic calculation derived from the contents of the file.

  • Certificate.

    You can allow or disallow an application based on the certificate associated with that application.

    A certificate rule can apply to a self-signed certificate, a certificate issued from a commercial certification authority, or a certificate issued from a Windows 2000 or Windows Server 2003 public key infrastructure. Because they use signed hashes contained in the file signature, certificate rules are applied to files regardless of file name or location.

  • Internet Zone.

    You can allow or disallow an application based on the Internet zone from which the application is downloaded.

    Applications can be downloaded from the following zones: Internet, Intranet, Restricted Sites, Trusted Sites, and My Computer. The Internet zone rules apply only to Windows Installer packages.

Additional Rules

The following Additional Rules allow you to further refine your Software Restriction Policies:

  • Enforcement Properties.

    Determines whether software library files are excluded from the software policy restrictions. Also, you can use this option to prevent software policy restrictions from applying to local administrators.

  • Designated File Types.

    Allows you to add or delete file types from the list of what is considered to be executable code.

  • Trusted Publishers.

    Allows you to define who (end users, local administrators, or enterprise administrators) can select trusted publishers. In addition, you can use this option to specify revocation-checking options.

Using Software Restriction Policies

How you use Software Restriction Policies depends in large part upon how well you know what software applications your users are running. If you know all the client software that will be allowed, you can use Software Restriction Policies to enforce the use of allowed software only. If you do not know all the applications that your users will run, you can still use Software Restriction Policies in a more limited way by disallowing applications that you are certain you do not want.

You can use Software Restriction Policies to protect users from viruses without preventing useful programs from running. For example, a number of recent worm viruses were authored using a language called Visual Basic Script (or VB Script). Many system administrators also use VB Script to perform system management tasks. An administrator might want to protect his or her computers from all VB Script–based viruses but still use VB Script for systems management and login scripts.

To do this, he or she can create a path rule such as *.VBS that disallows all VB Script files, and create a certificate rule identifying the certificate used by the IT department to sign administrative scripts. The IT department would sign all VB scripts using that trusted certificate. Any script not signed by that certificate would be prevented from running.

Security Templates

Windows XP Professional provides predefined security templates as a starting point for creating security policies that can be customized to meet different organizational requirements. You can customize the templates by using the Security Templates snap-in.

After the predefined security templates are customized, they can be used to configure an individual computer or thousands of computers. Individual computers can be configured by using the Security Configuration and Analysis snap-in or the Secedit.exe command-line tool, or by importing the template into Local Security Policy. You can configure multiple computers by importing a template into Group Policy.

You can also use a security template in conjunction with the Security Configuration and Analysis snap-in as a baseline for analyzing a system for potential security holes or policy violations. To examine the proposed changes, import the template into a database and then perform an analysis against that database. Performing an analysis does not change any system settings, but it will highlight the differences between the settings specified in the template and the settings as they currently exist on the system.

Note The predefined security templates should not be applied to production systems without comprehensive testing to ensure that they meet the security and functionality requirements for your specific organization.

By default, the predefined security templates are stored in the Systemroot\Security\
Templates folder. The predefined templates include:

  • Compatible (Compatws.inf)

  • Secure (Secure*.inf)

  • High Secure (Hisec*.inf)

  • Root Directory Permissions (Rootsec.inf)

  • Setup Security (Setup Security.inf)

Compatible (Compatws.inf)

Default permissions for workstations and servers are primarily granted to three local groups: Administrators, Power Users, and Users. Administrators have the most privileges, while Users have the least. Thus, you can significantly improve the security, reliability, and total cost of system ownership by doing the following:

  • Ensuring that end-users are members of the Users group

  • Deploying applications that run successfully under a User context

Applications that comply with the Designed for Windows XP logo program can run successfully under a User context. However, applications that are not certified are not likely to run under a User context. Thus, if noncertified applications must be supported, there are two primary options:

  • Allow users of such applications to be members of the Power Users group.

  • Relax the default permissions granted to the Users group.

Because Power Users have inherent capabilities such as creating users, groups, printers, and shares, some administrators would rather relax the default User permissions than allow users of noncertified applications to be members of the Power Users group. This is precisely what the Compatible template is for. It loosens the default file and registry permissions granted to the Users group in a manner that is consistent with the requirements of most noncertified applications. Also, because it is assumed that the administrator applying the Compatible template does not want users of noncertified applications to be Power Users, the Compatible template also removes all members of the Power Users group.

Because of the heightened security guidelines that must be applied to domain controllers, it is best if the Compatible template is not applied to domain controllers or imported into the default domain or default domain controller Group Policy objects.

Secure (Secure*.inf)

The Secure templates define enhanced security settings that are least likely to affect application compatibility. For example, the Secure templates define stronger password, lockout, and audit settings.

The Secure templates limit the use of the NTLM authentication protocol by configuring clients to send only NTLM version 2 responses and configuring servers to refuse LanManager responses.

To apply Securews.inf to a workstation or member server, all the domain controllers that contain the accounts of users that log on to the client must be running Windows NT 4.0 Service Pack 4 or higher. If a server is configured with Securews.inf, a client with a local account on that server will not be able to connect to it from a LanManager client using that local account. If a domain controller is configured with Securedc.inf, a user with an account in that domain will not be able to connect to any member server from a LanManager client by using his or her domain account.

Note You can use LanManager on clients running Microsoft Windows for Workgroups, as well as Microsoft Windows 95 and Microsoft Windows 98, without the DS Client Pack installed. If the DS Client Pack is installed on clients running Windows 95 and Windows 98, those clients can use NTLMv2. Windows Me supports NTLMv2.

The Secure templates also provide further restrictions by preventing anonymous users (for example, users from untrusted domains) from doing the following:

  • Enumerating account names and shares

  • Performing SID-to-name or name-to-SID translations

Finally, the Secure templates enable server-side Server Message Block (SMB) packet signing, which is disabled by default for workstations and servers. Because client-side SMB packet signing is enabled by default, SMB packet signing will always be negotiated when workstations and servers are operating at the secure level.

High Secure (Hisec*.inf)

The High Secure templates are supersets of the secure templates and impose further restrictions on the levels of encryption and signing required for authentication and for the data that flows over Secure Channels and between SMB clients and servers. For example, while the Secure templates cause servers to refuse LanManager responses, the High Secure templates cause servers to refuse both LanManager and NTLM responses. While the Secure templates enable server-side SMB packet signing, the High Secure templates require it. Also, the High Secure templates require strong (128-bit) encryption and signing for the Secure Channel data that constitute domain-to-member and domain-to-domain trust relationships. Therefore, to apply Hisecws.inf to a member computer:

  • All the domain controllers that contain the accounts of all users that will log on to the client must be running Windows NT 4.0 Service Pack 4 or higher.

  • All the domain controllers for the domain that the client is joined to must be running Windows 2000 or later.

The following rules also apply to the High Secure template:

  • To apply Hisecdc.inf to a domain controller, all the domain controllers in all trusted or trusting domains must be running Windows 2000 or later.

  • If a server is configured with Hisecws.inf, a client with a local account on that server will not be able to connect to it from a client that does not support NTLMv2.

  • If a server is configured with Hisecws.inf, all clients that want to use SMB to connect to that server must have client-side SMB packet signing enabled. Client-side SMB packet-signing is enabled by default for all Windows XP Professional–based computers.

  • If a domain controller is configured with Hisecdc.inf, a user with an account in that domain will not be able to connect to any member server from a client that does not support NTLMv2.

  • If a domain controller is configured with Hisecdc.inf, Lightweight Directory Access Protocol (LDAP) clients will not be able to bind with the Active Directory LDAP server unless data signing is negotiated. Thus, bind requests that use ldap_simple_bind or ldap_simple_bind_s are rejected. By default, all Microsoft LDAP clients that ship with Windows XP Professional request data signing if Transport Layer Security\Secure Sockets Layer (TLS\SSL) is not already in use. If TLS\SSL is in use, data signing is considered to be negotiated.

In addition to further restrictions on the use of downlevel LanManager protocols and the requirements for encryption and signing of secure channel and SMB traffic, the High Secure templates also limit the use of cached logon data such as data stored by Winlogon and Stored User Names and Passwords.

Finally, the template Hisecws.inf removes all members of the Power Users group based on the assumption that only applications that are certified under the Designed for Windows XP logo program have been deployed. The template also uses Restricted Groups to ensure that the only members of the local Administrators group are the local Administrator account and Domain Admins. With certified applications in place, neither the insecure Compatible template nor the insecure Power Users group is needed. Instead, users can successfully run certified applications under the secure context of a normal User.

Root Directory Permissions (Rootsec.inf)

By default, the Rootsec.inf template specifies the new permissions, introduced in Windows XP Professional, for the root of the system drive. This template can be used to reapply the default root directory permissions if they are inadvertently changed. In addition, the template can be used to apply the same root permissions to other volumes.

Note This template does not overwrite explicit ACEs defined on child objects. It propagates only the permissions that are inherited by child objects.

Setup Security (Setup security.inf)

Setup security is a computer-specific template that represents the default security settings applied during installation of the operating system, including the file permissions for the root of the system drive. This template, or portions thereof, can be used for disaster recovery purposes. Setup security.inf replaces the combination of Basic.inf and Ocfiles.inf that existed in versions of Windows earlier than Windows XP Professional. Setup security.inf should not be applied by using Group Policy.

No Terminal Server SID (Notssid.inf)

The default file system and registry ACLs on servers grant permissions to a Terminal Server SID. The Terminal Server SID is used only when Terminal Server is running in application compatibility mode. If Terminal Server is not in use, this template can be applied to remove the unnecessary Terminal Server SID from these file system and registry locations. Removing the ACE for the Terminal Server SID does not, however, increase the security of the system. Therefore, instead of removing the Terminal Server SID, it is recommended that you run Terminal Server in full security mode rather than application compatibility mode. When Terminal Server is running in full security mode, the Terminal Server SID is not used.

Working with Local Security Policy

To view and implement security policy on a local computer, you must have Administrator rights to the computer. Administrators can use the following Windows XP Professional tools to view and configure security policy settings:

  • Local Security Policy.

    This Group Policy snap-in can be used to configure security settings on individual computers. The Local Security Policy snap-in can be used to configure Account Policies, Audit Policies, User Rights, and numerous other security options.

  • Security Settings extension to Group Policy.

    This Group Policy snap-in can be used to establish security policies for domains or organizational units (OUs). The Group Policy snap-in can be used to configure the same settings that Local Security Policy configures, as well as Event Log settings, Restricted Groups, System Services, file ACLs, and registry ACLs.

  • Security Templates snap-in.

    This is a stand-alone Microsoft Management Console snap-in that can be used to create a text-based template file that contains security settings for all security areas. The security templates snap-in can be used to configure Account Policies, Local Policies, Event Log settings, Restricted Groups, System Services, registry settings, and File System settings.

  • Security Configuration and Analysis snap-in.

    This is a stand-alone MMC snap-in that can configure or analyze Windows XP Professional operating system security. Its operation is based on the contents of a security template that was created by using the Security Templates snap-in.

  • Secedit.exe.

    This is a command-line version of the Security Configuration and Analysis snap-in. It allows security configuration and analysis to be performed without a graphical user interface (GUI).

Viewing Local Security Policy Settings

You can use the following procedure to view the security policy settings on a computer running Windows XP Professional.

To view Local Security Policy settings
  • In Control Panel, click Performance and Maintenance, click Administrative Tools, and then double-click Local Security Policy.

The Local Security Settings snap-in is illustrated in Figure 17-7. You can also view the Local Security Settings container from the command line.

Figure 17-7 Local Security Settings snap-in

Figure 17-7 Local Security Settings snap-in

To open Local Security Settings from the command line
  • In the Run dialog box, type:

    secpol.msc

Modifying Local Security Policy Settings

To modify a local security policy setting, double-click the security item and revise the policy as needed. For example, you can use the following procedure to set the local policy Prevent users from installing printer drivers.

To set the Prevent users from installing printer drivers local policy
  1. In the Local Security Settings snap-in, in the left pane under Security Settings, click the PLUS SIGN (+) to expand Local Policies.

  2. Click Security Options.

  3. In the right pane, double-click Devices: Prevent users from installing printer drivers.

  4. Click Enabled, and then click OK.

  5. In the left pane, right-click Security Settings, and then click Reload.

Permissions on Group Policy objects

To edit a Group Policy object, the user must have both Read and Write access to the Group Policy object, and must be one of the following:

  • A member of the Administrators group for the local computer, domain, or enterprise.

  • A member of the Group Policy Creator Owners group who has previously created the Group Policy object.

  • A user with delegated access to the Group Policy object. That is, an administrator or a user who has had access delegated to him or her by someone with the appropriate rights using the Security tab on the Group Policy Object Properties page.

By default, Group Policy objects allow members of the Domain Administrators, Enterprise Administrators, and Group Policy Creator Owners groups Full Control without the Apply Group Policy attribute set. This means that they can edit the Group Policy object, but the policies contained in that Group Policy object do not apply to them.

By default, Authenticated Users have Read access to the Group Policy object with the Apply Group Policy attribute set. This means that Group Policy affects them.

Domain Administrators and Enterprise Administrators are also members of Authenticated Users; therefore, members of those groups are, by default, affected by Group Policy objects unless you explicitly exclude them.

When a nonadministrator creates a Group Policy object, this person becomes the Creator Owner of the Group Policy object (GPO) and can edit the GPO. When an administrator creates a Group Policy object, the Domain Administrators group becomes the Creator Owner of the GPO; therefore any member of the Domain Administrators group can edit the GPO.

Creating Group Policy MMC consoles to delegate Group Policy

You can delegate Group Policy by creating and saving the Group Policy snap-in consoles (.msc files), and then specifying which users and groups have access permissions to the Group Policy object or to an Active Directory container. You can define permissions for a Group Policy object by using the Security tab on the Properties page of the Group Policy object; these permissions grant or deny access by specified groups to a Group Policy object.

This type of delegation is also enhanced by the policy settings available for MMC. Several policies are available in the Administrative Templates node, which is located under Windows Components in the Microsoft Management Console. These policies enable the administrator to define which MMC snap-ins the affected user can or cannot run. The policy definitions can be inclusive, which allows only a specified set of snap-ins to run, or they can be exclusive, which does not allow a specified set of snap-ins to run.

Using Security Templates

The Security Templates snap-in allows you to create a text-based template file that can contain security settings for all the security areas supported by local security policy. You can then use these template files to configure or analyze system security in the following ways:

  • You can import a template file into the Security Settings extension to configure local, domain, or organizational unit (OU) security policy.

  • You can use the Security Configuration and Analysis snap-in to configure or analyze system security based on a text-based security template.

  • You can use the Secedit.exe command-line tool directly or in conjunction with other management tools such as Microsoft Systems Management Server or Task Scheduler to deploy a security template or trigger a security analysis.

To load the Security Templates snap-in and view security policy settings
  1. In the Run dialog box, type mmc /s.

  2. Click OK.

  3. On the File menu, click Add\Remove Snap-in, and then click Add.

  4. In Available Standalone Snap-ins, select Security Templates.

  5. Click Add, and then click Close.

  6. Click OK.

  7. In the left pane, click the PLUS SIGN (+) to expand Security Templates.

  8. Expand C:\Windows\security\templates.

    The Security Templates snap-in is illustrated in Figure 17-8.

    Note If you installed Windows XP Professional in a different drive or directory, that path will display instead of C:\Windows.

    Figure 17-8 Security Templates snap-in with the default templates

    Figure 17-8 Security Templates snap-in with the default templates

Creating and applying security templates

You can create your own security template, or you can select the existing template that most closely meets your needs and make any additions or changes that you want to that template.

To create a new security template

  • Double-click Security Templates, right-click the default templates folder, and then click New Template.

This creates a blank template file without any security settings. You can now completely customize the template to meet the needs of your organization.

Once you create your template or make all the desired changes to an existing template, it is automatically saved to the templates directory. By using Save As, you can overwrite the existing template of that name or save the template under a new name.

Tip Do not overwrite the default templates in case you later realize that the template you created does not work as desired.

To save a new or modified security template

  • Right-click the template name, select Save As from the shortcut menu, fill in a new name, and then click OK.

After you create a security template for your environment, you need to apply it to your computer. When you apply a template to existing security settings, the settings in the template are merged into the computer’s security settings.

To apply a security template to a computer

  1. In the Group Policy snap-in, double-click Computer Configuration\Windows Settings.

  2. Right-click Security Settings, and then click Import Policy.

  3. Select the template file that you want to import into your environment.

  4. Click OK.

You can also export the security template for your system from the Group Policy snap-in by navigating to the \%systemroot%\Security\Templates folder and copying the appropriate template file to another network location or to a floppy disk.

Performing security configuration tasks using security templates

You can perform the following key security-related tasks by using Windows XP Professional security templates:

  • Configure permissions for a file system directory.

  • Create a restricted Group Policy.

  • Inherit, overwrite, and ignore policy changes.

Configuring permissions for file system directories

You can use the following procedure to configure permissions for file system directories.

To configure permissions for file system directories

  1. Open the Security Templates snap-in, and expand Securews.inf.

  2. Right-click File System in the left pane, and then click Add File.

  3. Click the %systemroot%\repair folder, and then click OK.

  4. This brings up the Security Properties dialog box, which allows you to specify permissions for the %systemroot%\repair directory in the Securews.inf template.

  5. Click the Add button, and in the drop-down box select Administrators group.

  6. Click Add, and then click OK.

  7. Select the Full Control check box.

  8. Click the Advanced button. Clear the Inherit from parent the permission entries that apply to child objects check box.

  9. Click OK.

  10. Select the Replace existing permission on all subfolders and files with inheritable permissions button, and then click OK.

Creating a restricted Group Policy

A restricted Group Policy allows you to define who can and cannot belong to a specific group. When a template (or policy) that defines a restricted group is applied to a system, the Security Configuration Tool Set adds members to the group and removes members from the group to ensure that the actual group membership coincides with the settings defined in the template (or policy). The following procedure describes how to create a restricted Group Policy.

To create a restricted Group Policy

  1. In the left pane, in Security Templates, double-click a security template.

  2. Right-click Restricted Groups, and then select Add Group.

  3. In the Group dialog box, type the group name, and then click OK.

  4. Double-click the Restricted Groups folder.

    Tip To assist in troubleshooting, use a name that indicates that the group is affected by a restricted Group Policy.

  5. In the right pane, double-click the new group name. You can now define who can be a member of the restricted group and specify other groups of which that group can be a member.

  6. Click Add in the Members of this group section and then click Browse.

  7. In the Select Users dialog box, locate and select user names.

  8. Click Add, and then click OK.

The restricted Group Policy defines which users can be members of the specified local group when the specified template is used to configure a Windows XP Professional–based system. During configuration, the Security Configuration Tool Set removes all other users that belong to the group at the time of configuration. Similarly, if at the time of configuration the specified user does not belong to the specified group, the Security Configuration Tool Set adds the user to the group.

If no users are specified as members of a defined restricted group, the Security Configuration Tool Set removes all current members of that group when the template is used to configure a system.

If no groups are specified for a restricted group to belong to, no action is taken to adjust membership in other groups.

Inheriting, overwriting, and ignoring policy changes

After you define permissions for a file system or registry object, you can use the Security Configuration Tool Set to configure the object’s children.

If you select Propagate inheritable permissions to all subfolders and files, normal Windows XP Professional ACL inheritance procedures are put into effect—that is, any inherited permissions on child objects are adjusted according to the new permissions defined for this parent. Any explicit access control entry (ACE) defined for a child object remains unchanged.

If you select Replace existing permissions on all subfolders and files with inheritable permissions, all explicit ACEs for all child objects (which are not otherwise listed in the template) are removed, and all child objects are set to inherit the inheritable permissions defined for this parent.

To prevent a child object from being overwritten by a parent, the child object can be added to the template and ignored. If a child object is added to the template and ignored, that child’s inheritance mode and explicit ACEs remain untouched.

Choosing the option Do not allow permissions on this file or folder to be replaced makes sense only if an ancestor of that object is configured to overwrite children. If no ancestor exists in the template, ignoring an object has no impact. If an ancestor exists but is configured so that children inherit, ignoring a child has no impact.

By saving a security template file, you can copy the file containing your desired configuration settings to multiple computers running Windows XP Professional.

You can analyze, summarize, and evaluate your security policy configuration by using Security Configuration and Analysis tools. For more information about using the Security Configuration and Analysis tools, see “Auditing and Analyzing Access Control” next in this chapter.

Auditing and Analyzing Access Control

On many computers, the state of the operating system changes frequently. If you, other administrators, or users periodically make changes to computer configurations, auditing and regular analysis will enable you to validate the security configuration on each computer and to verify that security has not been breached. For example, you might want to track who or what is attempting to perform certain tasks, or you might want to obtain information about why certain events are taking place or not taking place.

Windows XP Professional provides a number of auditing and analysis features—including audit policies, Event Viewer, and the Security Configuration and Analysis snap-in—that can aid you in effectively validating the security configurations on the computers in your organization.

Enabling Auditing Policies

You can monitor many types of events on a Windows XP Professional–based system, including user actions such as logging on and logging off, and the success and failure of key application events. Administrators need to monitor these events to track security, system performance, and application errors.

You can set up audit policies to track authorized and unauthorized access to resources. By default, auditing is not enabled. Before you enable auditing, it will be important for you to define exactly what needs to be audited and why you want it to be audited. Auditing can slow down system performance, and it will also require effort on your part to evaluate audit logs; therefore, advanced planning is recommended to ensure that you track appropriate system events without creating excess administrative overhead.

For example, if you decide to audit account logon sessions, you need to consider what the information will be used for. Your security administrators group might be interested in logging failed logon events because this can indicate that someone is trying to log on with an account for which he or she does not have the correct password. Alternatively, you might want to log successful logon attempts to determine whether users are accessing workstations in areas of the network that they are not permitted to use.

To enable auditing, use the Microsoft Management Console with the Group Policy snap-in focused on the local computer. To see the different types of objects for which auditing can be configured, navigate to the following folder: Computer Configuration\Windows Settings\
Security Settings\Local Policies\Audit Policy.

There you will find a number of configuration audit policies, which can be used to audit events that fall into the following categories:

  • Account logon events.

    Logs an event each time a user attempts to log on. For example, specific events logged include: logon failures for unknown user accounts; time restriction violations; user account has expired; user does not have the right to log on locally; account password has expired; account is locked out. Successful logons also can be tracked through events.

  • Account management.

    Logs an event each time an account is managed. This is a useful function if you are concerned about changes being made to user accounts in your environment.

  • Directory service access.

    Logs an event each time a user accesses an Active Directory object that has its own system access control list (SACL) specified.

  • Logon events.

    Logs an event for logon events that are occurring over the network or generated by service startup (such as interactive logon events or service starting events).

  • Object access.

    Logs an event each time a user attempts to access a resource such as a printer or shared folder.

  • Policy changes.

    Logs an event each time a policy is successfully or unsuccessfully changed in your environment.

  • Privilege use.

    Logs an event each time a user attempts, successfully or unsuccessfully, to use special privileges, such as changing system time.

  • Process tracking.

    Logs an event for each program or process that a user launches while accessing a system. Administrators can use this information to track the details of a user’s activities while he or she is accessing a system.

  • System events.

    Logs designated system events, such as when a user restarts or shuts down a computer.

For each of these categories, determine whether you want to log Success, Failure, or both Success and Failure for the events they represent. Then configure the object that you want to monitor so that the policy and the object are linked.

For example, to audit file and folder access, first mark the activities (Success, Failure, or both) that you want to track under Object Access. Then, for each of the files and folders that you want audited, configure the SACLs that enable auditing.

To enable auditing of file or folder access
  1. Right-click the file or folder, and then click Properties.

  2. On the Security tab, click the Advanced button.

  3. On the Advanced Security Settings for Shared Documents page, click the Auditing tab.

    The Auditing tab is shown in Figure 17-9.

    Figure 17-9 Auditing tab

    Figure 17-9 Auditing tab

  4. Click the Add button, and then select the users or groups whose activity you want to monitor.

  5. For each entry, determine whether you want to track successes or failures or both.

  6. Determine whether auditing must be configured on this object only or on other child objects. For example, if the object is a folder and you want to audit activity on files and subfolders, select Apply these auditing entries to objects and/or containers within this container only.

  7. Configure settings for the Users, Computers, and Groups whose activities you want to track, and complete the process by clicking OK.

  8. In the Group Policy snap-in, navigate to:

    Local Computer Policy\Computer Configuration\Windows Settings \Security
    Settings\Local Policies\Audit Policy

  9. Double-click Audit object access.

  10. Select the appropriate check boxes for logging Success, Failure, or both.

  11. Click OK.

The list of configurable entries is almost identical to the list of Access Control Entries for files and folders. For more information about ACEs for files and folders, see “Access Control Entries” earlier in this chapter.

Auditing the Use of Privileges

Windows XP Professional provides the option to audit the use of privileges. Although this setting can be either enabled or disabled, it cannot be applied selectively to individual rights.

Warning Auditing the use of user privileges generates a very large number of audits, and in most cases the value of the information this provides does not outweigh the associated management costs. Therefore, do not audit the use of user privileges unless it is strictly necessary for your environment. If you must audit the use of user privileges, it might be worthwhile to obtain or write an event-analysis tool that can gather information about only the user rights that are of interest to you.

Enabling the Use of Privileges category in the system’s Audit policy does not enable the audit of all user rights. The following user rights are never audited:

  • Bypass Traverse Checking (SeChangeNotifyPrivilege)

  • Generate Security Audits (SeAuditPrivilege)

  • Create A Token Object (SeCreateTokenPrivilege)

  • Debug Programs (SeDebugPrivilege)

  • Replace A Process Level Token (SeAssignPrimaryTokenPrivilege)

The following user rights are audited only if a specific registry entry is present:

  • Backup Files and Directories (SeBackupPrivilege)

  • Restore Files and Directories (SeRestorePrivilege)

You can enable auditing of these privileges by using the security policy user interface in Windows XP Professional.

Auditing Account Management

Account Management audit policy is very detailed in Windows XP Professional. Enabling auditing for this event category allows you to record the success or failure of the domain and local events that are listed with their event numbers in the “Security Event Messages” document on the companion CD.

Using the Event Viewer

The Event Viewer is an MMC snap-in that enables you to view three different logs that are stored by Windows XP Professional:

  • System log.

    The System log contains events logged by the Windows XP Professional system components, such as drivers or other system components that failed to load during startup. Windows XP Professional predetermines the event types logged by the system components.

  • Application log.

    The Application log contains events logged by applications or programs. For example, a database program might record a file error in the application log. The program developer decides which events to record. Many Windows XP Professional services (such as DHCP, DNS, and File Replication Services) use the application log.

  • Security log.

    The Security log, if configured to do so, records security events, such as valid and invalid logon attempts. Events that are related to resource use—such as creating, opening, or deleting files—can also be logged. An administrator can specify the events that are recorded in the security log policy.

When you select the log type in the left pane of the Event Viewer, the corresponding log data displays in the right pane.

The data in the right pane can be filtered and resorted. In addition, you can select which columns of data to display by selecting Choose Columns from the View menu.

The Event Viewer tracks five types of events:

  • Error.

    A significant problem, such as loss of data or loss of functionality.

  • Warning.

    An event that is not necessarily significant but might indicate a possible future problem.

  • Information.

    An event that describes the successful operation of an application, driver, or service.

  • Success Audit.

    An audited security event in which a user’s attempt to access a resource succeeds.

  • Failed Audit.

    An audited security event in which a user’s attempt to access a resource fails.

In addition, the Event Viewer records the following:

  • The date of the event.

  • The time at which the event occurred.

  • The source (such as a service or process) that reported the event to the Event Viewer.

  • The category of the event. In many cases, the category relates to the subsystem that reported the event.

  • The user account associated with the event.

  • The computer on which the event occurred.

  • The Event ID, which is a numeric code that can be used to obtain additional information regarding the event being logged.

  • A description of the event.

Using the Security Configuration and Analysis Snap-In

You can use the Security Configuration and Analysis snap-in at any time to analyze current system settings against a baseline template. Performing this analysis allows you to do the following:

  • Identify security holes that might exist in the current configuration.

  • Identify the changes that a potential security policy will transmit to a system before actually deploying the security policy.

  • Identify deviations from a policy that is currently imposed on a system.

For example, if you have created a custom security template, the Security Configuration and Analysis tools will allow you to compare your system’s current settings against the settings that are defined by the security template that you created. If the custom security template defines a more secure configuration than the current settings provide, the analysis will identify the security holes that exist in the current system configuration, as well as the changes that will take place if the custom template is used to configure the system.

To load the Security Configuration and Analysis MMC snap-in
  1. In the Run dialog box**,** type:

    mmc /s

  2. On the File menu, click Add\Remove Snap-in, and then click Add.

  3. In Available Standalone Snap-ins, select Security Configuration and Analysis.

  4. Click Add, click Close, and then click OK.

Creating and Analyzing a Security Configuration Database

All configurations and analyses are database driven. The security configuration and analysis database, which is also referred to as the local computer policy database, is a computer-specific data store that is generated when one or more configurations are imported to a particular computer. A security configuration and analysis database is the starting point for all configurations and analyses done on a system.

An initial database is created during a clean installation of Windows XP Professional. Initially, it contains the default security configurations that are provided with the system. You can export and save this database to a security configuration file immediately after the installation for use in the event that you want to restore the initial security configuration at some point.

This database defines the security policy that is in force for that system. The system runs with the configuration defined in security policy. However, security policy might not define the entire configuration. For example, security might not be defined for every file or folder path. This means that security configuration attributes that are not enforced by policy can take any value for file and folder security—either a default value or a value defined by another mechanism. Attributes that are not enforced by policy might also be configured manually using personal databases. However, any custom configurations that conflict with the policy are overridden by the definitions in the policy. Personal database configurations are useful in areas such as the registry and the file system, where multiple users on the system can secure their own registry portions and home directory subtrees.

You can use the Security Configuration and Analysis snap-in to compare the current system configuration against the stored configuration in the database. Performing this analysis provides you with information about where a particular system deviates from the stored configuration. This information is useful for troubleshooting problems, tuning the security policy, and, most importantly, detecting any security flaws that might open up in the system over time.

The database is initially created from the computer-independent configuration file described previously. New configurations can be added to the database incrementally without overwriting the entire configuration.

To generate a security configuration database
  1. In the left pane, right-click Security Configuration and Analysis.

  2. Click Open Database. (See Figure 17-10.)

    Figure 17-10 Opening a Security Configuration and Analysis database

    Figure 17-10 Opening a Security Configuration and Analysis database

  3. In the Name dialog box, type a name for your new database.

  4. Click Open.

  5. Select an existing security template to import into the database.

  6. Click Open.

    The name of the database appears in the result pane. Several more options are available when you right-click Security Configuration and Analysis.

To analyze the security configuration database
  1. Right-click Security Configuration and Analysis, and then click Analyze Computer Now.

  2. In the Error log file path dialog box, specify a log file for the analysis results, such as the following:

    %windir%\security\logs\Mysecurews.log

  3. Click Open, and then click OK. A progress indicator displays as the analysis proceeds. (See Figure 17-11.)

    Figure 17-11 Progress dialog box for Security Configuration and Analysis

    Figure 17-11 Progress dialog box for Security Configuration and Analysis

Reviewing the results of a database analysis

After a database analysis is complete, you can view the security information under the Security Configuration and Analysis node.

To view the results of a database analysis

  1. In Security Configuration and Analysis, click View, and then click Customize.

  2. Select the Description Bar to expose the database you are currently working with.

  3. In the left pane, click Security Configuration and Analysis.

You can double-click any setting in the result pane to investigate discrepancies and modify database settings if desired.

Configuration results are displayed for the following areas:

  • Account policies.

    This includes password, account lockout, and Kerberos authentication policies. Kerberos authentication policies are relevant only on Windows 2000 domain controllers.

  • Local policies.

    This includes audit policy, user rights assignment, and computer security options.

  • Event log.

    This includes audit policies such as object access, password changes, and logon and logoff activities.

  • Restricted groups.

    This includes group memberships for selected groups that you consider to be sensitive.

  • Object trees.

    This includes system services settings, registry subkeys and entries, and the local file system.

    Note For each object tree, defined configuration files allow you to configure (and analyze) settings for security descriptors, including object ownership, the access control list (ACL), and auditing information.

In the right pane, both database and actual system settings are displayed for each object. Discrepancies are highlighted with a red flag. Consistencies are highlighted with a green check mark. If neither a flag nor a check mark appears, the security setting is not specified in the database (that is, the security setting was not configured in the template that was imported).

Modifying baseline analysis settings

After you review the results of the analysis, you might change your mind about the relevance of the security specification that was originally defined for an object. If so, you can update the baseline database used to perform the analysis.

If you consider an object to be relevant to security, select the Define this policy in the database check box when viewing the detailed analysis results. If this box is clear, the object is removed from the configuration and receives its inheritance from its parent object.

If you want to base future configurations or analyses on a different security specification, you can click the Edit Security Settings control to modify the security definition currently stored in the database.

Configuring and Analyzing Operations by Using Secedit.exe

The configuration and analysis operations available from the Security Configuration and Analysis snap-in can also be performed by using the Secedit.exe command-line tool. Using the command-line tool allows you to perform security configuration and analysis in conjunction with using other administrative tools, such as Microsoft Systems Management Server or the Task Scheduler built into Windows XP Professional. Secedit.exe also provides some capabilities that are not available in the graphical user interface, such as performing a batch analysis.

The Secedit.exe command-line tool allows the following high-level operations:

  • Analyze.

    Also available from the Security Configuration and Analysis snap-in.

  • Configure.

    Also available from the Security Configuration and Analysis snap-in.

  • Export.

    Also available after opening a database from the shortcut menu of the Security Configuration and Analysis snap-in. This dumps database configuration information into a template (.inf) file.

  • Validate.

    This verifies the syntax of a template created by using the Security Templates snap-in.

    Note For information about command-line syntax for Secedit.exe, see “Security Configuration Manager tools” in Windows XP Professional Help and Support Center.

All Secedit.exe configurations and analyses are database driven. Therefore, Secedit.exe supports switches for specifying a database (/db) as well as a configuration file (/cfg) to be imported into the database before performing the configuration.

By default, the configuration file is appended to the database. To overwrite existing configuration information in the database, use the /overwrite switch. As with the Security Configuration and Analysis snap-in, you can specify a log file (/log).

Note While the Security Configuration and Analysis snap-in always configures all security areas, Secedit.exe allows you to specify areas (/areas) to be configured. Security areas not specified with the /areas switch are ignored even if the database contains security settings for those areas.

Additional Resources

These resources contain additional information and tools related to this chapter.

  • The Microsoft Windows Security Resource Kit, for implementing security for Windows-based client computers and servers

  • Chapter 16, “Understanding Logon and Authentication,” for more information about the authentication process and how security contexts are created

  • “Access Control” in the Distributed Systems Guide, for more information about authorization in Active Directory environments

  • “Security Event Messages” on the companion CD

  • Appendix B, “User Rights”

  • “Set up your user account to use a .NET Passport” in Windows XP Professional Help and Support Center

  • “Fast User Switching” in Windows XP Professional Help and Support Center

  • “Local users and Groups overview” in Windows XP Professional Help and Support Center

  • “Permissions and user rights” in Windows XP Professional Help and Support Center

  • “Security Templates overview” in Windows XP Professional Help and Support Center

  • “Remote Desktop overview” in Windows XP Professional Help and Support Center