Revision 1.1

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Archived content - No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Microsoft® Windows NT®
Version 4.0
Microsoft Corporation

Information in this document is subject to change without notice. Companies, names, and data used in examples herein are fictitious unless otherwise noted. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation.

Microsoft Corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property rights except as expressly provided in any written license agreement from Microsoft Corporation.

© 1985-1998 Microsoft Corporation. All rights reserved.

Microsoft, Windows, and MS-DOS are registered trademarks and Windows NT is a trademark of Microsoft Corporation in the United States of America and other countries.

Adaptec is a trademark of Adaptec, Inc.

AppleTalk is a trademark of Apple Computers, Inc.

Compaq, Qvision, and SmartStart are registered trademarks and ProLiant is a trademark of Compaq Computer Corporation.

Alpha, AXP, DEC, and Digital are trademarks of Digital Equipment Corporation.

Hewlett-Packard, HP, and LaserJet are registered trademarks of Hewlett-Packard Company.

Intel and Pentium are registered trademarks and i386 is a trademark of Intel Corporation.

NT is a trademark of Northern Telecom.

OS/2 is a registered trademark of International Business Machines Corporation.

SCSI is a registered trademark of Security Control Systems, Inc.

UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd.

On This Page

Welcome
Chapter 1 - Security Policy Overview
Chapter 2 - Levels of Security
Chapter 3 - C2 Level Security
Chapter 4 - Microsoft Report on C2 Evaluation of Networked Windows NT
Appendix A - Software Security Rating Systems
Appendix B - Discretionary Access Control Lists (DACLs)

Welcome

Welcome to the Microsoft® Windows NT® Administrator's and User's Security Guide. This book is designed to help you use Microsoft® Windows NT® Server or Microsoft® Windows NT® Workstation to set up a computer system that is eligible for C2-level security certification.

This book has the following chapters:

Chapter 1, "Security Policy Overview," discusses security issues that every Windows NT administrator should be aware of. It focuses on the special considerations for high security installations.

Chapter 2, "Levels of Security," describes the different requirements for minimal, standard, and high level security.

Chapter 3, "C2 Level Security," describes the general requirements for C2 compliance, the evaluation process, and the evaluation history of Windows NT.

Chapter 4, "Microsoft Report on C2 Evaluation of Networked Windows NT," gives the specifications of the networked configuration of Windows NT 4.0 that was submitted for evaluation at the C2 level. A checklist is provided for duplicating this configuration.

Appendix A, "Software Security Rating Systems," describes the various rating systems in use worldwide, including the new Common Criteria designed to be a universal standard.

Appendix B, "Discretionary Access Control Lists (DACLs)" describes the discretionary access control mechanism used by Windows NT.

To administer a computer or network running Windows NT, you should be familiar with the product documentation for the operating system or systems. In most cases, you will also want to use information in the Microsoft resource kit for the product. This book assumes that you have the product documentation for Microsoft® Windows NT® Server version 4.0 or Microsoft® Windows NT® Workstation version 4.0, and the Microsoft® Windows NT® Resource Kit, Version 4.0.

Chapter 1 - Security Policy Overview

Computer security refers to the protection of all components—hardware, software, and stored data—of a computer or a group of computers from damage, theft, or unauthorized use. A computer security plan that is well thought out, implemented, and monitored makes authorized computer use easy and unauthorized use or accidental damage increasingly difficult.

This chapter is written primarily for Microsoft® Windows NT® system administrators. However, there are some issues that end users need to be aware of as well.

Some Definitions

C2 security is the highest government rating for business computing products; it requires the system to have discretionary resource protection and auditing capability.

Discretionary access control list (DACL) is the part of an object's security descriptor that provides for discretionary resource protection by allowing or denying permissions to specific users and groups.

An administrator is a person who sets up and manages domain controllers or local computers. By default, administrators are in the Administrators or Domain Admins account group.

A user is an end user, one who has no administrative rights or responsibilities on a computer. By default, users are in the Users account group.

A trusted user is a user who is allowed to run administrative utilities, replace files, install service packs, create printers, and install device drives.

Windows NT Security Model

In a multitasking operating system such as Windows NT, applications share a variety of system resources, including the computer's memory, I/O devices, files, and system processors. Windows NT includes a set of security components that ensure that applications cannot access these resources without authorization. Together, these components—the Security Reference Monitor, the Logon Process, the Security Account Manager (SAM), and the Local Security Authority—form the Windows NT security model.

The security model provides for discretionary access control so that the owner of a resource can specify which users or groups can access resources and what types of access they're allowed (such as read, write, and delete).

Tasks can access each others' resources, such as memory, only through specific sharing mechanisms. This feature helps enforce object hiding.

Windows NT also provides for auditing so that administrators can keep an audit trail of which users perform what actions.

By providing these features, the Windows NT security model prevents applications from gaining unauthorized access to the resources of other applications or the operating system either intentionally or unintentionally.

Components

The Security Reference Monitor enforces the access validation and audit generation policy defined by the Local Security Authority. It provides services to both of the system's operating modes—kernel mode and user mode—for validating access to objects, checking user privileges, and generating audit messages. The Security Reference Monitor runs in kernel mode, which protects it from interference by a rogue or failing application.

The Security Account Manager (SAM) maintains the user accounts database. This database contains information for all user and group accounts. SAM provides user validation services, which are used by the Local Security Authority. SAM is also known as the Directory database.

The Local Security Authority ensures that the user has permission to access the system. This component is the center of the Windows NT security subsystem. It generates access tokens, manages the local security policy, and provides interactive user authentication services. The Local Security Authority also controls audit policy and logs the audit messages generated by the Security Reference Monitor.

The Logon Process accepts logon requests from users. These include the initial interactive logon, which displays the initial logon dialog box to the user, and remote logon processes, which allow access by remote users to a Windows NT server process.

These last three components run in user mode, which makes them accessible to applications. However, because they are separate processes (subsystems), their memory is protected from other subsystems and applications.

The Windows NT Kernel and Executive are based on an object-oriented model that allows for a consistent and uniform view of security, right down to the fundamental entities that make up the base operating system. This means that Windows NT uses the same routines for access validation and audit checks for all protected objects. That is, whether someone is trying to access a file on the disk or a process in memory, there is one component in the system that is required to perform access checks, regardless of the object type.

Concepts

The concept of trust is basic in Windows NT 4.0 security. A user who is trusted on one domain in a network can potentially be trusted on other domains, depending on the trust relationships established between domains.

Trusting domains allow their resources to be used by accounts in other (trusted) domains. Trusted-domain users and global groups can hold user rights, resource permissions, and local group memberships on the trusting domain.

Domains

A domain is a networked set of Windows NT workstations and Windows NT servers that share a SAM database and can be administered as a group. A user with an account in a particular domain can log on to and access his or her account from any system in the domain.

User Manager for Domains is a system component that enables administrators to manage security for domains and computers. This includes creating and managing user accounts and groups, and managing the domain's security policies such as accounts (passwords), user rights, auditing, and trust relationships.

Trust Relationships

A trust relationship is a link between two Windows NT Server domains. Administrators can use trust relationships to add and remove trusting domains (resource domains) and trusted domains (account domains).

Trust relationships can allow a user to access resources on the entire network using a single user account and a single password. This moves the convenience of centralized administration from the domain level to the network level.

Although small organizations can store accounts and resources in a single domain, large organizations typically establish multiple domains. With multiple domains, accounts are usually stored in one domain and resources in another domain or domains.

Note: For C2 evaluation, it is assumed that the whole network is linked by mutual trust relationships. Thus, all trusted users are trusted throughout the network and, conversely, an untrusted user is not trusted on any machine in the network. Windows NT has no mechanism to enforce this universal trust, but organizational procedures can be used to ensure it. While each trusted user has the same set of rights everywhere, an administrator can still use discretionary access control lists (DACLs) to limit that user's ability to access and perhaps attack other machines and resources.

For detailed information about trust relationships, and strategies for planning trust relationships between the domains of a network, see "Planning Your Domain Design" in Chapter 2, "Network Security and Domain Planning," in the Microsoft®Windows NT®Networking Guide in the Microsoft® Windows NT® Server Resource Kit,version 4.0.

Subjects and Impersonation

One objective of the Windows NT security model is to ensure that the programs a user runs don't have greater access to objects than the user does.

A subject is the combination of the user's access token plus the program acting on the user's behalf. Windows NT uses subjects to track and manage permissions for the programs each user runs.

When a program or process runs on the user's behalf, it is said to be running in the security context of that user. The security context controls what access the subject has to objects or system services. To accommodate the client-server model of Windows NT, two classes of subjects exist within the Windows NT security architecture:

• A simple subject is a process that was assigned a security context when the corresponding user logged on. It is not acting in the capacity of a protected server, which might have other subjects as clients.

• A server subject is a process implemented as a protected server (such as the Win32 subsystem), and it does have other subjects as clients. In this role, a server subject typically has the security context of those clients available for use when acting on their behalf.

In general, when a subject calls an object service through a protected subsystem, the subject's token is used within the service to determine who made the call and to decide whether the caller has sufficient access authority to perform the requested action.

Windows NT allows one process to take on the security attributes of another through a technique called impersonation. For example, a server process typically impersonates a client process to complete a task involving objects to which the server does not normally have access.

For more information on subjects and impersonation, see "Subjects and Impersonation" in Chapter 6, "Windows NT Security," of Microsoft® Windows NT® 4.0 Workstation Resource Kit.

User Accounts and Groups

The key to Windows NT security is the user accounts. An administrator can create as many accounts as are needed, and can include any user account in as many groups of accounts as are appropriate. The administrator can then permit or limit access to any computer resource to individual accounts or to groups.

A user account consists of all the information that defines a user to Windows NT. This includes such things as the user name and logon password, the groups in which the user account has membership, and the rights and permissions the user has for using the system and accessing its resources. For Windows NT Workstation, user accounts are managed with User Manager. For Windows NT Server, user accounts are managed with User Manager for Domains.

Administrators typically group users according to the types and degrees of network access their jobs require. For example, most accountants working at a certain level will probably need access to the same servers, directories, and files. By using group accounts, administrators can grant rights and permissions to multiple users at one time. Other users can be added to an existing group account at any time, instantly gaining the rights and permissions granted to the group account.

Global Versus Local Accounts

There are two types of group account, global and local accounts:

• A global group consists of several user accounts from one domain that are grouped together under one group account name. A global group can contain user accounts from only a single domain — the domain where the global group was created. "Global" indicates that the group can be granted rights and permissions to use resources in multiple (global) domains. A global group can contain only user accounts and can be created only on a domain and not on a workstation or member server.

• A local group consists of user accounts and global groups from one or more domains, grouped together under one account name. Users and global groups from outside the local domain can be added to the local group only if they belong to a trusted domain. "Local" indicates that the group can be granted rights and permissions to use resources in only a single (local) domain. A local group can contain users and global groups, but it cannot contain other local groups.

Administrative Versus General User Accounts

Use separate accounts for administrative activity and general user activity. Individuals who do administrative work on the computer should each have two user accounts on the system: one for administrative tasks, and one for general activity. To avoid accidental changes to protected resources, the account with the least privilege that can do the task at hand should be used. For example, viruses can do much more damage if activated from an account with Administrator privileges.

Guest Account

An administrator can permit limited access for casual users through the built-in Guest account. If the computer is for public use, the Guest account can be used for public logons. Prohibit Guest from writing or deleting any files, directories, or registry keys (with the possible exception of a directory where information can be left).

In a standard security configuration, a computer that allows Guest access can also be used by other users for files that they don't want to be accessible to the general public. These users can log on with their own usernames and access files in directories on which they have set the appropriate permissions. They will want to be especially careful to log off or lock the workstation before they leave it.

For more on user accounts and other user accounts, see Chapter 2, "Working with User and Group Accounts," of Microsoft® Windows NT® Server Version 4.0 Concepts and Planning.

Account Management

For discretionary access and control, Windows NT has features that enable a user or administrator to decide who can access files and how the files will be accessed.

Logon Process

The Windows NT Logon Process provides for mandatory logon to identify users. Each user must have an account and must supply a password to access that account.

Before users can access any resource on a Windows NT computer, they must log on through the Logon Process so that the Security subsystem can authenticate their username and password. After successful authentication, whenever a user tries to access a protected object, the Security Reference Monitor runs an access validation routine against the user's security information to ensure the user has permission to access the object.

Logging On and Off

All users should always press ctrl+alt+del before logging on. Trojan horse programs designed to collect account passwords can appear as a logon screen that is there waiting for you. By pressing ctrl+alt+del you can foil these programs and get the secure logon screen provided by Windows NT.

Users should either log off or lock the workstation if they will be away from the computer for any length of time. Logging off allows other users to log on (if they know the password to an account); locking the workstation does not.

Logon Passwords

Anyone who knows a user name and the associated password can log on as that user. Users should take care to keep their passwords secret. Here are a few tips:

• Change passwords frequently, and avoid reusing passwords.

• Avoid using easily guessed words and words that appear in the dictionary. A phrase or a combination of letters and numbers works well.

• Don't write a password down—choose one that is easy for you to remember.

Administrators can set password enforcement options, which include minimum password length, minimum and maximum password age, password "uniqueness" (how often a password can be reused), and controls over whether a user can— or must—change his or her password. For more on password enforcement options, see "Setting User Password (Account) Policy" in Chapter 1, "Managing Windows NT Server Domains," of Microsoft Windows NT Server Version 4.0 Concepts and Planning.

A feature that is invisible to the user is the system-level encryption of their password so that it is never passed over the wire. This encryption prevents unauthorized discovery of a user's password through wire "sniffing."

Security Identifier (SID)

Each computer is assigned a unique security identifier (SID) during Windows NT setup when the machine name is entered; this ensures that it can be identified on the network. Almost all of the network services have this security information encoded in their registry entries during setup or subsequent installation. Because the SID identifies the computer or domain as well as the user, it is critical that it be unique to maintain support for current and future applications.

For a Windows NT workstation, Windows NT server, or Windows NT primary domain controller (PDC), the SID is computed to contain a statistically unique 96-bit number. For a Windows NT backup domain controller (BDC), the SID is identical to the SID of the PDC. This primary or machine SID is the prefix of the SIDs for all the user accounts and group accounts created on the computer. The SID is concatenated with the RID of the account to create the account's unique identifier. For example, if you create several local accounts, using Regedit.exe to view the local user SIDs might show you these:

HKEY_USERS on Local Machine 
S-1-5-21-191058668-193157475-1542849698-500 Administrator 
S-1-5-21-191058668-193157475-1542849698-1000 User one 
S-1-5-21-191058668-193157475-1542849698-1001 User two 
S-1-5-21-191058668-193157475-1542849698-1002 User three 

Note that only the last four digits are incremented as new accounts are added.

Note: Microsoft does not support systems that are installed by duplicating fully installed copies of Windows NT Workstation or Server. This gives both computers the same primary SID, making security impossible to maintain. The user accounts generated on both workstations will be numbered identically, and thus local users will have rights on other computers according to the order in which the account was created. File ownership for shared or removable media is also compromised, and security for these media becomes unmanageable.

The Microsoft Knowledge Base provides a variety of articles that outline specifications and how-to information for the proper deployment of Windows NT. Part I, "Windows NT Workstation Deployment," of the Windows NT 4.0 Workstation Resource Kit provide documentation on the deployment procedures for Windows NT 4.0 Workstation. Chapter 1, "Deploying Windows NT Server," of the Windows NT 4.0 Server Resource Kit provides deployment information for Windows NT 4.0 Server.

Control of Privileges

User accounts are managed centrally. The administrator can specify group memberships, logon hours, account expiration dates, and other user account parameters via easy-to-use graphical tools. The administrator can audit all security-related events, such as logon attempts and user access to files, directories, printers, and other resources.

Prevention of Abuses

The administrator can set procedures to prevent abuses. For example:

• The system can be set to lock out a user after a prescribed number of failed logon attempts.

• Administrators can force password expiration, and set password complexity rules so that users are forced to choose passwords that are difficult to discover.

  To prevent a user from logging on, an administrator can disable or delete the user account:

  • A disabled user account still exists, but the user is not permitted to log on; a deleted user account is completely removed.

  • A disabled account still appears in the user account list of the User Manager for Domains window; a deleted account is removed from the user account list of the User Manager for Domains window, and it cannot be restored.

  • A disabled account can be reenabled at any time.

For information about how to disable and delete user accounts, see "Disabling and Enabling User Accounts" and "Deleting User Accounts" in User Manager for Domains Help.

Immediate Action

Even though the assignment of privileges is stored in a secure area of the registry, the operating system determines the level of a user's privileges by examining the user's access token. The access token is built at the time the user logs on to the local computer or connects to a remote computer. When you revoke a privilege, the registry is changed immediately, but the change is not reflected in the user's access token until the next time the user logs on (or connects).

To revoke a user's privilege immediately

Privileges have scope only for a single computer. Thus, to revoke a privilege immediately, the administrator must:

1. Revoke the user rights assignment on the computer in question.

2. Forcibly log the user off the computer.

Discretionary Access Control Lists

An administrator uses discretionary access control lists (DACLs) to provide discretionary access control to specific objects. Each DACL is made up of access control entries(ACEs), which specify access or auditing permissions to that object for one user or group of users. There are three ACE types:

• AccessAllowed grants access to a user or group of users.

• AccessDenied denies access. The first AccessDenied ACE denies the user access to the resource, and no further processing of ACEs occurs.

• SystemAudit is a system security ACE, used to keep a log of security events (such as who accesses which files) and to generate and log security audit messages.

The following information on DACLs is digested from "Access Control Lists and Access Control Entries" in Chapter 6, "Windows NT Security," of Microsoft® Windows NT® 4.0 Workstation Resource Kit. For more detail on DACLs, and specific access rights for Windows NT objects, see Appendix B.

Object Types

The type of permissions that can be granted or denied for an object are dictated by the object's type. For example, you can specify permissions like Manage Documents and Print for a printer queue, and for a directory you can specify Read, Write, Execute, and so on.

Another quality that affects the permissions of an object is whether that object is a container object or a noncontainer object. A container object is one that logically contains other objects; noncontainer objects do not contain other objects. For example, a directory is a container object that logically contains files and other directories. Files are noncontainer objects.

This distinction between container and noncontainer objects is important because objects within a container object can inherit certain permissions from the parent container. By default, when you create new objects within a container object, the new objects inherit permissions from the parent.

In the case of files and directories, when you change permissions on a directory, those changes affect that directory and its files but do not automatically apply to existing subdirectories and their contents. They do, however, if you check the Replace Permissions On Existing Files checkbox as in the following illustration. You can apply the changed permissions to existing subdirectories and their files by selecting the Replace Permissions On Subdirectories check box.

Access Masks

Each ACE includes an access mask, which defines all possible actions for a particular object type. Permissions are granted or denied on the basis of this access mask. There are three types of access:

• Specific access types. Each object type can have up to 16 access types. Collectively, the access types for a particular object type are called the specific access mask.

• Standard access types. These apply to all objects and consist of these access permissions: SYNCHRONIZE, to synchronize access and to allow a process to wait for an object to enter the signaled state; WRITE_OWNER, to assign write owner; WRITE_DAC, to grant or deny write access to the DACL; READ_CONTROL, to grant or deny read access to the security descriptor and owner; and DELETE, to grant or deny delete access.

• Generic access types. These are broad types of access whose exact implementation is determined by the application defining an object. These rights are used when protecting an object. Although specific and standard types appear in the security log, generic types do not. Instead, the corresponding specific and standard types are listed.

Access Validation

When a user tries to access an object, Windows NT compares security information in the user's access token with the security information in the object's security descriptor. A desired access mask for the subject is created based on what type of access the user is attempting. This desired access mask, usually created by a program that the user is running, is compared with the object's DACL. Each ACE in the DACL is evaluated in this way:

1. The SID in the ACE is compared with the set of SIDs in the user's access token. If a match is not found, the ACE is skipped.

   Further processing is based upon the type of the ACE. AccessDenied ACEs are ordered (and therefore processed) before AccessAllowed ACEs.

2. If access is denied, the system checks to see if the original desired access mask contained only a ReadControl and/or WRITE_DAC. If so, the system also checks to see if the requester is the owner of the object. In this case, access is granted.

3. For an AccessDenied ACE, the accesses in the ACE access mask are compared with the desired access mask. If there are any accesses in both masks, further processing is not necessary, and access is denied. Otherwise, processing continues with the next requested ACE.

4. For an AccessAllowed ACE, the accesses in the ACE are compared with those listed in the desired access mask. If all accesses in the desired access mask are matched by the ACE, no further processing is necessary, and access is granted. Otherwise, processing continues with the next ACE.

5. At the end of the ACL, if the contents of desired access mask are still not completely matched, access is implicitly denied.

Other System Security Features

Other uses of Windows NT can be controlled, such as access to printers and network-server sharepoints. These features are discussed in detail in the product documentation for Windows NT and in the Windows NT resource kits.

File and Directory Protection

An administrator can set a range of file protections on a per-file or per-directory basis. The permissions can be on a per-user or per-group basis. Specific files to protect are discussed in Chapter 2 of this manual, in the "Protecting Files and Directories" section under "High-Level Security."

Registry Protection

Since the registry is the repository of all system configuration information, it is important to protect it from unauthorized changes. At the same time, individuals and programs that need to access or alter information in the registry must be allowed to do so. Protection of registry keys is discussed later in this manual, in the "Protecting the Registry" sections under "Standard Security" and "High-Level Security."

For more about protecting keys in the registry, see Appendix A, "Windows NT Registry," of Microsoft Windows NT Server Version 4.0 Concepts and Planning. For more about the registry and the Registry Editor, see Part V, "Windows NT Registry," of the Windows NT Workstation 4.0 Resource Kit.

Printer Protection

Central control of printing through a print server allows the print server administrator to specify which client computers, or which users, are allowed to print to which network printers. A domain may have many print servers, and each of those servers may serve many printers. The domain administrator may allow full discretion to each print server administrator or may set domain-wide printing policies that cannot be overridden at the print server level.

For more about printer access settings, see "Planning How Users Access Printers" in Chapter 5, "Setting Up Print Servers," of Windows NT Server 4.0 Concepts and Planning.

Secure Attention Sequence

Identification and authentication in Windows NT are achieved through the logon Secure Attention Sequence. All users must log on to start Windows NT. Before Windows NT users type their usernames and passwords to log on locally, they must first press CONTROL+ALT+DELETE. This key combination interrupts any program that may be running, including any Trojan horse program that may have been surreptitiously installed.(A Trojan horse is a program that can capture a user's logon information, thereby providing network access.) Because each user has a unique username, domain name, and password combination, Windows NT can assure a user's unique identity.

Object Reuse

One of the important issues in software security is object reuse. In a secure operating system, such as Windows NT, all allocation and deallocation of objects (such as files, directories, and memory) must be protected. Only users with proper access permissions should be allowed access. In Windows NT, administrators achieve this through a robust object manager that either initializes or zeroes out objects before presenting them to a user.

Performance Monitoring

The Windows NT Performance Monitor not only helps administrators fine-tune performance, it can also give warning of approaching problems before they are noticeable by the computer user. Performance Monitor can also help you spot the activity of a virus (by spotting performance degradation) or an attempted break-in (by tracking logon attempts). Performance Monitor can be set to send an alert to one or more administrators when certain events occur.

For more about Performance Monitor, see Chapter 8, "Monitoring Performance," in Windows NT Workstation 4.0 Concepts and Planning; and Part III, "Optimizing Windows NT Workstation," in the Windows NT Workstation 4.0 Resource Kit.

Note: Performance Monitor is an optional service that should not be enabled if a system is to be qualified at the C2 level. It was not included in the networked C2 evaluation.

Event Log

Windows NT Server includes software to write information to the security event log and to audit the log for possible attempts to breach security. You can log things like:

• Access to files.

• Invalid logon attempts.

• All logons.

The Audit policy, set by the administrator, controls what types of events are recorded in the security log.

For more about the security log, see Chapter 9, "Monitoring Events," in Microsoft Windows NT Server Version 4.0 Concepts and Planning; and Chapter 6, "Windows NT Security," and Appendix B, "Security In a Software Development Environment," in the Windows NT Workstation 4.0 Resource Kit.

Physical Security

Windows NT enables you to manage what your users can and cannot do by creating profiles for each of your users and restricting their access to files and servers. But no amount of planning will cover all of the ways people can cause damage to data on your computers or to the computers themselves. Thus an important area to consider in your planning is minimizing the effects of human error or deliberate sabotage attempts. If anyone can walk up to your computer running Windows NT and restart it, no amount of security that you implement by using software can protect your computer. Not only can they damage information on the computer, but they can steal information from your computer.

Access to Hardware

Administrators and users can implement procedures that restrict people's physical access to a facility, or to only those areas to which they should need access:

• Put your computers in a secure room.

• Lock both the room and the computers.

• Use a password on your screen saver.

• Run virus checks on floppy disks before you use them. Or disable the floppy disk, which you can sometimes do by using BIOS options. Otherwise, you can physically disconnect it.

• Run virus checks on your computer.

Servers that have externally accessible devices (e.g., hot-swappable disks) should be locked in a secured area away from untrusted users.

Warning: Do not introduce unknown media to the configuration, such as floppy disks and tapes that may contain sensitive information. In addition, since access to tapes is not protected by Windows NT, tape devices should only be installed in server configurations that are physically protected and do not allow untrusted users to log on. Only removable media devices that do not support downloadable firmware should be installed; this protects against the possibility of attacking the system via insertion of media into such devices.

Backup and Storage

Consider security when you develop your backup and storage procedures. Specifically, you should consider the risk of inadvertent disclosure when moving media from one machine to another. The backup media need to be carefully controlled so that they are kept logically associated with the machine that generated them. This is because DACLs do not have the same meaning from one platform to another.

For more information on security considerations in doing backup, see the following references:

• "Setting Tape Options," "Granting Backup and Restore Privileges," and "Setting Log Options for Backup and Restore" in Chapter 6, "Backing Up and Restoring Network Files," in Windows NT Server 4.0 Concepts and Planning

• "Cacls: Changes ACLs of NTFS Files and Folders," in Chapter 22, "Disk, File System, and Backup Utilities," in the Windows NT Workstation 4.0 Resource Kit.

Access to the Network

When you put a computer on a network, you add an access route to the computer. The two risks from network connections are other users on the network and unauthorized taps on the network. If everyone on the network has the security clearance needed to access your secure computer, you will probably prefer to include the computer in the network, to make it easier for these people to access data on the computer.

Warning: The UDP and TCP do not directly support the ability to identify, authenticate, or restrict access to potential clients. As a result, each server should implement its own mechanisms (e.g., passwords, cryptographic scheme, alternate protected communication mechanisms) to control access to UDP and TCP ports. While TCP supports the ability to establish a guaranteed private connection between a server and client, UDP does not. Therefore, any implemented mechanisms should be at the granularity of connections for TCP and individual packets for UDP.

Auditing Security Events

Using Windows NT, an administrator can audit all security events and user actions. User Manager enables you to specify which events (such as logon or file access) will be monitored. All audited information is stored in the Event Log, which can be viewed in Event Viewer.

Auditing is built into Windows NT. This allows you to track which user account was used to attempt what kind of access to files or other objects. Auditing also can be used to track logon attempts, system shutdowns or restarts, and similar events.

Audit Features

Windows NT includes auditing features you can use to collect information about how your system is being used. These features also allow you to monitor events related to system security, to identify any security breaches, and to determine the extent and location of any damage. The level of audited events is adjustable to suit the needs of your organization. Some organizations need little auditing information, whereas others would be willing to trade some performance and disk space for detailed information they could use to analyze their system.

Note: When you enable auditing, there is a small performance overhead for each audit check the system performs.

Windows NT can track events related to the operating system itself and to individual applications. Each application can define its own auditable events. Definitions of these events are added to the registry when the application is installed on your Windows NT computer.

Audit Record Format

Audit events are identified to the system by the event source module name (which corresponds to a specific event type in the registry) and an event ID. The domain administrator can receive audit logs from all machines in the network and compare them to track the actions of any user. However, there is no central network audit trail. Rather, audit records are maintained by individual machines, each of which enforces its own security policy.

Warning: Set the clock manually on each workstation in the network. Otherwise, clock drift between workstations can make events appear out of sequence. It could appear that a user logged out before they logged in if clock drift is not considered.

In addition to listing events by event ID, the security log in Event Viewer lists them by category. The following categories of events are displayed in the Security Log. (Those in parentheses are found in the Audit Policy dialog box of User Manager.)

Table 1.1 Security Log Event Categories

Category	Meaning
Account Management (User and Group Management)	These events describe high-level changes to the user accounts database, such as User Created or Group Membership Change. Potentially, a more detailed, object-level audit is also performed (see Object Access events).
Detailed Tracking (Process Tracking)	These events provide detailed subject-tracking information. This includes information such as program activation, handle duplication, and indirect object access.
Logon/Logoff (Logon and Logoff)	These events describe a single logon or logoff attempt, whether successful or unsuccessful. Included in each logon description is an indication of what type of logon was requested or performed (that is, interactive, network, or service).
Object Access (File and Object Access)	These events describe both successful and unsuccessful accesses to protected objects.
Policy Change (Security Policy Changes)	These events describe high-level changes to the security policy database, such as assignment of privileges or logon capabilities. Potentially, a more detailed, object-level audit is also performed (see Object Access events).
Privilege Use (Use of User Rights)	These events describe both successful and unsuccessful attempts to use privileges. It also includes information about when some special privileges are assigned. These special privileges are audited only at assignment time, not at time of use.
System Event (System)	These events indicate something affecting the security of the entire system or audit log occurred.

For a depiction of the audit record format and an explanation of its fields, see Chapter 9, "Monitoring Events," of Microsoft® Windows NT® Server Version 4.0 Concepts and Planning. For examples of audited security events, see "Security Event Examples" in Chapter 6, "Windows NT Security," in the Windows NT Workstation 4.0 Resource Kit.

Audit Record Loss Potential

The LSA and the Security Reference Monitor (SRM) each construct audit records. Such records can be lost from the LSA and SRM record queues if the correct value is not set for the CrashOnAuditFail entry in the registry key HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \Lsa.

The SRM constructs audit events for all the categories except Logon/Logoff, Account Management, and Policy Change. The SRM generates an audit record when requested by a user-mode server with the audit privilege or by an executive subsystem. The SRM then places the record, as a message, in its audit record queue. Records in this queue are sent to the LSA, where they are queued for processing and formatting.

The SRM maintains high and low water marks for its queue. If the value for the registry key CrashOnAuditFail is set to zero and the high water mark is reached, the SRM discards the newest records until it reaches the low water mark, and it generates a nondiscardable audit event telling how many records were discarded. The following is the entry for this nondiscardable audit event in the security log.

Event ID: 516

Type: Success Audit

Description: Internal resources allocated for the queuing of audit messages have been exhausted, leading to the loss of some audits.

Number of audit messages discarded: N

Audit records can also be discarded if the capacity of the LSA queue is exceeded. The LSA generates a nondiscardable audit event indicating how many records were discarded. The format of the security log entry is the same as above.

If CrashOnAuditFail is set to 1, the system will shut down when either the SRM or LSA queue is full. When the computer is restarted, only members of the Administrators group can log on until the Security log is cleared. This gives an administrator the opportunity to save the log. The maximum number of audit events that could be lost in such a shutdown equals the combined capacities of the two queues:

SRM high water mark: ULONG = 12,288 event records

LSA queue capacity: 500 event records.

Halting the Computer When the Security Log is Full

If you have set the security log either to "Overwrite Events Older than n Days" or "Do Not Overwrite Events (Clear Log Manually)", you can prevent auditable activities while the log is full. No new audit records can be written. To do so, create or assign a registry value using the following procedure.

To have the system shut down when log capacity is reached

1. Use Registry Editor to go to HKEY_LOCAL_MACHINE \SYSTEM subtree.

2. Go to the following key: \CurrentControlSet\Control\Lsa.

3. Add the entry:

   Key: CrashOnAuditFail

   Type: REG_DWORD

   Value: 1

   The changes take effect the next time the computer is started. You can update the Emergency Repair Disk to reflect these changes.

If Windows NT Server halts as a result of a full security log, the system must be restarted and reconfigured to prevent auditable activities from occurring again while the log is full. After the system is restarted, only administrators can log on until the security log is cleared. For more information on recovering after Windows NT halts, see the "Recovering After Windows NT Halts Because it Cannot Generate an Audit Event Record" in Event Viewer Help.

When a log is full (when no more events can be logged), you can free the log by clearing it. Reducing the amount of time you keep an event also frees the log if it allows the next record to be overwritten. For information on how to clear a log, see "Clearing All Events" in Event Viewer Help.

Additional Resources

• For more information about security policies, see Chapter 2, "Network Security and Domain Planning," in the Microsoft®Windows NT® Server Networking Guide.

• For more information about security features, see Chapter 3, "Managing User Work Environments," and Chapter 4, "Managing Shared Resources and Resource Security," in Microsoft®Windows NT® Server Concepts and Planning.

• For more information about discretionary access control, physical security, and security features available when you are running Windows NT, see Chapter 6, "Windows NT Workstation Security Model," in the Microsoft®Windows NT® Workstation Resource Guide.

• For a discussion of physical isolation in a network connected to the Internet, see "Physical Isolation" in Chapter 3, "Server Security on the Internet," in the Microsoft®Windows NT® Server Internet Guide.

Chapter 2 - Levels of Security

Microsoft® Windows NT® allows administrators to establish a range of levels of security, from none at all to the discretionary access control that many government agencies require. This chapter describes three levels of security—"Minimal," "Standard," and "High"—and the options used to provide each level. These levels are arbitrary, and you will probably want to create your own "level" by blending characteristics of the levels presented here.

Discretionary access control at the C2 level is a form of "High" security but is not specifically discussed here; Chapter 3 gives step-by-step instructions for achieving C2 security.

Note: C2 is not "high" security by U.S. government standards: levels A and B provide greater security. However, C2 is a high rating for business computing products.

Why not have maximum security at all times? One reason is that the limits you set on access to computer resources make it a little harder for people to work with the protected resources. Another reason is that it is extra work to set up and maintain the protections you want. For example, if only users who are members of the Human Resources (HR) user group are allowed to access employee records, and a new person is hired to do that job, then someone needs to set up an account for the new hire and add that account to the HR group. If the new account is created but not added to HR, the new hire cannot access the employee records and therefore cannot perform his or her job.

If the security is too tight, users will try to circumvent security in order to get work done. For example, if you set the password policy so that passwords are hard to remember, users will write them down to avoid being locked out. If some users are blocked from files they need to use, their colleagues might share their own passwords in order to promote the flow of work.

The first step in establishing security is to make an accurate assessment of your needs. Then choose the elements of security that you want, and implement them. Make sure your users know what they need to do to maintain security, and why it is important. Finally, monitor your system and make adjustments as needed.

Minimal Security

You might not be concerned with security at all if the computer is not used to store or access sensitive data or if it is in a very secure location. For example, if the computer is in the home office of a sole proprietor of a business, or if it is used as a test machine in the locked lab of a software development company, then security precautions might be unnecessarily cumbersome. Windows NT allows you to make the system fully accessible, with no protections at all, if that is what your setup requires.

Nevertheless you should take the precautions you would with any piece of valuable equipment to protect against casual theft. This step can include locking the room the computer is in when no one is there to keep an eye on it, or using a locked cable to attach the unit to a wall. You might also want to establish procedures for moving or repairing the computer so that the computer or its components cannot be taken under false pretenses.

Use a surge protector or power conditioner to protect the computer and its peripherals from power spikes. Also, perform regular disk scans and defragmentation to isolate bad sectors and to maintain the highest possible disk performance.

By default, access is limited to certain files. For minimal security, give the Everyone group full access to all files.

You should still take precautions against viruses, since they can disable programs you want to use or use the minimally secure computer as a vector to infect other computer systems.

For a fuller discussion of minimal security, see Chapter 6, "Windows NT Security," in the Microsoft® Windows NT® Workstation Version 4.0 Resource Kit.

Standard Security

Most often, computers are used to store sensitive and/or valuable data. This data could be anything from financial data to personnel files to personal correspondence. Also, you might need to protect against accidental or deliberate changes to the way the computer is set up. But the computer's users need to be able to do their work, with minimal barriers to the resources they need.

General guidelines for standard security are as follows:

• Physical Security. The computer should be protected as any valuable equipment would be. Generally, this involves keeping it in a building that is locked to unauthorized users. You might want to use a cable and lock to secure the computer to its location.

• Logging Off or Locking the Workstation. Logging off allows other users to log on (if they know the password for an account); locking the workstation does not. The workstation can be set to lock automatically if it is not used for a set period of time by using any 32-bit screen saver with the Password Protected option. For information about setting up screen savers, see Window NT Workstation Help.

• Off-the-Shelf versus Custom Software. If you are using software made especially for your installation, or shareware that you aren't sure you can trust, you might want to look at Appendix B, "Security In a Software Development Environment," in the Windows NT Workstation 4.0 Resource Kit. This provides information on settings and calls that can support—or circumvent—security settings.

• Displaying a Legal Notice Before Logon. Windows NT can display a message box with the caption and text of your choice before a user logs on. Many organizations use this message box to display a warning message that notifies potential users that they can be held legally liable if they attempt to use the computer without having been properly authorized to do so.

• User Accounts and Groups. With standard security, a user account (user name) and password should be required in order to use the computer. You can establish, delete, or disable user accounts with User Manager, which also allows you to set password policies and organize user accounts into Groups.

• Administrative Accounts versus User Accounts. It is a good idea to rename the built-in Administrator account to something less obvious. This powerful account is the one account that can never be locked out due to repeated failed logon attempts, and consequently is attractive to hackers who try to break in by repeatedly guessing passwords. By renaming the account, you force hackers to guess the account name as well as the password.

• Limiting the Guest Account. Prohibit Guest from writing or deleting any files, directories, or registry keys (with the possible exception of a directory where information can be placed).

• Backups. Regular backups protect your data from hardware failures and honest mistakes, as well as from viruses and other malicious mischief. Backup privileges should be limited to administrators and backup operators—people to whom you are comfortable giving read and write access on all files.

• Protecting Files and Directories. The NTFS file system provides more security features than the FAT system, and should be used whenever security is a concern. With NTFS, you can assign a variety of protections to files and directories, specifying which groups or individual accounts can access these resources in which ways. By using the inherited permissions feature and by assigning permissions to groups rather than to individual accounts, you can simplify the chore of maintaining appropriate protections.

• Protecting the Registry. The Registry Editor should be used only by individuals who thoroughly understand the tool, the registry itself, and the effects of changes to various keys in the registry. Mistakes made in the Registry Editor could render part or all of the system unusable.

• Auditing. Auditing can inform you of actions that could pose a security risk and also identify the user accounts from which audited actions were taken. When you establish an audit policy you need to weigh the cost (in disk space and CPU cycles) of the various auditing options against the advantages of these options. You'll want to at least audit failed logon attempts, attempts to access sensitive data, and changes to security settings.

• Managing the Security Log. A regular task of network administration is examining the security log to track significant events and monitor system usage, and clearing the log as necessary. It is recommended that you routinely archive the log before clearing it. You can specify the maximum size for the security log, and what happens when that size is reached.

High-Level Security

The standard security precautions are sufficient for most installations. However, additional precautions are available for computers that contain very sensitive data, or that are at high risk for data theft or the accidental or malicious disruption of the system.

Securing the Network

To eliminate unauthorized access over the network, user validation and protections on files and other objects are sufficient for standard-level security. For high-level security, however, make sure the network itself is secure, or in some cases you might need to isolate the computer completely.

If the network is entirely contained in a secure building, the risk of unauthorized taps is minimized or eliminated. If the cabling must pass through unsecured areas, use optical fiber links rather than twisted-pair cable to foil attempts to tap the wire and collect transmitted data.

If your installation needs access to the Internet, you should be aware of the security issues involved in providing access to—and from—the Internet community. Chapter 3, "Server Security on the Internet," in the Microsoft® Windows NT® Server Version 4.0 Internet Guide contains information on using network topology to provide security.

Limiting the Ability to Power On the Computer

You might choose to keep unauthorized users away from the power or reset switches on the computer, particularly if your computer's rights policy denies them the right to shut down the computer. The most secure computers (other than those in locked and guarded rooms) expose only the computer's keyboard, monitor, mouse, and (when appropriate) printer to users. The CPU and removable media drives can be locked away where only specifically authorized personnel can access them.

On many hardware platforms, the system can be protected using a power-on password. A power-on password prevents unauthorized personnel from starting an operating system other than Windows NT, which would compromise system security. Power-on passwords are a function of the computer hardware, not the operating system software. Therefore the procedure for setting up the power-on password depends on the type of computer, and is available in the vendor's documentation supplied with the system.

Restricting the Boot Process

Most personal computers support the ability to start a number of different operating systems. For example, even if your users normally start Windows NT from drive C, someone could boot another operating system from removable media on another drive, such as a floppy disk drive or a CD-ROM drive. If this happens, any security precautions you have taken within your version of Windows NT might be circumvented.

In general, you should install only those operating systems that you want to be used on the computer you are setting up. For a highly secure system, this will probably mean installing only Windows NT and only one version of it. However, you still need to protect the CPU physically to ensure that no other operating system is loaded. Depending on your circumstances, you might choose to remove the floppy disk drive or drives. In some computers you can disable booting from the floppy disk drive by setting switches or jumpers inside the CPU. If you use hardware settings to disable booting from the floppy drive, you might want to lock the computer case (if that is an option with the computer you have) or lock the machine in a cabinet with a hole in the front to provide access to the floppy disk drive. If the CPU is in a locked area away from the keyboard and monitor, drives cannot be added or hardware settings changed for the purpose of starting from another operating system.

Controlling Access to Removable Media

By default, Windows NT allows any program to access files on floppy disks and CDs. In a highly secure, multi-user environment, you might want to allow only the person interactively logged on to access those devices. This allows the interactive user to write sensitive information to these drives, confident that no other user or program can see or modify that data.

When operating in this mode, the floppy disks and CDs on your system are allocated to a user as part of the interactive logon process. These devices are automatically freed for general use or for reallocation when that user logs off. Because of this, it is important to remove sensitive data from the floppy disk or CD-ROM drives before logging off.

Hiding the Last User Name

By default, Windows NT places the user name of the last user to log on the computer in the User name text box of the Logon dialog box. This makes it more convenient for the most frequent user to log on. To help keep user names secret, you can prevent Windows NT from displaying the user name from the last logon. This is especially important if a computer that is generally accessible is being used for the (renamed) built-in Administrator account.

Disabling Shutdown Without Logon

Normally, when running Windows NT Workstation, you can click Shutdown in the Logon dialog box to shut down the computer without logging on. This is appropriate where users can access the computer's operational switches; otherwise they might turn off the computer's power or reset it improperly. Where this feature is inappropriate--for example, if the CPU is locked away so users cannot access the switches--you can remove it. This step is not required for Windows NT Server, which is configured this way by default.

Limiting User Rights

There are several user rights that administrators of high-security installations should be aware of and possibly audit. Of these, you might want to change the default permissions on two rights, as follows:

User Right	Allows a user to:	Groups assigned this right by default	Recommended change
Log on locally	Log on at the computer, from the computer's keyboard	Administrators, Backup Operators, Everyone, Guests, Power Users, and Users	Delete Everyone and Guests from the list of groups assigned this right.

Shut down the system (ShutdownPrivilege)

Shut down Windows NT

Administrators, Backup Operators, Everyone, Power Users, and Users

Delete Everyone and Users from the list of groups assigned this right.

Protecting Files and Directories

Among the files and directories to be protected are those that comprise the operating system (OS) itself. These are stored in the System32 directory. The standard permissions on system files and directories provide reasonable security without interfering with the computer's usability. For high level security installations, however, you might want to set permissions to allow a maximum of read-only access to untrusted users on most OS directories, subdirectories and existing files immediately after installing Windows NT. Be sure to apply permissions to parent directories before applying permissions to subdirectories.

You can protect the folder and its contents by giving full control to Administrators and LocalSystem, READ & EXECUTE to Everyone.

To view the System32 files in Windows NT Explorer

1. From the View menu, point to Arrange Icons, and then click by Type.

2. From the View menu, click Folder Options.

3. In the Folder Options dialog box, click View.

4. Under Hidden files, select the Show all files check box.

Protecting the Registry

In addition to the considerations for standard security, the administrator of a high-security installation might want to set protections on certain keys in the registry.

By default, protections are set on the various components of the registry that allow work to be done while providing standard-level security. For high-level security, you might want to assign access rights to specific registry keys. This should be done with caution because programs that the users require to do their jobs often need to access certain keys on the users' behalf.

Disabling the Schedule Service (AT Command)

The Schedule service (also known as the AT command) is used by administrators to schedule tasks to run automatically at a preset time. Because the scheduled task is run in the context run by the Schedule service (typically the operating system's context), this service should not be used in a highly secure environment. Therefore it is not available in the C2-evaluated configuration.

For more on the AT command, see "Backup Utilities" in Chapter 22, "Disk, File System, and Backup Utilities," in the Windows NT Workstation 4.0 Resource Kit.

Chapter 3 - C2 Level Security

The C2 level of security is a government rating for business software; it corresponds to high-level security, discussed in Chapter 1. C2 is a good commercial security level target, and a configuration that is rated C2 serves as an excellent building block in an overall system security plan. That building block can be modified, and the risks in so doing can be measured and accepted by various hosting organizations.

The C2 evaluation ensures that Microsoft® Windows NT® can properly enforce your security policy, but does not dictate what that policy should be. To set policy, you need to choose the combination of security features that fits your combination of resources, personnel, work flow, and perceived risks. A certification and accreditation process results in approval of your policy for government work.

Meaning and Value of the C2 Rating

U.S. government security levels for computing systems range from A (the highest) to D. The C level designates a system that has controls capable of enforcing access limitations on an individual basis. This level has two sublevels, C1 and C2.

C2 is the higher level, with more finely grained access control. A C2 system has the following capabilities:

• The owner of a system resource has the right to decide who can access it.

• The operating system can detect when data is accessed and by whom.

Requirements for C2 Compliance

The U.S. government standard for evaluating computer system security is the National Computer Security Center (NCSC) publication Department of Defense Trusted Computer System Evaluation Criteria (TCSEC), commonly called the Orange Book for the color of its cover. The TCSEC sets out criteria used to rate software on the basis of functional categories such as access control, authentication, object reuse, and auditing.

As outlined by the TCSEC, a C2 operating system must be able to:

• Define and control its users' access to objects, such as files and directories.

• Provide a way for users to uniquely identify themselves.

• Provide a way to audit security-related events and actions of individual users.

• Prevent all processes from accessing the data for other processes.

Microsoft has worked closely with the U.S. government to ensure that the features of Windows NT meet the criteria for C2 compliance. Table 3.1 compares the C2 criteria with Windows NT features that are designed to comply with them.

Table 3.1 C2 Criteria and Windows NT Equivalents

C2 Criterion	Function	Windows NT Server Feature(s) Implementing Criterion
Secure logon facility	Users must identify themselves by entering a unique logon identifier and password before they are allowed access to the system.	Secure Attention Sequence
Discretionary access control	The owner of a resource grants access rights to a user or group of users. In this way the owner can determine who has access and what they can do to the resource.	Access Control List
Auditing	A record is made of important security-related events or any attempt to create, access, or delete system resources. Logon identifiers record the identity of the user who performed the action.	Event logs
Memory protection	No one can read information written by someone else after a data structure is released back to the operating system. Memory is reinitialized before use.	NTFS file system: · Memory and files cannot be accessed directly. · NTFS-deleted files cannot be undeleted.
	.	Object Reuse (data in memory is not left behind to be reused)
		Kernel runs in 32-bit protected mode

Certification and Accreditation

To use your C2-compliant configuration for government work, you may need to have it certified and accredited. The NCSC describes "certification" as a plan to use computer systems in a specific environment, and "accreditation" as the evaluation of that plan by administrative authorities. It is this certification plan, and the subsequent accreditation procedure, that balances the sensitivity of the data being protected against the environmental risks present in the way the computing systems are used.

Considerations

Many features of Windows NT need to be considered when determining how to use the computer within your specific environment. What level of auditing will you require? How should your files be protected to ensure that only appropriate users can access them? What applications should you allow people to run? Should you use a network? If so, what level of physical isolation of the actual network cable is needed?

For example, a certification plan for a university computing lab might require that startup from a floppy disk be disabled, thus minimizing the risk of infection by viruses or Trojan horses. However, in a top-secret Defense Department development lab, it might be necessary to go much further and have a fiber-optic LAN to prevent generation of electronic emissions. A good certification plan covers all aspects of security, from backup and recovery mechanisms to the use of locked rooms and security guards.

Due Diligence

Commercial work may not require accreditation, but to minimize liability it may be advisable to provide evidence of due diligence in configuring a system that is C2 compliant to the extent feasible. An organization shows due diligence if it employs a reasonable standard of care to guard data consistent with the sensitivity of the data and the technology available. In business, due diligence is particularly important in network transfers of money, credit information, medical records, and other sensitive information.

Needless to say, due diligence needs to be documented. This requires a plan similar to a certification plan, explaining the tradeoffs that were made in selecting system components and features.

C2 and C2-Equivalent Evaluations of Windows NT

Microsoft has been committed to the product evaluation process since issuing the first version of Windows NT. The process is lengthy and detailed, such that it is almost impossible to keep every version of a product evaluated on a timely basis. However, Windows NT has completed such evaluation under two rating systems:

• The Department of Defense Trusted Computer System Evaluation Criteria (TCSEC), used in the United States.

• The Information Technology Security Evaluation Criteria (ITSEC) and its equivalents, used in the United Kingdom and several other countries.

A new international rating system, the Common Criteria, has been agreed upon by several countries and will be used in the future. The various rating systems are discussed in the Appendix, "Software Security Rating Systems."

Currently, Windows NT has the following status in regard to C2 security and its equivalents.

Windows NT 3.5

Microsoft® Windows NT® version 3.5 with U.S. Service Pack 3 has been evaluated and rated at the C2 level by the U.S. government for stand-alone Compaq ProLiant 2000 and 4000 and Digital Alpha DECpc AXP/150 hardware platforms.

In 1991, Microsoft submitted Windows NT for platform evaluation by the U.S. National Computer Security Center (NCSC), the federal agency charged with evaluating software product security. In July 1995, Windows NT met its first milestone: C2 recognition for the base operating system.

The NCSC also recognized two features of the operating system as meeting requirements of the B2 level. The B2 class is characterized by strengthened authentication mechanisms, trusted facility management in the form of support for system administrator and operator functions, and stringent configuration management controls. The two B2-level features are Trusted Path and Trusted Facility Management:

• The Trusted Path functionality uses the authentication mechanism of the Secure Attention Sequence, described in Chapter 1, whereby users must press CONTROL+ALT+DELETE to log on. This prevents Trojan horse programs from intercepting user name and password information during logon.

• The Trusted Facility Management functionality supports separate account roles for operator and administrator functions. For example, Windows NT provides separate administrative roles for Administrators, users tasked with backups, users tasked with administering print servers, privileged Power Users, and Users.

Windows NT 3.51

Microsoft® Windows NT® version 3.51 has met the E3/F-C2 criteria of the United Kingdom for networking, trusted relationships, and stand-alone configurations. The U.K. evaluation used newer Compaq systems and no Alphas. F-C2 is comparable to the U.S. C2 rating. For more information about E3, see "ITSEC Assurance Level" in the Appendix.

The evaluation of Windows NT 3.51 to the E3/F-C2 security level included user account policies, workstation locking, user roles, access control lists and privileges, and a trusted path for logon. The extension of these facilities to the network was also evaluated, including centralized security management, multiple logical domains of workstations and servers, domain-wide user account and accountability policy, domain-wide global groups, restriction on logon hours, and trust relationships between domains.

Domain-based security functionality was included up to the transport driver interface; underlying network protocols and architectures were excluded.

The U.K. evaluation of Windows NT 3.51 resulted in a certification report, which is available over the Internet at the ITSEC Website, https://www.itsec.gov.uk.

Windows NT 4.0

Windows NT 4.0 with U.S. Service Pack 6a was evaluated in the U.S. for a C2 rating in a networked environment. The evaluation used Compaq ProLiant5100, 6500, 7000, and 8000 hardware in both single-processor and multiprocessor configurations. The TCP/IP protocol was used to interconnect the tested network.

For a report on the results of this evaluation, see the Microsoft Security Web site, https://www.microsoft.com/security.

Windows 2000

Microsoft® Windows® 2000 and later versions will be submitted for evaluation under the new international Common Criteria. This evaluation methodology was designed to allow a successful security evaluation in one country to be accepted in other countries without the need for repeated testing.

For more information on the Common Criteria, see "Common Criteria: A New International Standard" in Appendix A.

Note: Windows NT 3.5 and Windows NT 3.51 are no longer available on Microsoft CDs, although 3.5 can still be ordered through Microsoft Inside Sales. Purchase of a Windows NT 4.0 license allows the owner to run these earlier versions, and Microsoft will supply the Windows NT 3.5 or Windows NT 3.51 software upon application.

Additional Resources

If you need to set up a C2-certifiable system, see Chapter 4, "Microsoft Report on C2 Evaluation of Networked Windows NT." That chapter lists the hardware configurations in which Windows NT has been evaluated. Chapter 4 also specifies the feature configurations that were implemented for C2 evaluation, so that you can duplicate them if necessary for your own C2-certifiable system.

You might also study Appendix B, "Security In a Software Development Environment," in the Microsoft® Windows NT® Workstation Version 4.0 Resource Kit, especially if you are using custom or in-house software. This appendix provides information on managing and interpreting the security log, and technical details on special-case auditing (for example, auditing base objects). The Windows NT product documentation and the Microsoft® Windows NT® Resource Kit also provide information on features that may fit your particular combination of resources, personnel, work flow, and perceived risks.

Chapter 4 - Microsoft Report on C2 Evaluation of Networked Windows NT

Today, computer networks are becoming increasingly important to most businesses. Networks are used to share key information and resources among many users throughout organizations of various sizes. Frequently, the information stored on network servers, such as the Microsoft® Windows NT® Server operating system, is secure information that is intended for use only by specific individuals. Therefore, the ability of these networks to prevent unauthorized access to information is paramount to the security and competitiveness of an organization.

Characteristics of a Secure System—C2 and Beyond

One measure of a secure operating system is the U.S. Department of Defense's criteria for a C2-level secure system. While C2 security is a requirement of many U.S. government installations, its substantial value extends to any organization concerned about the security of its information.

Some of the most important requirements of C2-level security are:

• The owner of a resource (such as a file) must be able to control access to the resource.

• The operating system must protect data stored in memory for one process so that it is not randomly reused by other processes. For example, Windows NT protects memory so that its contents cannot be read after it is freed by a process. In addition, when a file is deleted, users must not be able to access the file's data even when the disk space used by that file is allocated for use by another file.

• Each user must uniquely identify himself or herself. In Windows NT, this is achieved by typing a unique logon name and password before being allowed access to the system. The system must be able to use this unique identification to track the activities of the user.

• System administrators must be able to audit security-related events and the actions of individual users. Access to this audit data must be limited to authorized administrators.

• The system must protect itself from external interference or tampering, such as modification of the operating system or of system files stored on disk.

In addition to meeting the U.S. government's C2 requirements, there are certain "real world" security problems that a fully secure system must also solve. These real world security issues tend to fall into two categories: managing security and using security. Microsoft® Windows NT® Workstation and Windows NT Server are designed to meet the requirements for a C2-secure system while also providing excellent tools for both managing and using these comprehensive security features.

Windows NT products provide comprehensive tools to help administrators manage and maintain security in their environments. For example, an administrator can specifically control which users have access rights to which network resources. These resources include files, directories, servers, printers, and applications. Rights are defined on a per resource basis and can be managed centrally from any single location.

From the user's perspective, Windows NT security is complete, yet easy to use. A simple password-based logon procedure gives users access to the appropriate network resources. Users are also able to define access rights for any resource they own. For example, if a user needs to share a specific document with other users, he or she can specify exactly who has read and write access to that document. These rights are easily assigned through Windows NT Explorer. Of course, access to organizational resources is fully managed only by authorized administrators.

Another example of Windows NT security capabilities is its protection of data, even while that data is in a machine's physical memory. Windows NT allows only authorized programs to access data. When such a program accesses data, that data is placed in physical memory. Despite the fact that the data is no longer only on the disk, Windows NT still protects it from unauthorized access. No unauthorized program will be able to access that data while it is in memory. Therefore, it is impossible for a rogue application to take advantage of another application's use of data while that data is in the physical memory of a machine.

Evaluation Approach

Windows NT Workstation and Windows NT Server are large, modern operating systems with built-in networking capabilities. When the National Computer Security Center (NCSC) began evaluation of these products in early 1992, it soon became apparent to everyone involved that this evaluation would be considerably more complex than any the NCSC had performed in many years. The NCSC had become proficient at evaluating UNIX® clones, but Windows NT is significantly different from the technologies they had evaluated before.

From the beginning of the evaluation, Microsoft and the NCSC worked together closely to ensure C2 compliance of the Windows NT Workstation and Windows NT Server platforms. One of the first actions of this joint effort was a decision to bring some fruits of the evaluation process to market as quickly as possible, without waiting for all components to be fully evaluated. The result was a phased approach that allowed the core components of Windows NT Workstation and Windows NT Server, on a handful of hardware platforms, to be added to the Evaluated Products List first. Additional hardware platforms, protected subsystems, and networking components will be added to the Evaluated Products List as their evaluations are completed.

The core components of Windows NT Workstation and Windows NT Server attained their first listing as an evaluated product in mid-1995. In 1999, Windows NT was successfully evaluated in a networked environment. This means that the NCSC has found Windows NT Workstation and Windows NT Server to be C2 compliant, and that government customers who are required to purchase C2-compliant systems can consider using Windows NT Workstation and Windows NT Server either as stand-alone components or in an entire C2-certifiable network.

In addition to C2 evaluation by the NCSC, Microsoft® Windows NT® 4.0 Workstation and Microsoft® Windows NT® 4.0 Server are also being evaluated in Europe for the similar E3/F-C2 rating. This will allow customers in both the U.S. and Europe to operate certifiably secure networks.

Initial Evaluation Results

This section describes the hardware and software configuration used in evaluating Windows NT for C2-level security clearance. This configuration constitutes the trusted computing base (TCB). The TCB is the security-relevant, or trusted, part of the operating system. In terms of architecture, it consists of those components that run in the protected kernel mode, as opposed to user mode.

Evaluated Hardware Components

The following hardware configuration was used in evaluating networked Windows NT for C2 compliance.

Platforms Included

The evaluated hardware configuration includes Compaq Professional Workstation 5100, Compaq Professional Workstation 8000, Compaq Proliant 6500 Server, and Compaq Proliant 7000 Server. No other model may be substituted if the setup is to conform to the evaluated C2 configuration. Each evaluated machine can be configured as defined below.

Machine	CPU	Memory	Drive Controller	Network Controller	Graphic Controller
Professional Workstation 5100	One or two Intel Pentium II microprocessors, 266 or 300 MHz	Up to 512 MB of ECC, EDO SIMMs	Integrated Wide-Ultra SCSI-3 on PCI bus	Integrated Compaq Netelligent 10/100 TX PCI UTP Controller	MGA Millenium II
Professional Workstation 8000	One to four Intel Pentium Pro microprocessors, 200 MHz	Up to 3 GB of ECC, EDO SIMMs	Integrated Wide-Ultra SCSI-3 on PCI bus	Integrated Compaq Netelligent 10/100 TX PCI UTP Controller	Diamond Fire GL 4000
Proliant 6500 Server	One to four Intel Pentium Pro microprocessors, 200 MHz	Up to 4 GB of ECC, EDO or Fastpage SIMMs	Two integrated Wide-Ultra SCSI-3; Compaq SMART-2 Array	Dual port 10/100 TX UTP PCI controller	Integrated PCI VGA video
Proliant 7000 Server	One to four Intel Pentium Pro microprocessors, 200 MHz	Up to 4 GB of ECC, EDO or Fastpage SIMMs	Integrated Wide-Ultra SCSI-3; Compaq SMART-2 Array	Dual port 10/100 TX UTP PCI controller	Integrated PCI VGA video

Peripherals Included

In addition to the base system components, each system may include any of the following devices:

• Enhanced Keyboard

• 1.44-MB 3.5-inch diskette drive

• Two-button mouse

• VGA monitor

• Disk drives that meet the Fast SCSI-2, Fast-Ultra SCSI-2, Wide SCSI-3, or Wide-Ultra SCSI specifications

• ATAPI CD-ROM drives

• HP 4mm DAT SCSI tape drive

• HP LaserJet IV and V PCL (i.e., not PostScript) printers

Peripherals Excluded

Peripherals that can invalidate the evaluated configuration are to be avoided. Be particularly careful about using hardware with removable media because some of these devices can reconfigure themselves when special media are inserted. The known examples are all tape drives that overwrite their firmware when a special firmware load tape is inserted. This happens regardless of the other hardware components or OS installed.

In the evaluated configuration, the tape drive is to be used only by the administrator, with procedures established to keep it away from physical access by untrusted users (e.g., by putting it in a locked server room). Other devices, such as CD-ROM drives and floppy disk drives, should be installed only after confirming (e.g., by asking the vendor) that the device does not have this feature. Otherwise you are accepting a risk.

Evaluated Software Configuration

The evaluated configuration of Windows NT includes any number of the Windows NT Server and Windows NT Workstation products, acting in any one of the following roles, either stand-alone or connected via a physically protected network:

Microsoft Windows NT Server product:

• Primary Domain Controller (PDC)

• Backup Domain Controller (BDC)

• Non-domain controller (member server)

• Non-domain controller (non-member server)

Windows NT Workstation product:

• Domain member

• Non-domain member

This configuration can include multiple Windows NT domains (and their PDC and BDCs), as well as networked non-member workstations and servers attached to the same local network.

Components Included

The actual components evaluated were the following:

• Windows NT 4.0 Server or Windows NT 4.0 Workstation product

• Windows NT 4.0 Service Pack 6a

• Microsoft DNS Server (optional on Windows NT Server; not available on Windows NT Workstation)

• Microsoft WINS Service (optional on Windows NT Server; not available on Windows NT Workstation)

• Network Protocol–TCP/IP with static IP address

Components Excluded

There are a few available system components that are not included in the evaluated configuration. Those product elements specifically not included in the Windows NT 4.0–evaluated configuration include:

• POSIX and OS/2 subsystems

• Streams

• Remote Access Service

• Dynamic Host Configuration Protocol (DHCP)

• NetBEUI, AppleTalk, and IPX protocols

• Other services which must run as part of the system such as Internet Information Server.

Administrator Tools Included

The Administrator tools listed in this section are the applications an administrator uses to manage the TCB. All of the tools run in user mode; however, unlike protected servers, these tools execute in the security context of the user. Some tools require the user to possess one or more privileges (which are enforced by the underlying TCB server or Executive subsystem, and not the tool itself). Since privileges are associated with users and their tokens, and not with executable programs, the Administrator tools are only in the TCB because a privileged administrator must use them to manage the TCB.

The set of administrative tools included in the evaluated configuration are: Control Panel, Event Viewer, User Manager and User Manager for Domains, Server Manager, Print Manager, Backup, Registry Editor, Disk Administrator, DNS Manager, WINS Manager, DCOM Configuration Utility, and Windows NT Explorer.

Warning: Only the tools listed in this section have been evaluated for administrator use. Do not use other tools if an installation is to conform to the evaluated C2 configuration because unlisted tools have not been evaluated for correct security administrator behavior.

Control Panel

Users can customize and administer Windows NT with the Control Panel functions. The following list includes those Control Panel functions that are security relevant. Their use requires special privileges:

• Date/Time—Changes the date, time, and time zone of the computer clock.

• Devices—Starts, stops, and configures the startup type for device drivers.

• Display—Installs and configures display drivers.

• Network—Installs, removes, and configures system identification, network services, adapters, protocols, and bindings.

• Printers—Opens Print Manager.

• Server—View and manage the server properties of this computer.

• Services—Manages services defined in the registry (i.e., start or stop the services available in the computer and configure the startup options for each service).

• System—Specifies the startup Operating System, sets system and user environment variables, changes system performance parameters, determines error recovery procedure, and defines paging file size.

• Tape Devices—Installs and configures tape devices.

For user documentation about Control Panel, see the Microsoft® Windows NT® Workstation Version 4.0 Resource Kit (several chapters).

Event Viewer

Event Viewer is used to view and manage event logs, including the security log. It allows for viewing, sorting, filtering, and searching the event logs. The user must have access to the event log file in order to successfully view it. To view the contents of the security log, the user must be logged on as a member of the Administrators group. No special privilege is required to use Event Viewer itself. Security is enforced by the ACL on the log and certain registry settings.

Event Viewer provides two sorting options: newest events first or the oldest events first. To filter events, there is a predefined set of options available. Some of the filter options are: from date, through date, warnings, errors, success or failure audit, source of logging events, user, and event category (e.g., policy changes). Event Viewer also provides for the saving of audit data in a number of formats, including comma-delimited ASCII.

For user documentation about Event Viewer, see "Using Event Viewer" in Chapter 9, "Monitoring Events," of Microsoft® Windows NT® Server Version 4.0 Concepts and Planning.

User Manager and User Manager for Domains

There are two flavors of User Manager: User Manager and User Manager for Domains. User Manager is installed on systems running Windows NT Workstation. It is used to manage users of the local system. User Manager for Domains is used on systems running Windows NT Server. It is used to manage users of the local system and of the domain. Both flavors are used to create and manage user accounts and groups and to implement the security audit policy. User Manager for Domains also is used to create interdomain trust relationships.

The actions a user can perform with the tools are determined by the group memberships of the user's account. If the user does not have sufficient authority to perform an action, that user will be denied access to that function. In particular, a user who is a member of the Administrators group can perform all functions of User Manager and some functions of User Manager for Domains. A user who is a member of the Users group can create local groups, modify and delete those groups, and give any user membership in those groups. Members of the Domain Admins group can perform all functions of User Manager for Domains.

User Manager and User Manager for Domains provide functions for implementing security policy. They include: controlling the way passwords might be used by all user accounts; controlling the privileges assigned to groups and user accounts; and controlling the audit policy by defining the security events that will be logged. These functions are restricted to members of the Administrators and Domain Admins groups.

For user documentation about User Manager for Domains, see Windows NT Server Help and Chapter 2, "Working with User and Group Accounts," in Windows NT Server 4.0 Concepts and Planning. For more about User Manager, see Windows NT Server Help.

Server Manager

The Server Manager is available on Windows NT Server. It provides functions for viewing information about workstations and servers in a domain. The major functions it provides are: manually synchronizing the LSA and SAM databases between the PDC and each BDC, promoting a BDC to a PDC, and viewing the properties of systems in the domain in which the user is a member of the Administrators group. The functions that are domain controller related functions are restricted to members of the Domain Admins group. The individual server and workstation viewing is restricted to members of the Administrators group per system.

For user documentation about Server Manager, see "Assessing and Managing Resource Use" in Chapter 4, "Managing Shared Resources and Resource Security," of Windows NT Server 4.0 Concepts and Planning.

Print Manager

The Print Manager provides functions to manage printing, printers, and print jobs. The major functions it provides are installing printers, changing a printer's properties, and setting event types for auditing. Some functions, such as creating a printer or changing the printer properties, are restricted to members of the Administrators or Print Operators group. A user can also change printer properties if he or she is granted Full Control access to the printer. Printing properties include hours available to print, sharing the printer, configuring printer security, printer priority, the separator page option, and the spooling option.

A printer is secured by a DACL. To change the DACL on a printer object, the user must be the owner of the printer, have been granted Full Control access, or have the TakeOwnership privilege. A user can always control printing of the user's own documents. However, members of the Administrators and Print Operators group can control the printing of other users' documents. Manage Documents or Full Control access to the printer also allows the control of printing other users' documents.

For user documentation about management of printing, see Chapter 5, "Setting Up Print Servers," in Windows NT Server 4.0 Concepts and Planning.

Backup

The Windows NT Backup utility is a tool used to backup information to a local tape drive. It is used to protect data from accidental loss or hardware and media failures. It provides functions to back up disk files to tape, restore tape files to disk, and manage tapes. Members in the Administrators or Backup Operators groups have Backup and Restore privileges allowing them to bypass the protection provided by ACLs.

File permission information is stored on tape with backup files by default. The Backup operator has the option to restore the original file access permissions. If this option is not selected, the files inherit the permission of the directory into which they are restored.

For user documentation about NT Backup, see "Using Windows NT Backup" in Chapter 6, "Backing Up and Restoring Network Files," in Windows NT Server 4.0 Concepts and Planning.

Registry Editors

There are two registry editors, Regedt32.exe and Regedit.exe. These tools can be used to view and edit the configuration database of a Windows NT system. They do not appear in any default program groups, although they are installed automatically when Windows NT is installed. Most often, changes to the configuration database are accomplished through one of the other tools, but certain changes can only be accomplished through the Registry Editor.

The Registry Editor is invoked by executing the file Regedt32.exe or Regedit.exe. Keys modified by the Registry Editor are protected by ACLs; to change a key, a user must have the TakeOwnership privilege or be the owner of the key. To change auditing of keys, non-owners must have the Security Privilege.

For user documentation about registry editors, see "Using Registry Editor" in Appendix A, "Windows NT Registry," in Windows NT Server 4.0 Concepts and Planning.

Disk Administrator

The Disk Administrator provides functions to partition disks, create and delete volume sets, extend volume sets, create and delete stripe sets, establish and break mirror sets, and recover data. Volume sets and stripe sets are mechanisms whereby free space from multiple disk partitions is combined into a new partition. A user must be a member of the Administrators group to start this tool.

For user documentation about Disk Administrator, see "Disk Administrator Overview" in Chapter 7, "Protecting Data," in the Microsoft® Windows NT® Server Version 4.0 Concepts and Planning.

DNS Manager

The DNS Manager provides functions to configure and manage Microsoft DNS servers. The major functions it provides are: viewing and adding records, viewing and adding hosts, creating and maintaining zones, and creating and maintaining subdomains. Most functions, such as creating a zone, are restricted to members of the Administrators group.

For user documentation about DNS Manager, see "Domain Name System Name Resolution" in Chapter 32, "Networking Name Resolution and Registration," in the Windows NT Workstation 4.0 Resource Kit.

WINS Manager

The WINS Manager provides functions to configure and manage Microsoft WINS servers. The major functions it provides are: viewing the WINS server statistics; adding and managing static entries; logging database activity; and scavenging the database. Some functions, such as adding static entries, are restricted to members of the Administrators group.

For user documentation about WINS Manager, see "NetBIOS over TCP/IP (NetBT) Name Resolution" in Chapter 32, "Networking Name Resolution and Registration," in the Windows NT Workstation 4.0 Resource Kit.

DCOM Configuration Utility

The DCOM Configuration Utility is invoked by executing the file Dcomcnfg.exe. It is a utility used to secure administrator-created DCOM objects. It provides functions such as: viewing the DCOM configuration interfaces; managing options, managing default settings; configuring applications; and configuring default security. Functions are restricted to members of the Administrators group.

For user documentation about DCOM Configuration Utility, see "Configuring DCOM" in Chapter 4, "Managing Shared Resources and Resource Security," in the Windows NT Server 4.0 Concepts and Planning.

Windows NT Explorer

Windows NT Explorer provides file and directory manipulation and organization functions. It provides functions such as: creating and removing directories; moving, copying, and deleting files; securing files and directories; and performing other disk, directory, and file management tasks. Some functions are restricted to certain groups. Manipulation of directory and file objects is controlled by their ACLs, which are set by using Windows NT Explorer.

Windows NT Explorer provides functions to audit operations on files and directories. To enable auditing of files or directories, membership in the Administrators group or possession of the security privilege is necessary. Using Windows NT Explorer, an administrator can enable different types of auditable events on the files and directories when these events are generated by specified users and groups. To change permission on a file not owned by the user, the TakeOwnership privilege is required.

For user documentation about Windows NT Explorer, see "Windows NT Explorer" in online help.

Installing and Configuring a C2-Compliant System

The following checklist and procedures describe the configuration of the hardware platforms referred to in the preceding sections. The checklist and procedures are written to enable you to duplicate the configuration used in the C2-level networking security evaluation.

All settings are for workstations, domain controllers, and non-domain controller servers unless otherwise specified.

Note: The configuration must be exactly as described here to qualify as an evaluated C2 configuration.

Cautionary Notes

In installing the configuration, there are some general cautions to be observed or else C2 compliance might be compromised.

DCOM Warning

The COM Service Control Manager (SCM) supports the ability to activate (launch) COM servers in processes using different security contexts. The identity of the COM server is determined by the RunAs attribute of the AppID as configured using the Dcomcnfg.exe tool. If there is no RunAs value, the COM SCM will activate the server process "as activator." That is, the server process will have the same security context (token) as the activating client. This is the preferred method in the evaluated configuration.

If present, the RunAs value tells the COM SCM the name of the account under which the server is to be activated. In addition to the account name, the COM SCM must also have the password of the account. The result of a successful logon is a security context (token) for the named account that is used as the primary token for the new COM server process. Administrators should not use this method in the evaluated configuration if accountability is required, since accountability cannot be enforced.

Instead of a specific user, the RunAs value can have the special string "Interactive User." In this case, the COM SCM starts the new server using the security context of the current interactively logged on user (and if there is not a current interactive user, the activation request will fail). No logon occurs; the interactive user's token is used for the new COM server. Running COM servers as "Interactive Users" can have detrimental security impacts, especially for distributed COM since potentially any user can start a remote process for any user who happens to be logged onto a workstation. For the C2-evaluated configuration, the administrator must not configure any AppID to run as the interactive user.

User/GDI Warning

Administrators should not open the desktops of untrusted users. This is because of the possible presence of "window hooks," which are processes in a program that allow it to execute in the context of another user's process. Such hooks can be installed by any user process that has appropriate access to a desktop. The hook can then be triggered by opening and setting the desktop. This is a concern only for those, like administrators, who have permission to open other users' desktops.

Removable Media Warning

All users should be careful with removable media. In addition, administrators should take precautions with tape drives.

All Users

When a user finishes an interactive logon session, all removable media (e.g., diskettes) should be removed from the drive and physically protected, unless the machine is in a physically secure location (e.g., locked room or office). Users should be aware that files on diskettes are not protected resources and that deleting files or erasing data from a diskette does not necessarily remove the data from the physical media. Users should always physically protect all removable media.

Administrators

Administrators use tape drives, which are not protected like floppy disk drives and CD-ROM drives inasmuch as they are not limited to the current interactive user. As such, tape drives should only be installed on systems that will not support interactive, untrusted users so that the online tape media can be appropriately controlled by limiting access to the system itself. Furthermore, some tape drives implement a feature whereby a special tape, when inserted, would cause the tape firmware to be updated automatically. Hence it is important to control tape media and to ensure that new tapes do not represent a threat to the system (that is, they are not from a potentially malicious source).

Control of Network Connections

The C2-evaluated configuration assumes that all connections to the network are controlled. The control should be high-level; that is:

• If the network is entirely contained in a secure building, the risk of unauthorized taps is minimized or eliminated.

• If the cabling must pass through unsecured areas, optical fiber links are used, rather than twisted-pair cable, to foil attempts to tap the wire and collect transmitted data.

Warning: Control of connections requires the ability to confirm that messages arrived intact. UDP should not be used as the protocol because it offer no ability to guarantee the sender and receiver to each other. Some communication may not require such protection, but if protection is required, another mechanism, such as TCP/IP, should be used. Only TCP/IP is supported in the evaluated configuration.

Applications that Replace Operating System Files

Do not install any application until you first determine whether its installation program modifies or replaces dynamic link libraries (DLLs) and other files that are part of the C2-evaluated trusted computing base (TCB). There are several ways to determine whether the process of installing an application changes base operating system files:

• Install the evaluated configuration on one computer by following the instructions described in this section. Set this computer aside to use as a baseline. After you install a new application on another computer, compare its system files against the system files on the baseline computer.

• Obtain descriptions (file names, versions, file sizes) of system files from the Windows NT 4.0 distribution media and subsequent service pack media. Manually compare that information against the modified system, or develop a tool to do the job automatically.

• Enable auditing for successful object writes in the entire system directory and all subdirectories. After installing a new application, use Event Viewer to examine the security log for object access events. For each object access event, read the event detail. If the path portion of the object name indicates that the object is a system file and the type of access audited is WriteData, then a system file has been overwritten.

Protection Against Malicious Code

In today's computing world, you must prevent intentional intrusions of malicious code into your network. These typically take the form of viruses and Trojan horses:

• Viruses are programs that attempt to spread from computer to computer and either cause damage (by erasing or corrupting data) or annoy users (by printing messages or altering what is displayed on the screen).

• Trojan horses are programs that masquerade as other common programs in an attempt to receive information. An example of a Trojan horse is a program that masquerades as a system logon screen to retrieve user names and password information. The writers of the Trojan horse can use this information later to break into the system.

By taking some precautions as a matter of course, you can go a long way toward preventing intrusions by viruses and Trojan horses.

Viruses

• Following are precautions you can take to prevent virus outbreaks:

• Educate your network users. Few realize that they can unwittingly bring viruses into the network by loading a program from a source such as an online bulletin board.

• Have at least one commercial virus-detection program and use it to regularly to check your file servers for viruses. If possible, you should also make virus-detection software available to your users.

• Set file permissions to make all applications available on network servers and Windows NT workstations read and execute only, thereby preventing them from being replaced by viruses.

• Before putting a new application or file on the network, put it on a computer not attached to the network, and check it with your virus-detection software. You might also want to log on to this computer using an account with only guest access to the computer so that the program being tested will have only guest permissions and be unable to modify any important files.

• Regularly back up the files on your file servers (and workstations, if possible) so that damage is minimized if a virus attack does occur. For information about backups, see Chapter 6, "Backing Up and Restoring Network Files" in Windows NT Server 4.0 Concepts and Planning.

Trojan Horses

Windows NT Server provides an important safeguard against Trojan horse programs. Before a user can log on at a Windows NT Server or Windows NT Workstation computer, the user must type the secure attention sequence, CTRL+ALT+DEL. This series of keystrokes always displays the Windows NT operating system logon screen; it can never activate Trojan horse programs. Users are guaranteed to be providing their user name and password only to the operating system itself. To ensure effective security, you should educate your users to always type CTRL+ALT+DEL before logging on at a computer, even if the logon window already appears on the screen.

The secure attention sequence is also required before users can unlock locked workstations or change their passwords.

Another way to guard against Trojan horses is identical to a method for protecting against viruses. Make your applications read-and-execute-only so they cannot be replaced with programs that masquerade as the original program and steal information.

Procedure Checklist

Feel free to photocopy the following C2 Configuration Checklist (Table 4.1) and use it to keep track of the steps as you complete them. It is an abbreviation of the steps detailed in the next section of this document.

Table 4.1 C2 Configuration Checklist

	Action
	Unpack and set up hardware
	Set power-on password
	Install Windows NT
	Restart Windows NT as Administrator
	Verify video driver
	Install Printer and Tape Drivers
	Install Service Pack 6a
	Install C2 Update (KB 244599, 243405, 243404, and 241041)
	Enable hardware boot protection
	Remove the NetBIOS Interface service
	Disable unnecessary devices
	Disable unnecessary services
	Disable Guest account
	Remove OS/2 and POSIX subsystems
	Secure base objects
	Secure additional base named objects
	Protect kernel object attributes
	Protect files and directories
	Protect the registry
	Restrict access to public Local Security Authority (LSA) information
	Restrict null session access over named pipes
	Restrict untrusted users' ability to plant Trojan horse programs
	Disable caching of logon information
	Allow only Administrators to create shares
	Disable direct draw
	Restrict printer driver installation to Administrators and Power Users only
	Set the paging file to be cleared at system shutdown
	Restrict floppy disk drive and CD-ROM drive access to the interactive user only
	Enable NetBT to open TCP and UDP ports exclusively
	Modify user rights memberships
	Set auditing (if enabled) for base objects and for backup and restore
	Disable blank passwords
	Restrict system shutdown to logged-on users only
	Set security log behavior
	Restart the computer
	Update the Emergency Repair Disk

Detailed Procedures

The following list is a restatement of the steps in Table 4.1, with explanatory notes.

Unpack and set up hardware

The Compaq ProLiant platform, models 5100, 6500, 7000, and 8000, was used in evaluating Windows NT for C2 compliance. Follow the hardware manufacturer's manuals accompanying your computer system to unpack and connect your computer system components. Physically secure the hardware to the extent necessary, including using optical fiber if cabling must pass through unsecured areas, or isolating the network in a secure building if very high security is needed.

To test processor integrity

You can obtain a suite of diagnostic integrity tests for i386 processors by contacting Microsoft Product Support Services, and referring to Microsoft Knowledge Base article 240049, "How to Obtain Diagnostic i386 Processor Integrity Tests Required by the C2 TFM for Windows NT 4.0." Telephone numbers and information on support costs are available at https://support.microsoft.com/default.aspx?pr=cntactms&style=home.

To test peripheral integrity

Use the peripheral integrity tests that are shipped with the Compaq ProLiant 5100, 6500, 7000, and 8000, as documented by Compaq, to test the integrity of the peripheral in the evaluated configuration.

Set power-on password

Set the power-on password for your computer as follows:

To set up a power-on password on a computer manufactured by Compaq ® Computer Corporation

1. Insert the SmartStart® CD in the CD-ROM drive and turn on the computer's power.

   The computer starts the MS-DOS operating system from the CD and runs the SmartStart utility.

2. Select Non-SmartStart Setup from the SmartStart menu.

3. Select System Configuration from the Manual Configuration And Server Utilities menu.

4. From the System Configuration menu, select Configure Hardware.

   The utility will attempt to configure the hardware automatically and then displays the Configuration Complete dialog box.

5. Select Review Or Modify Hardware Settings, and then press enter.

6. From the Steps In Configuring Your Computer menu, select Step 3: View Or Edit Details, and then press ENTER.

7. From the View Or Edit Details dialog box, select Set Power-On Password: Disabled.

8. Type the password, and then press ENTER. Type the password again, and then press ENTER.

9. Press F10.

10. From the Steps In Configuring Your Computer menu, select Step 5: Save And Exit, and then press ENTER.

11. Press ENTER.

12. From the Save and Edit menu, select Save the Configuration and Restart, and then press ENTER.

Note: An intruder who can physically open your computer's central processing unit (CPU) can adjust hardware switches to disable the power-on password. Access to the internal components of the CPU would also permit temporary installation of a drive from which a less secure OS, or a version of Windows NT that lacks your security settings, can be used to start the computer. Options for preventing unauthorized access to internal components include locking the case (if the model permits it) or locking away the entire CPU in a well-ventilated area, possibly with an opening to allow use of the floppy drive or drives.

Install Windows NT

For additional information on installing Windows NT, see the instructions in Part 2, "Installation," in Windows NT Server Start Here or Windows NT Workstation Start Here. Keep in mind the following considerations:

• If you install systems by disk duplication (e.g., by using the xcopy command), do not use "after-GUI replication," where the copy is made after the graphical user interface (GUI) appears. Microsoft supports disk duplication for Windows NT 4.0 only if the disk is duplicated at the point in the setup process after the second reboot and before the GUI portion of Windows NT 4.0 setup.

  Warning: Duplicating the system in the wrong part of the setup process will copy the entire tree structure of Windows NT, affecting security, hardware, and other areas of the product. Security is impossible because the two installations have the same primary SID, and thus users on one system can access accounts on the other. (Windows NT 3.51 CPS and Windows NT 4.0 Deployment Tools, although unattended, are not simple copies and do configure the OS correctly.)

• Choose the Custom Setup option.

  As you proceed through the steps of Setup, use the default settings except for the following:

  • All hard-disk partitions must be formatted with NTFS.

  • Do not install any other operating systems on the computer.

  • When the Administrator Account Setup dialog box appears, do not supply a blank password for the Administrator account. That is, do not simply leave the password field blank. Provide a password that is at least six characters long and cannot be easily guessed.

  • When the Local Account Setup dialog box appears, you can create a user account for routine computer use. If you choose to create a local account, keep in mind that this account is placed by default in the Administrators group, which gives the user the ability to create user accounts.

  • Create an emergency repair disk. This makes it easier to recover your system if the operating-system configuration databases become corrupt.

    During the network portion of the installation process, make the following selections:

    • For installations of Windows NT Server, do not install Internet Information Server (IIS).

    • When the Network Protocol dialog appears, select only TCP/IP.

    • Do not use DHCP. Instead, use a static IP address appropriate for your network.

    • Workstations and member servers may or may not be part of a domain; either option is appropriate.

Restart Windows NT as Administrator

Log on to the Administrator account. This account has sufficient capability for you to perform the remainder of the configuration steps.

Verify video driver

The only video driver in the evaluated configuration is vga.sys. To verify that the correct video driver is loaded, right click on the desktop. From the context menu, choose Properties, select the Settings tab, then click the Display Type button. If the current files list includes any driver other than vga.sys, click the Change button and choose the VGA compatible display adapter. This change will require a reboot.

Install Printer and Tape Drivers

If any printers or tape devices are to be installed, install those devices and their drivers before installing Service Pack 6a. If a tape or printer device is added at a later time, re-install Service Pack 6a after the drivers have been installed.

Install Service Pack 6a

Install the Microsoft Windows NT 4.0 Workstation and Server U.S. Service Pack 6a. Service Pack 6a incorporates all improvements that were made in Service Packs 1 through 5.

Install C2 Update

Install the post-Service Pack 6a hotfix "C2 Update" to ensure that

1. NetBT disallows unprivileged user mode applications from sharing TCP and UDP ports that are opened by NetBT. This feature is described in Microsoft Knowledge Base article 241041, "Enabling NetBT to Open TCP and UDP Ports Exclusively."

2. Device drivers create their corresponding DeviceObject with FILE_DEVICE_SECURE_OPEN DeviceCharacteristics. This feature is described in Microsoft Knowledge Base article 243405, "Device Drivers Create Their Corresponding DeviceObject with FILE_DEVICE_SECURE_OPEN DeviceCharacteristics."

3. Jet500 creates events and semaphores objects with non-NULL ACLs. This feature is described in Microsoft Knowledge Base article 243404, "ACLs associated with events and semaphores created by Jet500.dll."

4. The C2 Update also includes the binary files required in the spooler-fix described in Microsoft Knowledge Base article 243649, "Unchecked Print Spooler Buffer May Expose System Vulnerability."

The C2 update is posted to the Microsoft.com download center:

https://www.microsoft.com/downloads/Search.aspx?displaylang=en.

This is a fully supported update. Information on contacting Microsoft Technical Support is available at https://support.microsoft.com/support/contact/default.asp.

Customers unable or unwilling to download this update can order the update on various media through Microsoft Technical Support.

Enable hardware boot protection

Configure each Windows NT Workstation to boot only with a BIOS setup password and only from the fixed disk. For Windows NT Server, this configuration is not available; instead you should physically protect each Server machine as described under "Restricting the Boot Process" in Chapter 2 of this guide.

Remove the NetBIOS Interface service

Use the Remove button on the Services page of the Network menu, accessed via Control Panel, to remove NetBIOS Interface as a network service. This service was not included in the evaluation.

Disable unnecessary devices

All devices are to be disabled except those shown in Table 4.2 (and the NetBIOS Interface, because the associated service was disabled in the previous step). The devices in Table 4.2 have been evaluated, and it is acceptable to enable all of them (or a subset of them) to remain in the evaluated configuration. Do not install any devices not explicitly listed in the table.

The NetBIOS device cannot be disabled because the associated service was disabled in the previous step.

Note: Disable devices before services. Some devices depend on services and therefore cannot be disabled if the service is not present.

Table 4.2 Enabled Devices for Evaluated Configuration

Device in C2 Configuration	Device Driver
AFD Networking Support Environment	afd.sys
atapi	atapi.sys
Beep	beep.sys
Cdfs	cdfs.sys
Cdrom	cdrom.sys
Compaq NetFlex-3 Driver	netflx3.sys
cpqarray	cpqarray.sys
Disk	disk.sys
Fastfat	fastfat.sys
Floppy	floppy.sys
HP 4mm DAT tape device	hpt4qic.sys
i8042 Keyboard and PS/2 Mouse Port	i8042prt.sys
keyboard class driver	kbdclass.sys
KSecDD	ksecdd.sys
Microsoft NDIS System Driver	ndis.sys
Mouse Class Driver	mouclass.sys
Msfs	msfs.sys
Mup	mup.sys
NetDetect	netdetect.sys
Npfs	npfs.sys
Ntfs	ntfs.sys
Null	null.sys
Parallel	parallel.sys
Parport	parport.sys
Rdr	rdr.sys
Serial	serial.sys
Srv	srv.sys
symc810	symc810.sys
TCP/IP Service	tcpip.sys
Vga	vga.sys
VgaSave	vga.sys
VgaStart	vga.sys
WINS Client (TCP/IP)	netbt.sys
Tape	tape.sys
4mm tape drive	4mmdat.sys

Disable unnecessary services

All services except those listed in Table 4.3 are to be disabled. Note that Microsoft DNS Server and WINS are only enabled on servers on which they are installed. Note also that when Plug and Play is disabled, the Devices menu is not accessible from Control Panel.

To remain in the evaluated configuration, it is acceptable to have all of the listed services (or a subset of them) enabled and running. Do not install any trusted services (or applications) not explicitly listed in the table.

Warning: Enabling or installing new services not identified as enabled in Table 4.3 is outside the scope of the C2-evaluated configuration. The C2-evaluated configuration includes no auditing capability for administrators installing, enabling, or disabling services. Hence, management of services can only be accomplished outside the C2-evaluated configuration, though the C2-evaluated configuration can be reestablished subsequently.

Table 4.3 Enabled Services for Evaluated Configuration

Service
Computer Browser
Event Log
Microsoft DNS Server (only on servers that have it installed)
Net logon
NTLM SSP
RPC Locator
RPC Service
Server
Spooler
TCP/IP NetBIOS Helper
WINS (only on servers that have it installed)
Workstation

Disable Guest account

By default the Guest account is disabled at startup. If the Guest account is enabled, disable it. Disabling accounts is described under "Disabling and Enabling User Accounts" in User Manager for Domains Help and User Manager Help.

Remove the OS/2® and POSIX subsystems

These subsystems were not included in the evaluated configuration, and therefore full C2 compliance cannot be achieved unless they are removed.

To remove the OS/2 and POSIX subsystems

1. Delete the \winnt\system32\os2 directory and all of its subdirectories.

2. Use the Registry Editor to remove the following registry entries:

   Key:	HKEY_LOCAL_MACHINE \SOFTWARE
   Subkey:	Microsoft\OS/2 Subsystem for NT
   Entry:	delete all subkeys
   Key:	HKEY_LOCAL_MACHINE \SYSTEM
   Subkey:	CurrentControlSet\Control\Session Manager\Environment
   Entry:	Os2LibPath
   Value:	delete entry
   Key:	HKEY_LOCAL_MACHINE \SYSTEM
   Subkey:	CurrentControlSet\Control\Session Manager\SubSystems
   Entry:	Optional
   Values:	delete entry
   Key:	HKEY_LOCAL_MACHINE \SYSTEM
   Subkey:	CurrentControlSet\Control\Session Manager\SubSystems
   Entry:	delete entries for OS2 and POSIX

   The changes take effect the next time the computer is started. You might want to update the emergency repair disk to reflect these changes.

Caution: The registry editor bypasses the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. There could be serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows NT 4.0. If you are not familiar with the registry or the Windows NT 4.0 registry editors, please see Part V, "Windows NT Registry," in the Windows NT 4.0 Workstation Resource Kit.

Secure base objects

This step is necessary to further heighten security of the base objects. Among other things, it prevents users from gaining local administrator privileges by way of a dynamic-link library (DLL). Without this safeguard, a non-administrator user could load into memory a file with the same name as a system DLL and redirect programs to it. When called by a program that has the privileges of the Local Administrator group, the fake DLL might be able secretly to add the user to that group.

To secure base objects

• Use the Registry Editor to create the following registry entry and assign a value to it:

  Key:	HKEY_LOCAL_MACHINE \SYSTEM
  Subkey:	CurrentControlSet\Control\Session Manager
  Entry:	ProtectionMode
  Type:	REG_DWORD
  Value:	1

Secure additional base named objects

This step is necessary to heighten security of additional base named objects such as RotHintTable or ScmCreatedEvent, not addressed by the ProtectionMode key entry above.

To secure additional base named objects

• Use the Registry Editor to create and set the value of the following registry entry:

  Key:	HKEY_LOCAL_MACHINE \SYSTEM
  Subkey:	CurrentControlSet\Control\Session Manager
  Entry:	AdditionalBaseNamedObjectsProtectionMode
  Type:	REG_DWORD
  Value:	1

Protect kernel object attributes

This step is necessary to ensure that the object manager may change attributes of a kernel object in the object table for the current process if and only if the previous mode of the caller is kernel mode.

To protect kernel object attributes

• Use the Registry Editor to create and set the value of the following registry entry:

  Key:	HKEY_LOCAL_MACHINE \SYSTEM
  Subkey:	CurrentControlSet\Control\Session Manager
  Entry:	EnhancedSecurityLevel
  Type:	REG_DWORD
  Value:	1

Protect files and directories

Use the ACL Editor in Windows NT Explorer to change access on the system drive (by default "C:\") to grant Full Control permission to Administrators and SYSTEM, and to grant Read permission to Everyone, with the following exceptions:

Directory	Users	Maximum access
c:\temp	Creator Owner	Full Control
c:\temp	Everyone	Add
c:\winnt\profiles\<specific user> directory and subdirectories	<specific user>	Full Control
c:\winnt\profiles\administrator directory and subdirectory	Everyone	None; delete from the ACL
c:\winnt\repair directory and existing files	Everyone	None; delete from the ACL

Several critical operating system files exist in the root directory (System32) of the system partition on Intel 80486 and Pentium-based systems. These files must be protected with the following permissions:

File	C2-Level Permissions
BOOT.INI, NTDETECT.COM, NTLDR	Administrators: Full Control SYSTEM: Full Control
AUTOEXEC.BAT, CONFIG.SYS	Everybody: Read Administrators: Full Control SYSTEM: Full Control

All TCB used program and library files are stored on the system drive (by default "C:"). Nearly all TCB files are stored in the system directory (by default "\WINNT") and its subdirectories. In addition, the three files (boot.ini, ntdetect.com, ntldr) in the root directory of the system drive (by default "C:\") are also TCB files. Modification of these three files or any files in the system directory should be considered a modification to the TCB.

Warning: The C2-evaluated configuration requires that the directories and files identified above be continuously controlled at least to the degree specified. Other files or directories can effectively have any access control.

Protect the registry

The default permissions grant Full Control to Administrators and SYSTEM and Read access to Everyone for the following registry subkeys and all their subkeys:

• HKEY_LOCAL_MACHINE \Hardware

• HKEY_LOCAL_MACHINE \Software

• HKEY_LOCAL_MACHINE \System

• HKEY_USERS.Default

The default permissions do not restrict who has remote access to the registry. Only administrators should have remote access to the registry.

To restrict remote access to the registry

1. Use the Registry Editor (regedt32.exe) to find the following registry subkey:

   Key:	HKEY_LOCAL_MACHINE \SYSTEM
   Subkey:	CurrentControlSet\Control\SecurePipeServers\winreg

2. Select winreg, click the Security menu, and then click Permissions.

3. Set the Administrators permission to Full Control, make sure no other users or groups are listed, then click OK.

Restrict access to public Local Security Authority (LSA) information

In the C2 configuration, you need to be able to identify all users. Therefore you should restrict anonymous users from being able to obtain public information about the LSA component of the Windows NT Security Subsystem. The LSA handles aspects of security administration on the local computer, including access and permissions.

To restrict access to public LSA information

• Use the Registry Editor to create and set the value of the following registry entry:

  Key:	HKEY_LOCAL_MACHINE \SYSTEM
  Subkey:	CurrentControlSet\Control\Lsa
  Entry:	RestrictAnonymous
  Type:	REG_DWORD
  Value:	1

Restrict null session access over named pipes

Restricting such access helps prevents unauthorized access over the network.

To restrict null session access over named pipes

• Use the Registry Editor to create and set the value of the following registry entries:

  Key:	HKEY_LOCAL_MACHINE \SYSTEM
  Subkey:	CurrentControlSet\Services\LanmanServer\Parameters
  Entry:	NullSessionPipes, NullSessionShares
  Type:	REG_MULTI_SZ
  Value:	delete all values

Restrict untrusted users' ability to plant Trojan horse programs

Trojan horses take advantage of the Run utility if it is unguarded. There are some Trojan horses that are written to execute during an Uninstall operation.

To restrict the ability to plant Trojan horse programs

1. Use the Registry Editor to find the following registry subkeys:

   Key:	HKEY_LOCAL_MACHINE \SOFTWARE
   Subkey:	Microsoft\Windows\CurrentVersion
   Entry:	Run, RunOnce, Uninstall (if present), and all their subkeys

2. Select each subkey, click the Security menu, and then click Permissions.

3. For each subkey set the permissions for Everyone and all untrusted users to a maximum of Read, and then click OK.

Disable caching of logon information

Windows NT 4.0 has the capability to cache logon information in short-term memory. If the domain controller cannot be found during logon and the user has logged on to the system in the past, it can use those credentials to log on. If the Administrator disables a user's domain account, the user could still use the cache to log on by disconnecting the net cable. To prevent this, Administrators should disable the cache. This results in a somewhat longer logon time, but prevents hackers from tapping logon information from short-term memory.

To disable caching of logon information

• Use the Registry Editor to create and set the value of the following registry entry:

  Key:	HKEY_LOCAL_MACHINE \SOFTWARE
  Subkey:	Microsoft\Windows NT\CurrentVersion\Winlogon
  Entry:	CachedLogonsCount
  Type:	REG_SZ
  Value:	0

Allow only Administrators to create shares

This allows the administrator to control who can access a computer from its network interface and what information is shared over the network interface.

To restrict share creation to Administrators

1. Use the Registry Editor to find the following registry subkey:

   Key:	HKEY_LOCAL_MACHINE \SYSTEM
   Subkey:	CurrentControlSet\Services\LanmanServer\Shares

2. Select Shares and all its subkeys, click the Security menu, and then click Permissions.

3. For Shares and each subkey, set the permissions for Everyone and all untrusted users to a maximum of Read, and then click OK.

Disable direct draw

This prevents direct access to video hardware and memory.

To disable direct draw

• Use the Registry Editor to set the value of the following registry entry:

  Key:	HKEY_LOCAL_MACHINE \SYSTEM
  Subkey:	CurrentControlSet\Control\GraphicsDrivers\DCI
  Entry:	Timeout
  Type:	REG_DWORD
  Value:	0

Restrict printer driver installation to Administrators and Power Users only

Who can add printer drivers is controlled by the value of a registry entry. The value should be set to 1 to allow only administrators to install printer drivers on servers and domain controllers, and Administrators and Power Users to install them on workstations.

To restrict printer driver installation

• Use the Registry Editor to create the following registry entry:\

  Key:	HKEY_LOCAL_MACHINE \SYSTEM
  Subkey:	CurrentControlSet\Control\Print\Providers\LanMan Print Services\Servers
  Entry:	AddPrintDrivers
  Type:	REG_DWORD
  Value:	1

The subkey will not exist if no printers are installed on the system. In that case, you will need to create the subkey before creating an entry for AddPrintDrivers.

Set the paging file to be cleared at system shutdown

Clearing the paging file ensures that no unsecured data is contained in the paging file when the shutdown process is complete.

To clear the paging file on shutdown

• Use the Registry Editor to set the value of the following registry entry:

  Key:	HKEY_LOCAL_MACHINE \SYSTEM
  Subkey:	CurrentControlSet\Control\Session Manager\Memory Management
  Entry:	ClearPageFileAtShutdown
  Type:	REG_DWORD
  Value:	1

Restrict floppy disk drive and CD-ROM drive access to the interactive user only

Only the currently logged-on user should be able to access floppy disk drives and CD-ROM drives. To ensure this, allocate the drives at logon.

To restrict floppy and CD-ROM drive access to the logged-on user

• Use the Registry Editor to create and set the values for the following registry entries:

  Key:	HKEY_LOCAL_MACHINE \SOFTWARE
  Subkey:	Microsoft\Windows NT\CurrentVersion\Winlogon
  Entry:	AllocateFloppies, AllocateCdRoms
  Type:	REG_SZ
  Value:	1

  If the entry does not exist, or is set to any other value, floppy devices will be available for shared use by all processes on the system.

  These values take effect at the next logon. If a user is already logged on when the values are set, they will have no effect for that logon session. The user must log off and log on again to cause the device or devices to be allocated.

Note: Windows NT allows all users access to the floppy disk drive, and therefore any user can read and write the contents of any floppy disk in the drive. In general this is not a concern, because only one user is logged on at a time. However, in rare instances, a program started by a user can continue running after the user logs off. When another user logs on and puts a floppy disk in the drive, this program can secretly transfer sensitive data from the floppy disk. If this is a concern, restart the computer before using the floppy disk drive.

Enable NetBT to open TCP and UDP ports exclusively

It is a TCSEC C2 requirement that an unprivileged user mode application should not be able to listen to TCP and UDP ports used by Windows NT services, regardless of the cryptographic protection applied to the Windows NT service traffic through the ports.

To enable NetBT to open TCP and UDP ports exclusively

• Use the Registry Editor to set the values for the following registry entries:

  Key:	HKEY_LOCAL_MACHINE \SYSTEM
  Subkey:	CurrentControlSet\Services\NetBT\Parameters
  Entry:	EnablePortLocking [This name does not appear by default and must be created.]
  Type:	REG_DWORD
  Value:	1

Note: To ensure that the registry key value is effective, the post-Service Pack 6a hotfix "C2 Update" must be installed.

Modify user rights memberships

Use User Manager for Domains to restrict the use of user rights as shown in Table 4.4.

Table 4.4 Allowable User Rights Assignment for Evaluated Configuration

User Right	Domain Controllers	Member Servers	Workstations
Access this computer from network	(anyone)	(anyone)	(anyone)
Act as part of the operating system	(no one) Do not assign to any user.	(no one) Do not assign to any user.	(no one) Do not assign to any user.
Add workstations to domain	(no one)	(no one)	(no one)
Back up files and directories	trusted users	trusted users	trusted users
Bypass traverse checking	(anyone)	(anyone)	(anyone)
Change the system time	trusted users	trusted users	trusted users
Create a pagefile	trusted users	trusted users	trusted users
Create a token object	(no one) Do not assign to any user.	(no one) Do not assign to any user.	(no one) Do not assign to any user.
Create permanent shared objects	(no one)	(no one)	(no one)
Debug programs	(no one) This right is not auditable and should not be assigned to any user, including system administrators.	(no one) This right is not auditable and should not be assigned to any user, including system administrators.	(no one) This right is not auditable and should not be assigned to any user, including system administrators.
Force shutdown from a remote system	trusted users	trusted users	trusted users
Generate security audits	(no one) Do not assign to any user.	(no one) Do not assign to any user.	(no one) Do not assign to any user.
Increase quotas	trusted users	trusted users	trusted users
Increase scheduling priority	trusted users	trusted users	trusted users
Load and unload device drivers	trusted users	trusted users	trusted users
Lock pages in memory	(no one)	(no one)	(no one)
Log on as a batch job	trusted users (as needed)	trusted users (as needed)	trusted users (as needed)
Log on as a service	trusted users (as needed)	trusted users (as needed)	trusted users (as needed)
Log on locally	trusted users	(anyone)	(anyone)
Manage auditing and security log	trusted users	trusted users	trusted users
Modify firmware environment values	trusted users	trusted users	trusted users
Profile single process	trusted users	trusted users	trusted users
Profile system performance	trusted users	trusted users	trusted users
Replace a process level token	(no one) Do not assign to any user.	(no one) Do not assign to any user.	(no one) Do not assign to any user.
Restore files and directories	trusted users	trusted users	trusted users
Shut down the system	trusted users	(anyone)	(anyone)
Take ownership of files or other objects	trusted users	trusted users	trusted users

Set auditing for base objects and for backup and restore

Certain programming objects (i.e., base named objects) are not audited by default when auditing of object and file access is enabled. Likewise, the Backup and Restore user rights are not audited by default when use of user rights auditing is enabled. Administrators need to adjust the size of the event log file accordingly to anticipate the increase in auditable events. To enable auditing of base named object and the Backup/Restore user rights, make the following changes.

To set auditing for base objects

• Use the Registry Editor to set the value of the following registry entry:

  Key:	HKEY_LOCAL_MACHINE \SYSTEM
  Subkey:	CurrentControlSet\Control\Lsa
  Entry:	AuditBaseObjects
  Type:	REG_DWORD
  Value:	1

To set auditing for backup and restore privilege

• Use the Registry Editor to set the value of the following registry entry:

  Key:	HKEY_LOCAL_MACHINE \SYSTEM
  Subkey:	CurrentControlSet\Control\Lsa
  Entry:	FullPrivilegeAuditing
  Type:	REG_BINARY
  Value:	01 (hex)

Disable blank passwords

Blank passwords are unacceptable in a C2 configuration. You can prohibit blank passwords using User Manager or User Manager for Domains. Under the "Policies...Account..." menu, ensure that "Permit Blank Password" is not checked.

Restrict system shutdown to logged-on users only

If installing Windows NT Workstation, ensure that the computer cannot be shut down unless a user is logged on. This step is not necessary if you are installing the Windows NT Server product because the default behavior on a dedicated server already limits system shutdown to only logged on users.

To restrict system shutdown to logged-on users only

• Use the Registry Editor to create the following entry or assign a value to it:

  Key:	HKEY_LOCAL_MACHINE \SOFTWARE
  Subkey:	Microsoft\Windows NT\Current Version\Winlogon
  Entry:	ShutdownWithoutLogon
  Type:	REG_SZ
  Value:	0

Set security log behavior

Use Event Viewer to set security log behavior. Choose Do Not Overwrite Events (Clear Log Manually). Optionally, you can also force Windows NT to halt when it cannot generate an audit event record. Also optionally, you can set the registry key to enable auditing of the use of all rights.

To shut down the system when the security log is full

• Use the Registry Editor to set the value of the following registry entry:

  Key:	HKEY_LOCAL_MACHINE \SYSTEM
  Subkey:	CurrentControlSet\Control\LSA
  Entry:	CrashOnAuditFail
  Type:	REG_DWORD
  Value:	1

Restart the computer

Restarting the computer saves and executes all the changes you made in the preceding steps.

Update the Emergency Repair Disk

You should update the system's Emergency Repair Disk (ERD) to reflect these changes. For instructions, see "Update Repair Info" in Repair Disk Utility Help. (Run rdisk.exe, then click Help.)

Remember to use the emergency repair disk, rather than the Restore utility, if system files are lost. Backup and Restore do not copy system access control lists (SACLs). The emergency repair disk does restore this information.

Appendix A - Software Security Rating Systems

Windows NT is sold throughout the world, and thus it has been and is being tested in several countries for C2 compliance. The standards and procedures, described in the following sections, have differed slightly from one country to another, with a resulting duplication of effort. The recent movement to create and adopt the Common Criteria holds promise for broader equivalency in the future. For more information, see "Common Criteria: A New International Standard," later in this appendix.

C2 Evaluation in the United States

Evaluators for U.S. government software product security evaluations come from the Trust Technology Assessment Program (TTAP), a joint program of the National Security Agency (NSA) and National Institute of Standards and Technology (NIST), as well as from a small group of federal contract research organizations. Some evaluations have also benefited from the participation of evaluators from the security evaluation organizations of other cooperating governments.

Evaluation Criteria

The National Computer Security Center (NCSC) carries out its evaluation primarily against three published sets of requirements: the TCSEC, the Interpreted TCSEC, and the TNI.

TCSEC (Orange Book)

The TCSEC or Orange Book is a set of criteria used to grade or rate the security offered by a computer system product. The current version is dated 1985 (DOD 5200.28-STD, Library No. S225,711). The TCSEC and its interpretations and guidelines all have different color covers, and are sometimes known as the Rainbow Series.

If a product has been evaluated under the TCSEC to comply with the requirements of a rated class, it means that an independent assessment showed the product to have the features and assurances of that class. It does not mean that the product is impenetrable.

Interpreted TCSEC (ITCSEC)

The Interpreted Trusted Computer Security Evaluation System Requirements (ITCSEC) is a version of the TCSEC maintained by the TTAP that annotates the TCSEC requirements with all current interpretations.

Often, there are several ways to read a given statement in the TCSEC. Interpretations are official statements that articulate which, of a number of possible ways to read the requirement, are acceptable. Interpretations are developed and proposed by a group of highly experienced product evaluators. After considering comments and revising the interpretation as appropriate, sometimes through several rounds of comments and revision, the proposed interpretation is accepted by the TTAP and officially announced.

TNI (Red Book)

The Trusted Network Interpretation of the TCSEC (TNI) or Red Book restates the TCSEC requirements in a network context. Part I of the Red Book gives guidelines for evaluating a network of computers and communication devices (sometimes called a distributed, or homogeneous, system) where a single trusted computing base is physically and logically partitioned among the network's components. Appendix A of the TNI provides guidance for evaluation of the individual components of a trusted network.

The Red Book is an interpretation of the Orange Book as it applies to network security. In the successful evaluation of Windows NT 4.0, the Red Book was used to evaluate the networking component of the secure system.

Evaluation Process

TTAP evaluation is the comprehensive technical analysis of a product's security functionality. It involves hands-on testing of complete security systems, including both hardware and software components of the product and associated documentation. The testing involves running the vendor's test suite, as well as tests formulated by the evaluation team.

Evaluation begins with a vendor approaching the NIST with a commercial-off-the-shelf (COTS) computer security product and requesting an evaluation that targets a particular level of trust rating. Evaluators at TTAP-authorized commercial testing facilities assess how well the product meets the requirements for the targeted rating. The evaluation team must determine that the system meets all of the TCSEC C2 requirements, and prepare and defend an Initial Product Assessment Report (IPAR) documenting this determination.

Since the team must understand the system to a level at which such analysis can be made, evaluation evidence in the form of design documentation, training, informal vendor presentations, and so on, is provided by the vendor. The vendor also provides system-level, developer-oriented training for the product. Training is followed by the team's comprehensive analysis of the system design and review of the user, test, and Rating Maintenance Phase (RAMP) documentation. The information gathered during design analysis is used to write the IPAR, which the team presents to a Technical Review Board (TRB). The team also briefs the TRB on the vendor's and the team's plans for testing the product.

After the TRB meeting, the evaluation team performs security testing on the product. The test results are combined with the IPAR and edited to form the Final Evaluation Report (FER). The team presents final responses to open issues and the results of testing to a Final TRB. The Final TRB makes its recommendations to the TTAP Oversight Board regarding the product's requested trust rating. The Oversight Board then makes the final decision to place the evaluated product on the Evaluated Product List (EPL) at the requested level. Finally, the EPL entries and the final evaluation reports are published, and the evaluation documentation is archived.

Timelines

The typical NCSC evaluation cycle takes longer than the product release cycle of Windows NT.

The evaluation cycle begins with an Intensive Preliminary Technical Review (IPTR), a short (one to two week) assessment of the state of the product documentation and testing. A successful IPTR ensures that the materials needed for evaluation are complete and usable. The length of time a vendor needs to prepare for an IPTR varies considerably.

After the IPTR, the time for evaluation may be lengthened by such factors as technical problems that arise, changes in the configuration the vendor is planning to market, and system complexity.

Once evaluation is complete, later configuration changes can be included through a maintenance program called Rating Maintenance Phase (RAMP). RAMP allows vendors to analyze changes to an already-evaluated product to maintain the evaluated rating on later versions. The length of time to obtain a RAMP rating depends on the vendor and on the nature and complexity of the change. However, it is reasonable to expect a RAMP assessment to take far less time than an initial product evaluation.

The TTAP conducts hands-on testing of complete security systems. Thus, where system complexity is such that later versions have very different configurations, RAMP updates are not feasible. This is why the Windows NT 3.5 evaluation did not extend to Windows NT 4.0. By the same token, the Windows NT 4.0 evaluation cannot extend to Windows 2000.

Reporting the Results: the Evaluated Products List (EPL)

The results of the TTAP evaluations are published quarterly in the EPL as Chapter 4 of the Information Systems Security Products and Services Catalog, which is available from the U.S. Government Printing Office. EPL entries issued within the last three years are posted on the Internet at https://www.radium.ncsc.mil/tpep/epl/epl-by-class.html.

C2-Equivalent Evaluation in Other Countries

Other parts of the world have been developing computer security standards that are comparable to the American A-B-C-D levels. One such rating system, the ITSEC, was mentioned in Chapter 3; others are the Canadian Trusted Computer Product Evaluation Criteria (CTCPEC) and the Australasian Information Security Evaluation Programme (AISEP).

In 1995, NIST released a draft bulletin recommending that if an appropriate C2-rated product is not available, the following could be used:

• ITSEC-rated E2/F-C2 products (that is, with an E2 assurance level and an F-C2 functionality profile).

• Products with a CTCPEC rating of T1 assurance and C2 functionality profile.

United Kingdom and Europe

The ITSEC is recognized in most of western Europe. It represents a single uniform standard adopted by the U.K., France, Germany, the Netherlands, and the European Commission. The standards created under the U.K. ITSEC scheme are designed to apply both to products and to end-user systems.

The ITSEC is a set of European-developed criteria roughly equivalent to the TCSEC. An important distinction is that the ITSEC places greater emphasis on integrity and availability, and attempts to provide a uniform approach to the evaluation of both products and systems.

The ITSEC also introduces a distinction between doing the right job (effectiveness) and doing the job right (correctness). In so doing, the ITSEC allows less restricted collection of system requirements at the expense of more complex and less comparable ratings and the need for effectiveness analysis of the features claimed for the evaluation.

The question of whether the ITSEC or TCSEC is the better approach has been the subject of intense debate.

Administration

In the U.K., the ITSEC scheme is administered by the Certification Body, which is jointly managed by the U.K.'s Communications-Electronics Security Group (CESG) and Department of Trade and Industry (DTI). Evaluations are performed by Commercial Licensed Evaluation Facilities (CLEFs). These are commercial entities appointed by the Certification Body and responsible for meeting its testing requirements and operating conditions. The latest products to be certified in the U.K. are posted on the Internet at https://www.itsec.gov.uk.

Later configuration changes are accommodated through a maintenance program similar to the RAMP program used by the United States. This is called the Certification Maintenance Scheme (CMS).

Certification Mark

Certification under the ITSEC scheme allows the vendor to stamp or print the product with the ITSEC Certification Mark. The mark offers an assured level of security for end users and confirms that the product achieves internationally recognized security standards.

All products authorized to use the mark have achieved a predetermined level of functionality and security. Under the ITSEC scheme there are six security assurance levels that can be achieved.

ITSEC Assurance Level

In an ITSEC evaluation, the assurance rating given to a product indicates the level of analysis and supporting documentation used in the testing. The greater the assurance rating, the higher the assurance.

ITSEC assurance levels range from E0 (inadequate assurance, the lowest) through E6. Windows NT has been certified at level E3, which is typically mapped to the level of analysis performed in a U.S. B-level evaluation. E3 has the following requirements:

E3 Assurance Level

• Source code or hardware drawings are produced.

• Correspondence is shown between source code and detailed design.

• Acceptance procedures are used. Implementation languages meet recognized standards.

• Retesting is done after the correction of errors.

The E3 level also includes all the requirements of levels E2 and E1, which are described in the following sections.

E2 Assurance Level

• An informal detailed design and test documentation are produced.

• Architecture shows the separation of the evaluated system into security enforcing and other components.

• Penetration testing searches for errors.

• Configuration control and developer's security are assessed.

• Audit trail output is required during startup and operation.

E1 Assurance Level

• A security target and informal architectural design are produced.

• User and administrator documentation give guidance on system security.

• Security enforcing functions are tested by evaluator or developer.

• The system is uniquely identified and has Delivery, Configuration, Startup, and Operational documentation.

• Secure distribution methods are used.

Note: In meeting the E3/F-C2 level of assurance under the ITSEC, Windows NT exceeds the NIST requirement of E2/F-C2 for U.S. C2 compatibility.

Canada

The Canadian Trusted Computer Product Evaluation Criteria (CTCPEC) is the Canadian equivalent of the TCSEC. It is somewhat more flexible than the TCSEC (along the lines of the ITSEC) while maintaining fairly close compatibility with individual TCSEC requirements. Under the CTCPEC, the C2 functionality profile with assurance level T1 is similar to the U.S. C2 level.

Canada maintains an EPL similar to that of the United States. Called the CEPL or Canadian Evaluated Products List, it is available from the Information Technology Security office of the federal Communications Security Establishment in Ottawa. The CEPL is posted on the Internet at https://www.cse-cst.gc.ca/en/knowledge_centre/knowledge_centre.html.

Australasia

Australia and New Zealand (collectively "Australasia") use a rating system called the Australasian Information Security Evaluation Programme (AISEP). The AISEP is based on the ITSEC. The certification body in Australia is the Defence Signals Directorate (DSD); in New Zealand, it is the Government Security Bureau (GCSB). The DSD publishes its results in an EPL; the GCSB publishes its results in a Preferred Product List (PPL). A Management Policy Board, composed of government, standards, and industry representatives, oversees the program.

Evaluations are performed by Evaluation Facilities (AISEFs). The Australasian maintenance program that is equivalent to the CMS and RAMP is called AISEP Certificate Extension. Under this program, an update of a product that has been certified as E1, E2, or E3 need not be submitted for reevaluation by an AISEF, provided the update does not change the description of the operation of security enforcing functions (SEFs) in either the high-level design or the security target.

Both the Australian EPL and the U.K. CPL list products that have been accepted by the respective certification body as "in evaluation." This practice reflects the certification body's confidence that the product is capable of being evaluated at the level for which it is submitted. In Australia, government organizations are encouraged to purchase products "in evaluation" over products not submitted for evaluation. Of course, fully evaluated products are preferred to those that are still in evaluation.

AISEFs are subject to the same basic requirements and conditions of operation as CLEFs in the U.K.

The AISEP equivalent of the ITSEC Certification Mark is called the AISEP Stamp.

Common Criteria: A New International Standard

The differences among the U.S., European, and Canadian criteria have sometimes caused problems in recognition of testing results, with developers having to have their products separately tested for different markets. Although several countries test according to the ITSEC criteria, they retain the right "in the national interest" to refuse reciprocal recognition of each other's evaluations. Thus a product that has been successfully evaluated in the U.K. may need to be evaluated again, using the same criteria, if it is to be sold in France.

The Common Criteria (CC) addresses this difficulty. It is the result of an effort to write a set of multinational criteria applying to large parts of the world. Version 1.0 was released in January 1996, and version 2.0 was accepted as an international standard in April 1998.

Objectives

The CC is a successor to the TCSEC and its international counterparts that combines the best aspects of each. It is an important advance in international computer security testing because it will eventually allow testing results published in one country to be recognized globally.

The CC has a structure closer to the ITSEC than the TCSEC and includes the concept of a protection profile to collect requirements into easily specified and compared sets.

One aim of the CC is to use general terminology applicable to both commercial and military uses. This addresses a problem created by the U.S. Computer Security Act of 1987, which prohibits the NCSC from directly addressing the needs of commercial computer systems. It seems reasonable to address them together because commercial users require many of the same basic features as the military: identification and authentication; ability to audit user actions; and control of access to information, both at the discretion of the information owner and by corporate policy.

Recognition Agreement

On October 17, 1997, the U.K., U.S., and Canada signed an agreement to recognize each country's Common Criteria evaluation results. The agreement was announced at the 20th National Information Systems Security Conference in Baltimore, MD. Later signatories were Germany, the Netherlands, and France. All signatories agreed to recognize CC certifications by any one of them, without requiring further validation, at assurance levels of EAL1 through EAL4.

The final draft of the Common Criteria version 2.0 was published in December 1997 and was adopted by the International Standards Organization (ISO) in April 1998. The U.K. ITSEC scheme administers Common Criteria testing in the U.K. Australasia also recognizes the Common Criteria and will retrospectively list all products evaluated against the AISEP, along with their CC equivalents, on the EPL.

Common Criteria Assurance Levels

The CC evaluation assurance levels have been developed to preserve the assurance and results of previous evaluations performed using the source criteria (TCSEC, ITSEC, and CTCPEC). Comparisons are possible, but should be made with caution. Table A.1 can be used to assist in making such comparisons, though it is by no means intended to assert exact equivalence, since the levels do not derive assurance in exactly the same manner.

Table A.1 Comparison of Assurance Levels under Different Evaluation Systems

Common Criteria	TCSEC (Orange Book)	ITSEC
EAL0: Inadequate Assurance	D: Minimal Protection	E0: Inadequate assurance
EAL1: Functionally Tested	No equivalent	No equivalent
EAL2: Structurally Tested	C1: Discretionary Security Protection	E1 (See "ITSEC Assurance Level" earlier in this appendix.)
EAL3: Methodically Tested and Checked	C2: Controlled Access Protection	E2 (See "ITSEC Assurance Level" earlier.)
EAL4: Methodically Designed, Tested, and Reviewed	B1: Labeled Security Protection	E3 (See "ITSEC Assurance Level" earlier.)
EAL5: Semiformally Designed and Tested	B2: Structured Protection	E4: Formal model, configuration control, auditing of changes.
EAL6: Semiformally Verified Design and Tested	B3: Security Domains	E5: Relations between security-enforcing features (SEFs) explained; information provided on integration process and run-time libraries.
EAL7: Formally Verified Design and Tested	A1: Verified Design	E6: Correspondence shown from formal specification of SEFs through to source code and tests.

The CC assurance levels are defined as follows.

EAL0 Inadequate Assurance.

EAL1 Functionally Tested. Analysis of the security functions is provided, using a functional and interface specification of the product, to understand the security behavior. The analysis is supported by independent testing of the security functions.

EAL2 Structurally Tested. Analysis of the security functions is provided, using a functional and interface specification and the high-level design of the product's subsystems. The analysis is supported by independent testing of the security functions, evidence of developer "black box" testing, and evidence of a search for obvious vulnerabilities.

EAL3 Methodically Tested and Checked. The analysis is supported by "gray box" testing, selective independent confirmation of the developer test results, and evidence of a developer search for obvious vulnerabilities. Development environment controls and product configuration management are provided.

EAL4 Methodically Designed, Tested, and Reviewed. Analysis is supported by the low-level design of the modules of the product, and a subset of the implementation. Testing is supported by an independent search for obvious vulnerabilities. Development controls are supported by a life-cycle model, identification of tools, and automated configuration management.

EAL5 Semiformally Designed and Tested. Analysis includes all of the implementation. Assurance is supplemented by a formal model and a semiformal presentation of the functional specification and high-level design, and a semiformal demonstration of correspondence. The search for vulnerabilities ensures relative resistance to penetration attack. Covert channel analysis and modular design are also provided.

EAL6 Semiformally Verified Design and Tested. Analysis is supported by a modular and layered approach to design, and a structured presentation of the implementation. The independent search for vulnerabilities ensures high resistance to penetration attack. The search for covert channels is systematic. Development environment and configuration management controls are further strengthened.

EAL7 Formally Verified Design and Tested. The formal model is supplemented by a formal presentation of the functional specification and high-level design showing correspondence. Evidence of developer "white box" testing and complete independent confirmation of developer test results are provided. Complexity of the design is minimized.

Additional Resources

• For more information about U.S. C2 standards, see DoD 5200.28-STD, Department of Defense Trusted Computer System Evaluation Criteria (Orange Book), December 1985, and NCSC-TG-005, Trusted Network Interpretation of the TCSEC (TNI) (Red Book), July 1987. Both books may be viewed on the Internet at https://www.radium.ncsc.mil/tpep/library/rainbow.

• For more information about international equivalent standards, see Information Technology Security Evaluation Criteria (ITSEC), DTI, London, June 1991, and CCEB-96, Common Criteria for Information Technology Security Evaluation (CCITSE), TPEP, July 1996. Both books may be viewed on the Internet: the ITSEC at https://www.itsec.gov.uk ; and the CCITSE at https://www.radium.ncsc.mil/tpep/library/ccitse.

• For more information about environmental aspects of evaluating a computing system, see NCSC-TG-029, Introduction to Certification and Accreditation Concepts (Blue Book), January 1994. This book may be viewed on the Internet at https://www.radium.ncsc.mil/tpep/library/rainbow.

• For more information about the Windows NT philosophy of protection, see Inside Windows NT by Helen Custer, Microsoft Press, 1993, and Windows NT 3.5Guidelines for Security, Audit, and Control, Microsoft Press, 1996.

• For more information about evaluation reports on Windows NT, see CSC-FER-95/003, Final Evaluation Report, Microsoft, Inc., Windows NT Workstation and Server version 3.5 with U. S. Service Pack 3, April 1996; Certificate 96/71, Microsoft® Windows NT® Workstation and Microsoft® Windows NT® Server version 3.51, ITSEC, October 1996; and https://www.radium.ncsc.mil.

Appendix B - Discretionary Access Control Lists (DACLs)

Windows NT uses DACLs to control access between named users and named objects. The use of DACLs allows users to specify and control the sharing of objects with other users, groups of users, or both. The DACL structure has the ability to specify that an access right be granted or denied at the granularity of an individual user.

There are rules which dictate how an object is assigned a DACL when it is created. These rules are described in "DACL Inheritance". If no DACL is provided through various other ways, the object will always receive the default DACL, which is a field in the object's owner's token. Therefore, objects are protected by default. An object's default protection is further described in "Default Object Security".

Access permission to an object by users not already possessing access permission can only be granted by modifying the DACL of that object to grant this access permission. The owner of an object always has ReadControl and WriteDAC access, which allow the owner to always be able to read and write the DACL. The owner of an object and those with WriteDAC access to an object are the only users who can modify the DACL of that object. Those with WriteOwner access have the ability to modify the DACL, but they must first make themselves the owner of the object. Object Ownership is described in further detail in "Object Ownership". Propagation of access rights is limited by object ownership.

There are several privileges which allow exception to the DACL: TakeOwnership, Backup, Restore, and Debug. These are each described in "Discretionary Access Control Related Privileges". Of these privileges, Debug will not be assigned to any users in the evaluated configuration, and the others should only be assigned to administrators.

Discretionary Access Control

Windows NT implements a discretionary access control policy using DACLs. The Windows NT philosophy of discretionary access control and DACL assignment is described in this section.

Discretionary Access Control Philosophy

Windows NT implements a discretionary access control policy between all protected objects and subjects. Discretionary access control provides a means of restricting access to objects based on the identity of a subject and/or the identity of groups (i.e., a collection of users) to which the subject belongs. It is at the discretion of the owner of an object, or any user who has WriteDac access to that object, to define the access restrictions to that object. Windows NT uses DACLs as the mechanism to enforce discretionary access control philosophy. Each entry in the DACL (an ACE) can specify an access to grant or deny to a particular user or group. There are many different types of objects, and each type has a set of defined access rights which can be allowed or denied in the DACL policy. Each of these specific access rights and the access rights which apply to all object types are discussed in detail in "Object-Specific Attributes".

The enforcement of discretionary access control, the authority of object ownership, discretionary access control revocation, and privileges which override the DACL are each described in this section.

Discretionary Access Control Enforcement

The Security Reference Monitor (SRM) validates a requested access to an object by a subject. It performs this validation by comparing the object's DACL against the identity(s) listed in the requesting subject's token. There are two categories of objects: executive and server objects.

For executive objects, a handle must be obtained by a subject before that subject can access that object. The ways to obtain a handle to an object are: object open, object create, inheritance, handle duplication, and special interfaces that allow for handle creation (NTCurrentProcess, NTCurrentThread, NTOpenProcessToken, NTOpenThreadToken). Each one of these results in handle creation and each one, with the exception of handle inheritance, results in a call to the SRM for access validation. The Object Manager creates handles for all executive objects. However, before the Object Manager releases a handle to a subject requesting access to objects, it calls the SRM for access validation. The Object Manager then stores the granted access mask, which it receives from the SRM (if the requested access right is valid), in the handle and releases the handle to the subject. All subsequent access requests to that object by that subject are then checked against the granted access mask stored in the handle. If an access right to an object is requested by a subject and that access right is not included in the granted access mask, then that access request is denied. Handle inheritance allows a child process to get copies of designated handles from its parent process. This is implemented by an inheritance bit in each of the handles of the parent process, which specifies the inheritance designation of the handle.

For server objects, a subject must open an object before any access to it is allowed. Each server calls the SRM for access validation before it opens an object. The SRM returns the granted access mask to the server and the server stores this mask in a type-specific structure (handle). This structure is used to restrict subsequent access requests by that subject to the object. As in the executive, if a different access is requested by a subject which is not in the granted access mask for that object, the request fails.

Object Ownership

The owner of an object is specified in the security descriptor of that object. The owner of an object is always allowed ReadControl access and WriteDac access regardless of what is specified in the DACL policy. WriteOwner is a standard access right which allows the owner of an object to be changed. The TakeOwnership privilege allows the same access as WriteOwner to all objects, without being granted the WriteOwner access in the DACL policy.

DAC Revocation

A DACL can be changed on an object to which a subject currently has a handle. A change in an object's DACL will not impact subjects which already have a handle to this object.

For executive objects, once a handle is obtained, the granted access mask indicating the allowed access rights a user's process has to an object is valid as long as the handle is valid, regardless of changes made to the DACL philosophy. A handle to an object is valid as long as that object is opened.

For server objects, similar to executive objects, the access rights granted when an object is opened are valid as long as that object is opened, regardless of changes made to the DACL policy.

Access to objects is not immediately revoked; however, a change to an object's DACL becomes effective upon future attempts to open that object.

DAC Related Privileges

There are privileges which allow exception to what is specified in the DACL policy. If the primary or impersonation token of the process requesting access has any of these privileges enabled, the DACL is overridden. The privileges which allow exceptions to the DACL are listed below.

• TakeOwnership

• Security

• Backup

• Restore

• Debug

• ChangeNotify

Of the privileges listed, the SRM knows only about the TakeOwnership privilege (in the DAC related context. TakeOwnership privilege grants WriteOwner access to an object.

The other privileges listed above allowing DACL exception are enforced by other responsible subsystems which call the SRM privilege test routine. Backup and Restore privileges are enforced by the Configuration Manager and \NTFS\ subsystems, and the debug privilege is enforced by the Process Manager subsystem. The ChangeNotify privilege provides the reverse access on directories. This privilege is given, by default, to all users and is not considered security relevant. The Security privilege provides several abilities. The SRM does know about its use to provide access to the SACL and enforces its privilege check. However, the Security privilege also provides access to the security log, overriding the DACL to the security log. The Event Logger is responsible for enforcing the Security privilege in this context.

DACL Processing

This section describes the initial assignment of the DACL, the default DACL, and the difference between an empty DACL and an absent DACL policy.

DACL Assignment

When an object is created there are several ways for a DACL to be assigned. The DACL can be explicitly provided, can be a default DACL, or can be inherited. The explicitly provided method is when parameters defining the DACL are passed into the object create system call. Assignment of the DACL by default and via inheritance are described in this section.

DACL Inheritance

There are two classifications of objects: container and noncontainer. Container objects (e.g., printer) can logically contain other objects and noncontainer objects (e.g., job) may not contain other objects. Objects within container objects may inherit the ACL from the container object. Each ACE within the ACL of a container object can be inherited by sub-objects of that container object. There are control flags which are only valid for container objects in each ACE which specify if and how that ACE can be inherited. Note that a sub-object can be either a container or non-container object. The inheritance control flags are as follows:

• ObjectInherit - inherited by sub-objects of the container.

• ContainerInherit - inherited by sub-containers of the container.

• NoPropagateInherit - inheritance control flags are not propagated in ACEs inherited by sub-containers.

• InheritOnly - ACE is not to be used in validating access attempts to the corresponding object, but will be applied to sub-objects as they are created.

The inheritance control flags of the container object and the type of the sub-object (container or non-container) determine if and how ACEs are inherited. The policy is described in this section for both container and non-container sub-objects.

Container Sub-Object Inheritance Algorithm

For each ACE in the object's ACL:

1. If the ContainerInherit flag in the container object's ACE is not set, then go to step 2. Otherwise:

   A copy of the ACE is added to the end of the inherit ACL and the following actions performed on it.

   • The InheritOnly flag in the inherited ACE is cleared.

   • The NoPropagateInherit flag in the inherited ACE is copied from the container object's ACE policy.

   • The ObjectInherit and ContainerInherit flags in the inherited ACE are set according to the value of the NoPropagateInherit flag. If the NoPropagateInherit flag is cleared, then the ObjectInherit and ContainerInherit flag values are copied to the inherited ACE from the container object's ACE policy. Otherwise, the ObjectInherit and ContainerInherit flags in the inherited ACE are cleared.

   • If the ACE access mask has any generic access flags set, then map the indicated generic rights to the standard and specific rights of the sub-object type.

2. If the container object's ACE is marked both ContainerInherit and InheritOnly, but not the NoPropagateInherit, then another copy of the ACE is added to the end of the inherit ACL without change.

3. If the ContainerInherit flag is not set and the NoPropagateInherit flag is not set, then the ObjectInherit and InheritOnly flags are checked. If both of these flags are set, then the ACE is added to the end of the inherit ACL policy.

4. Otherwise, the ACE is not inherited.

Non-container Sub-Object Inheritance Algorithm

If the ObjectInherit flag is set, then the ACE is inherited and the following rules apply.

• The InheritOnly flag in the inherited ACE is cleared.

• The NoPropagateInherit, ObjectInherit and ContainerInherit flags in the inherited ACE are cleared.

• If the ACE access mask has generic access flags set, then map the indicated generic rights to the standard and specific rights of the sub-object type.

1. Otherwise, the ACE is not inherited.

Default Object Security

All named executive objects and server objects must have a DACL policy. Unnamed executive objects need not have a DACL with the exception of process, thread, and token object types. The default methods described in this section apply to those objects which must have a DACL policy. When a DACL is not explicitly provided or obtained via inheritance, it will be assigned by default. Another discretionary access control related security attribute, the owner attribute, will also be defaulted to if not provided explicitly. The security attributes of an object are stored in the security descriptor. A field in the security descriptor points to the object's DACL policy. When a new object is created, the values assigned to the object's security descriptor are based on the following information: the user creating the object, any explicit values provided by the creator, any default values provided in the creating process' token, and any inheritable DACL information according to the rules stated earlier in "DACL Inheritance".

The following rules state how each discretionary access control related security attribute is assigned to newly created named objects. The order of steps indicates the order the search for a value is performed. The search ends when the first value is found.

Owner:

1. An explicit or default value in the security descriptor, if provided.

2. A default value in the creating process' token, if provided.

3. The creator's SID provided in the creating process's token.

DACL:

1. The explicit DACL in the security descriptor, if provided.

2. The inheritable ACEs in the DACL of the container object which contains this object, if any. (As defined in "DACL Inheritance").

3. The default DACL in the security descriptor, if provided.

4. The default DACL in the creating process' token.

5. No DACL is assigned, granting unconditional access to everyone. This cannot happen in the evaluated configuration. In the evaluated configuration, by default, every user is assigned a default DACL in the token of the first process created for them at logon.

   The default DACL is for the SYSTEM and the owner to get all access.

Absent vs. Empty DACL

There is a difference between the protection of an object that does not have a DACL (absent DACL) and an object that has a DACL with no ACEs in it (empty DACL). An empty DACL indicates that access is denied. An absent DACL indicates there is no protection assigned to the object, and unconditional access is granted.

Object-Specific Attributes

This section explains the specific access rights for all Windows NT objects.

This appendix lists the object-specific security-related attributes for each of the Windows NT protected objects identified in "NT Protected Objects" in the Microsoft Windows 4.0 Final Evaluation Report. For each object type, the following information is provided:

[Object Type:]
Name of the object type and a brief description of the object's purpose.

[Managing Subsystem or Server:]
Executive subsystem or protected server responsible for the object type. See "NT Protected Objects" in the Microsoft Windows 4.0 Final Evaluation Report for references to report section describing the subsystem or server.

[Specific Access Rights:]
The type-specific access rights defined for the object type, along with a brief definition of the type of access each right allows (or denies).

[Mapping to Generic Access Rights:]
A mapping between the specific access rights and the generic access rights for this object type. As discussed above, the mapping between the generic and standard access rights is the same for all object types. A mapping to GenericAll is not provided for each object type since GenericAll maps to all specific and standard access rights for each object type.

[Default Protection (Servers Only):]
Most server object types have pre-defined DACLs and owner for all instances of that type. Often, this DACL cannot be changed.

Although Synchronize is a standard access right, it is not supported for most Discretionary Access Control object types. Therefore, it will be listed along with the specific access rights for the objects to which it applies.

Non-I/O Executive Objects

OBJECT TYPE: Event

Event objects are an inter-process synchronization mechanism. Threads can set, reset, and wait on an event object.

Managing Subsystem: Executive Object Services

Specific Access Rights:

[Query\_State:]
Permission to determine the current state of an event.

[Modify\_State:]
Permission to change the current state of an event.

[Synchronize:]
Permission to wait on an event.

Mapping to Generic Access Rights:

GenericRead: Query\_State 
GenericWrite: Modify\_State 
GenericExecute: Synchronize 

OBJECT TYPE: Event Pair

An event pair object has two events: Event Low and Event High. These events are autoclearing (i.e., when Event Low is set, Event High is cleared, and vice versa). An event pair can be used to synchronize message passing via shared memory between two threads. The primary user of event pair objects is the Win32 server in the implementation of Quick LPC (see "Win32 Interface" in the Microsoft Windows 4.0 Final Evaluation Report).

Managing Subsystem: Executive Object Services

Specific Access Rights:

[Synchronize:]
Permission to use an event pair.

Mapping to Generic Access Rights:

GenericRead: Synchronize  
GenericWrite: Synchronize   
GenericExecute: Synchronize  

OBJECT TYPE: I/O Completion Port

This object provides a means to synchronize I/O. This object is based on the microkernel's queue object. To use this object, a thread associates an I/O completion port with a file and starts an I/O operation. When the I/O operation completes, the executive will queue a message on the I/O port. The message can be subsequently read by a thread with access to the I/O completion port object.

Managing Subsystem: Executive Object Services

Specific Access Rights:

[Query\_State:]
Permission to determine the depth of the queue (i.e., how many messages are on the queue).

[Modify\_State:]
Permission to remove a message from the queue.

[Synchronize:]
Permission to wait on the queue for an I/O completion.

Mapping to Generic Access Rights:

GenericRead: Query\_State  
GenericWrite: Modify\_State  
GenericExecute: Synchronize  

OBJECT TYPE: Key

Key objects are the only objects provided by the Configuration Manager, and the basis for the hierarchical registry name space. Keys have a fixed header (which includes the key name, key class, access control list), and two variable parts. The first variable part contains a set of value entries (an entry has a name, a title index, a type, and a value). The second part contains a list of sub-keys.

Managing Subsystem: Configuration Manager

Specific Access Rights:

[Query\_Value:]
Permission to read an entry's value and type information, and time modified field.

[Set\_Value:]
Permission to write value and type entries.

[Create\_Sub\_Key:]
Permission to create a new sub key.

[Enumerate\_Sub\_Key:]
Permission to list the names of sub-keys.

[Traverse]
(Traverse access is not implemented.)

[Notify:]
Permission to receive notification when a key is changed, modified, or created.

[Create\_Link:]
Permission to create a symbolic link to a key object within the registry name space.

Mapping to Generic Access Rights:

GenericRead: Query\_Value  
Enumerate\_Sub\_Keys   
Key\_Notify   
GenericWrite: Set\_Value  
Create\_Sub\_Key   
GenericExecute: Query\_Value   
Enumerate\_Sub\_Key   
Key\_Notify   

OBJECT TYPE: Mutant

A mutant object is a means for providing mutual exclusion between two or more threads. Only one thread may be the owner of a mutant; other threads may wait on a mutant object until they can obtain ownership.

Managing Subsystem: Executive Object Services

Specific Access Rights:

[Query\_State:]
Permission to read the current state of a mutant object.

[Synchronize:]
Permission to use (i.e., wait or release) a mutant object.

Mapping to Generic Access Rights:

GenericRead: Query\_State  
GenericWrite: none  
GenericExecute: Synchronize  

OBJECT TYPE: Object Directory

Object directories contain pointers to other objects, and form the basis of the hierarchical structure of the global name space (by one object directory containing pointers to another object directory). For example, the global root directory is an object directory type. Object directories should not be confused with NTFS directory objects described later.

Managing Subsystem: Object Manager

Specific Access Rights:

[Query:]
Permission to read the names and types of objects in the directory.

[Traverse:]
Permission to perform name look up through the directory. This access right is not considered security relevant and all processes, by default, are given a privilege to bypass Traverse access checking. Traverse access checking is included within Windows NT to support conformance with standards such as POSIX.

[Create\_Object:]
Permission to add a pointer to a named object (other than object directory type) in the directory.

[Create\_Subdirectory:]
Permission to place a directory type objects in the directory object.

Mapping to Generic Access Rights:

GenericRead: Query   
Traverse   
GenericWrite: Create\_Object   
Create\_Subdirectory   
GenericExecute: Query   
Traverse   

OBJECT TYPE: Object Symbolic Links

Object symbolic links provides a means for name aliasing of objects within the Object Manager's global name space. When the Object Manager discovers a object symbolic link during name parsing, it uses the value stored in the link object to complete name parsing. Object symbolic links only have meaning within the Object Manager's global name space (see "Object Name Space" in the Microsoft Windows 4.0 Final Evaluation Report).

Managing Subsystem: Object Manager

Specific Access Rights:

[Query:]
Permission to read the value stored in the link object. The value of the link is set during creation and cannot be changed.

Mapping to Generic Access Rights:

GenericRead: Query   
GenericWrite: none   
GenericExecute: Query   

OBJECT TYPE: Port

Port objects provides a means for inter-process communication. There are two types of ports: connection and communication. A connection port is created and announced (i.e., named) by a server process. Once a client process successfully connects to a connection port, then a pair of communication ports (client-side and server-side) are created to facilitate two-way communication between the server and the client. A client process never obtains a handle to a connection port; rather, once a successful connection occurs, the client process receives a handle to the client-side communication port (and likewise for the server and the server-side communication port).

Managing Subsystem: Local Procedure Call Facility

Specific Access Rights:

[Connect:]
Permission to use a connection port in an attempt to establish a connection with the port's server. Permission to connect to a port does not imply the ability to actually establish a connection; the server can always refuse the connection request.

Mapping to Generic Access Rights:

GenericRead: Connect   
GenericWrite: Connect   
GenericExecute: none   

OBJECT TYPE: Process

A process object is the basic execution environment for threads and includes an address space, handle table, and security context (i.e., token objects). All threads associated with a given process object have equal access to all of the process' resources. Additionally, threads within other processes may access a process object by obtaining a valid handle to the process object (e.g., by opening the process object).

Managing Subsystem: Process Manager

Specific Access Rights:

[Terminate:]
Permission to terminate (destroy) a process object and all associated thread objects.

[Create\_Thread:]
Permission to create a new thread within the process object.

[VM\_Operation:]
Permission to manipulate the address space (other than reading and writing) of a process object.

[VM\_Read:]
Permission for a thread not associated with the process object to read memory regions of the process object (given that those regions are readable in the process object).

[VM\_Write:]
Permission for a thread not associated with the process object to write memory regions of the process object (given that those regions are writable in the process object).

[Dup\_Handle:]
Permission to copy a handle from one process to another process. The calling thread must have Dup\_Handle access to both processes to successfully duplicate an object handle. A handle to any executive object type can be duplicated in this manner.

[Create\_Process:]
Permission to use a process object as the parent of a new process.

[Set\_Quota:]
Permission to modify resource quota limits for a process object.

[Set\_Information:]
Permission to modify certain attributes of a process (e.g., priority, working set size).

[Query\_Information:]
Permission to query certain information of a process (e.g., priority, working set size, quotas).

[Set\_Port:]
Permission to define the debug or exception port associated with a process.

[Synchronize:]
Permission to wait on a process handle until the process terminates.

Mapping to Generic Access Rights:

GenericRead: VM\_Read   
Query\_Information   
GenericWrite: Create\_Process   
Create\_Thread   
VM\_Operation   
VM\_Write   
Dup\_Handle   
Terminate   
Set\_Quota  
Set\_Information  
Set\_Port  
GenericExecute: Synchronize  

OBJECT TYPE: Profile

A profile object provides a means to measure the distribution of execution time across regions of memory (i.e., blocks of code).

Unlike all other server objects, access to a profile is controlled completely by privileges. SystemProfile privilege is required to create a profile object for all processes. Query access to the target process is required to create a profile object for a single process.

Managing Subsystem: Executive Object Services

Specific Access Rights: Not applicable.

Mapping to Generic Access Rights: Not Applicable.

OBJECT TYPE: Section

Section objects are regions of memory that can be shared between processes. Sections can be optionally backed by a file object (i.e., memory-mapped file I/O), in which case the section object is a means to access a file (and to share that access). Otherwise sections are backed by the system paging file. When a section is backed by a file, access to the section object is contingent upon access to the file (see "Section Objects and Shared Memory" in the Microsoft Windows 4.0 Final Evaluation Report).

Managing Subsystem: Memory Manager

Specific Access Rights:

[Map\_Read:]
Permission to map read-only views to a section.

[Map\_Execute:]
Permission to map execute-only views to a section (currently equivalent to read).

[Map\_Write:]
Permission to map read-write views to a section.

[Query:]
Permission to obtain attribute information about a section to include section size and associated backing file (if any).

[Extend\_Size:]
Permission to extend the size of sections backed by memory mapped file.

Mapping to Generic Access Rights:

GenericRead: Query 
Map\_Read 
GenericWrite: Map\_Write 
GenericExecute: Map\_Execute 

OBJECT TYPE: Semaphore

A semaphore is a counting inter-process communication object that aides in providing control of critical resources. A thread trying to acquire a semaphore will wait until the count is greater than zero. If the count is greater than zero, then the thread decrements the count and continues. When the thread releases the semaphore, the count is incremented.

Managing Subsystem: Executive Object Services

Specific Access Rights:

[Query\_State:]
Permission to read the current state information of a semaphore object.

[Modify\_State:]
Permission to modify a semaphore's current state.

[Synchronize:]
Permission to wait on a semaphore object.

Mapping to Generic Access Rights:

GenericRead: Query\_State  
GenericWrite: Modify\_State  
GenericExecute: Synchronize  

OBJECT TYPE: Thread

A thread object represents an execution point within a process, including its own set of machine registers, and kernel-mode and user-mode stacks. A thread may also have an impersonation token (which, when present, supersedes the primary token associated with the thread's process for discretionary access validation decisions).

Managing Subsystem: Process Manager

Specific Access Rights:

[Terminate:]
Permission to destroy a thread.

[Suspend\_Resume:]
Permission to suspend or resume a thread.

[Alert:]
Permission to send an alert (which is similar to an interrupt) to a thread.

[Get\_Context:]
Permission to read the user-mode-visible machine context of a thread.

[Set\_Context:]
Permission to modify the user-mode-visible machine context of a thread.

[Set\_Information:]
Permission to modify certain attributes of a thread (e.g., priority, processor affinity).

[Query\_Information:]
Permission to read the above attributes, and to open (for read) a thread's impersonation token.

[Set\_Thread\_Token:]
Permission to explicitly assign an impersonation token to a thread (impersonation tokens may also be implicitly assigned, e.g., as a result of an LPC communication).

[Impersonate:]
Permission to directly impersonate a thread. While an impersonation token for a thread is typically sent via an LPC port, a thread with Impersonate access to a second thread can directly impersonate the second thread using the NtImpersonateThread() executivecall.

[Synchronize:]
Permission to wait on a thread handle until the thread terminates.

Mapping to Generic Access Rights:

GenericRead: Get\_Context 
Query\_Information 
GenericWrite: Terminate 
Suspend\_Resume 
Alert 
Set\_Context 
Set\_Information 
GenericExecute: Set\_Thread\_Token  
Synchronize 

OBJECT TYPE: Timer

A timer is a synchronization object that is used to record the passage of time. When the specified time has expired, it becomes signaled and threads waiting on the timer are notified.

Managing Subsystem: Executive Object Services

Specific Access Rights:

[Query\_State:]
Permission to read a timer object's state.

[Modify\_State:]
Permission to cancel or set a timer object.

[Synchronize:]
Permission to wait on a timer object.

Mapping to Generic Access Rights:

GenericRead: Query\_State  
GenericWrite: Modify\_State  
GenericExecute: Synchronize  

OBJECT TYPE: Token

Token objects contain the security context of processes or threads and include user and group identifiers and privileges. Tokens can also have default values for owner, group, and DACL. These defaults are used when creating a new object (e.g., if no explicit DACL is provided for a new object, then the default DACL in the token is used). There are two types of token objects: primary and impersonation. Each process has a primary token, and each thread may optionally have an impersonation token.

Managing Subsystem: Security Reference Monitor

Specific Access Rights:

[Assign\_Primary:]
Permission to directly assign a token as a process' primary token. In order to assign a primary token, the caller must also have Set\_Information to the target process and AssignPrimaryToken privilege.

[Duplicate:]
Permission to make a duplicate copy of an impersonation token, or to make an impersonation token from a primary token.

[Impersonate:]
Permission to use a token as an impersonation token.

[Query:]
Permission to read most information about a token.

[Query\_Source:]
Permission to determine the source of an impersonation token.

[Adjust\_Privileges:]
Permission to enable or disable privileges within a token.

[Adjust\_Groups:]
Permission to enable or disable groups within a token.

[Adjust\_Defaults:]
Permission to change the default owner, group, and DACL values associated with a token.

Mapping to Generic Access Rights:

GenericRead: Query 
GenericRead: Query  
GenericWrite: Adjust\_Privileges 
Adjust\_Groups 
Adjust\_Default 
GenericExecute: none  

I/O Subsystem Objects

Unlike all other executive object types, I/O Subsystem objects are all exported to user-mode using a single file object type managed by the Object Manager. In actuality, the file object type represents a number of sub-types of object. For the evaluated configuration of Windows NT, I/O file objects include:

[Devices:]
A device file object can represent many different types of physical and logical devices including serial and parallel ports, disk drives and partitions, removable media devices, keyboard, and so forth. By convention, all device file objects are located in the Device directory or its subdirectories (though it is common to have symbolic links in other directories point to these devices).

[Mailslot:]
A mailslot file object provides a form of unidirectional inter-process communication. Mailslots are provided by Discretionary Access Control principally to support cross-network inter-process communication, but the capability is available in non-networked systems. Mailslots are implemented by the Mailslot File System (MSFS).

[Named Pipe:]
A named pipe file object provides a form of full duplex inter-process communication. A given named pipe can have one or more instances; each of which is a complete duplex IPC channel. Each instance has a server-side (i.e., the creating process) and a client-side. A client connects to an instance by opening the named pipe; if an instance is available then a connection is established and a handle to the client-side of the instance is given to the client. Named pipes are implemented by the Named Pipe File System (NPFS).

[NTFS File:]
NTFS file objects are the only protected file-like objects in the evaluated configuration of Windows NT. NTFS files are implemented by the NT file system (NTFS).

[NTFS Directory:]
NTFS directory objects are also implemented by the NT file system. NTFS directories are analogous to object directories except that they may only be on NT file system managed disk volumes (and likewise, object directories may only be within the Object Manager's global name space). As such, entries in an NTFS directory may only be other NTFS directories or NTFS files.

Specific Access Rights:

Since all the I/O objects are exported as a single file object type, they all share a common set of defined specific access. However, the actual interpretation of a given access right is defined by the file system or device driver responsible for the I/O object. Additionally, not all specific access rights are implemented for each I/O object type. Listed below are the specific access rights defined for the file object type. Included with the description of the access right is the list of I/O objects to which it applies.

[Read\_Data:] device, mailslot, NTFS file, pipe

Permission to read the contents of the object.

[List\_Directory:] NTFS directory

Permission to list the content of an NTFS directory object.

[Write\_Data:] device, mailslot, NTFS file, pipe

Permission to write the contents of the object.

[Add\_File:] NTFS directory

Permission to add NTFS file entries into an NTFS directory object.

[Append\_Data:] NTFS file

Permission to append data to the end of an NTFS file.

[Add\_Subdirectory:] NTFS directory

Permission to add NTFS directory entries into an NTFS directory object.

[Create\_Pipe\_Instance:] pipe

Permission to create new instances of an existing named pipe.

[Read\_Attributes:] device, mailslot, NTFS file, NTFS directory, pipe

Permission to read most attributes of an object, e.g., creation time, last access time, file attribute flags.

[Write\_Attributes:] device, mailslot, NTFS file, NTFS directory, pipe

Permission to modify most attributes of an object, e.g., creation time, last access time, file attribute flags.

[Read\_EA:] NTFS file, NTFS directory

Permission to read any extended attributes associated with an NTFS object. Extended attributes are user-definable attributes which can be used to contain application-specific information. See "NTFS Volume Layout" for more information on NTFS attributes.

[Write\_EA:] NTFS file, NTFS directory

Permission to modify extended attributes associated with an NTFS object.

[Execute:] NTFS file

Permission to have the loader fault the file into memory as an executable object.

[Traverse:] NTFS directory

Permission to perform name look up through the directory. This access right is not considered security relevant and all processes, by default, are given a privilege to bypass Traverse access checking. Traverse access checking is included within Windows NT to support conformance with standards such as POSIX.

[Delete\_Child:] NTFS directory

Permission to remove an entry from an NTFS directory.

[Synchronize:] device, mailslot, NTFS file, NTFS directory, pipe

Permission to wait for completion of an I/O operation.

Mapping to Generic Access Rights:

GenericRead: Read\_Data 
Read\_Attributes  
Read\_EA 
Synchronize  
GenericWrite: Write\_Data  
Write\_Attributes  
Write\_EA  
Append\_Data  
Synchronize  
GenericExecute: Read\_Attributes  
Execute  
Synchronize  

Protected Server Objects

OBJECT TYPE: Desktop

Desktop objects are associated (contained within) a WindowStation object. A desktop object has a number of application-defined attributes (e.g., windows, menus).

The WinLogon Desktop exists at all times. This desktop is used by the WinLogon server for user authentication and is not directly accessible by non-TCB processes. Another desktop object, called the ScreenSaver Desktop, is created when the screen saver is started (and destroyed when it terminates). This desktop is not directly accessible to user processes. A third desktop, called the Application Desktop, is created during system initialization and exists across all logon sessions. It is the only desktop object directly accessible to user processes. Other desktops can be created when CreateDesktop access is granted to a WindowStation object.

Managing Server: Win32 Server

Specific Access Rights:

[CreateWindow:]
Permission to create a new window within a Desktop object.

[CreateMenu:]
Permission to create a new menu within a Desktop object.

[ReadObjects:]
Permission to list window and menu sub-objects within a Desktop object.

[WriteObjects:]
Permission to modify window and menu sub-objects.

[HookControl:]
Permission to establish a hook for another thread, or to establish a server-wide hook. A hook is a means to monitor for certain messages or event (e.g., mouse input) and invoke an application procedure when that event occurs.

[JournalRecord:]
Permission to perform journal recording. A journal records, and allows playback of, keyboard and mouse events.

[JournalPlayback:]
Permission to perform journal playback.

[Enumerate:]
Permission to list all attributes associated with the Desktop object.

Mapping to Generic Access Rights:

GenericRead: ReadObjects  
Enumerate  
GenericWrite: CreateWindow  
CreateMenu  
WriteObjects  
HookControl  
JournalRecord  
JournalPlayback 
GenericExecute: none 

Default Protection:

All three system-defined desktop objects are owned by SYSTEM. When initially created, the default DACL (which is changeable by an authorized user) for all three objects is:

User/Group SID	Access Granted
SYSTEM	GenericAll
Administrators	ReadObjects WriteObjects Enumerate CreateWindow CreateMenu

After a successful interactive logon, the following access right is added to the Application Desktop object only:

User/Group SID	Access Granted
logon SID	GenericAll

The above entry is removed from the Application Desktop object's DACL during the logoff process.

OBJECT TYPE: Event Log

Event logs record certain types of events within the system. Logs are backed by NTFS files; but the DACL on these NTFS files only allow access to the SYSTEM SID (i.e., direct access to the file is available only to protected servers). All other access to log files must go through the Event Logger. There are only three instances of event logs:

• Application log: Used by any user-mode application to record events.

• System log: Used by the TCB to record non-security relevant events.

• Security log: Used by the TCB to record security audit events.

Managing Server: Event Logger

Specific Access Rights:

[Logfile\_Read:]
Permission to view the events within a log file.

[Logfile\_Write:]
Permission to obtain a handle to an event log that allows adding events to the log (i.e., to register with the Event Logger for a particular event log file).

[Logfile\_Clear:]
Permission to clear (i.e., truncate) an event logfile.

Mapping to Generic Access Rights:

Unlike most other objects, the interface for event logs does not support specifying a desired access. Rather the access right requested is implicit in the request. Hence, the generic access rights are not meaningful for this object type.

Default Protection:

Each of the three instances of the event log object type has a pre-defined DACL which is created by the Event Logger when the object is created. All three log objects are owned by SYSTEM.

The pre-defined DACL for each log file are listed below.

These DACLs cannot be changed.

Log File	User/Group SID	Access Granted
Security	SYSTEM Administrators	Read, Write, Clear Read, Clear
System	SYSTEM Administrators ServerOperator Everyone	Read, Write, Clear Read, Clear Read, Clear Read
Application	SYSTEM Administrators ServerOperator Everyone	Read, Write, Clear Read, Write, Clear Read, Write, Clear Read, Write

In addition, the Security privilege gives all access to the Security event log.

OBJECT TYPE: LsaAccount

An LsaAccount object assigns privileges, system access capability (e.g., interactive, network logon), and special (i.e., non-default) memory quotas for individual users, or local and global group accounts.

Managing Server: Local Security Authority

Specific Access Rights:

[View:]
Permission to read information within the LsaAccount object to include assigned privileges, memory quotas, system access capabilities.

[Adjust\_Privileges:]
Permission to assign or remove privileges from an LsaAccount.

[Adjust\_Quotas:]
Permission to change memory quotas.

[Adjust\_System\_Access:]
Permission to change the type of system access allowed to the user, group, or alias represented by an LsaAccount.

Mapping to Generic Access Rights:

GenericRead: View  
GenericWrite: Adjust\_Privileges  
Adjust\_Quotas  
Adjust\_System\_Access  
GenericExecute: none 

Default Protection: (Refs.: LSA Spec and code)

The default owner for all newly created objects of this type is Administrators.

New instances of the LsaAccount object have the following pre-defined default DACL.

This DACL can be changed by authorized users.

User/Group SID	Access Granted
Administrators	GenericAll
Everyone	GenericExecute

OBJECT TYPE: LsaDomain (also known as Trusted Domain)

An LsaDomain object represents a domain, or more specifically the controller of a domain, to which the local system will trust in providing user authentication. This object is most meaningful in a network configuration, but the object type is available in a stand-alone system.

Managing Server: Local Security Authority

Specific Access Rights:

[Query\_Domain\_Name:]
Permission to determine the account name associated with a trusted domain that should be used for authentication requests.

[Query\_Controllers:]
Permission determine the list of controller systems for a given domain.

[Set\_Controllers:]
Permission to change the list of controllers associated with a domain.

[Query\_POSIX:]
Permission to obtain the POSIX offset associated with a domain, which is necessary to create a POSIX-compliant 32-bit representation of a SID\@.

[Set\_POSIX:]
Permission to change the POSIX offset associated with a domain.

Mapping to Generic Access Rights:

GenericRead: Query\_Account\_Name  
GenericWrite: Set\_Controllers  
Set\_POSIX  
GenericExecute: Query\_Controllers  
Query\_POSIX 

Default Protection:

The default owner for all newly created objects of this type is Administrators.

New instances of this object type have the following pre-defined default DACL.

This DACL can be changed by authorized users.

User/Group SID	Access Granted
Administrators	GenericAll
Everyone	GenericExecute

OBJECT TYPE: LsaPolicy

The LsaPolicy object controls access to the LSA server itself, and also controls access to certain system-wide security information (e.g., information about special domains, the system-wide auditing policy, and the default memory quota assigned to all users). There is exactly one instance of an LsaPolicy object per Windows NT system. An LsaPolicy object can neither be created nor destroyed.

Managing Server: Local Security Authority

Specific Access Rights:

[View\_Local\_Information:]
Permission to read most security information (e.g., default auditing policy, memory quota), and to enumerate the accounts, domains, and privileges known to LSA.

[Get\_Private\_Information:]
Permission to read the names of accounts established for trust relationships. Trust relationship are only important in networked systems.

[Trust\_Admin:]
Permission to change the Account and Primary Domain, and to add new trust relationships.

[Set\_Default\_Quota\_Limits:]
Permission to change the default memory quota.

[Create\_Secret:]
Permission to create a new LsaSecret object instance.

[Create\_Account:]
Permission to create a new LsaAccount object instance.

[Set\_Audit\_Requirements:]
Permission to configure the audit policy to include turning on or off system-wide auditing, and determining which type of audit events should be collected.

[Audit\_Log\_Admin:]
Permission to manipulate the audit log including its maximize size and retention period, and to clear the audit log of all events.

[View\_Audit\_Information:]
Permission to view the audit policy configuration, and the audit log.

[Server\_Admin:]
Permission to change certain state information for the LSA server (e.g., whether it is the primary or backup server).

[Lookup\_Names:]
Permission to translate between SIDs and names (e.g., users, groups, aliases, domains).

[Create\_Privilege:]
This right is defined but is not yet implemented. Currently, possession of this right implies no access to an LsaPolicy object.

Mapping to Generic Access Rights:

GenericRead: View\_Audit\_Information 
Get\_Private\_Information 
GenericWrite: Trust\_Admin 
Create\_Account 
Create\_Secret 
Create\_Privilege  
Set\_Default\_Quota\_Limits  
Set\_Audit\_Requirements  
Audit\_Log\_Admin  
Server\_Admin  
GenericExecute: View\_Local\_Information 
Lookup\_Names 

Default Protection:

The default owner for the LsaPolicy object is Administrators. The LsaPolicy object has the following pre-defined default DACL. This DACL can be changed by authorized users.

User/Group SID	Access Granted
Administrators	GenericAll
Everyone	GenericExecute

OBJECT TYPE: LsaSecret

LsaSecret objects are used to store encrypted data. One of their primary uses is for passwords. The API for LsaSecret objects is not published (due to export control concerns), but is available at the TCB interface.

Managing Server: Local Security Authority

Specific Access Rights:

[Query\_Value:]
Permission to obtain the clear-text contents of an LsaSecret object.

[Set\_Value:]
Permission to change the contents (via an encryption function) of an LsaSecret object.

Mapping to Generic Access Rights:

GenericRead: Query\_Value  
GenericWrite: Set\_Value  
GenericExecute: none 

Default Protection:

The default owner for all newly created objects of this type is Administrators.

New instances of this object type have the following pre-defined default DACL.

This DACL can be changed by authorized users.

User/Group SID	Access Granted
Administrators	GenericAll
Everyone	GenericExecute

OBJECT TYPE: SamAlias (also known as a Local Group)

A SamAlias object associates a set of user and group SIDs in a single identifier. An alias is analogous to a group, expect that it can include group SIDs as well as user SIDs, and in networked system, can include users and groups from different domains.

Managing Server: Security Accounts Manager

Specific Access Rights:

[Add\_Member:]
Permission to add a user or group to an existing SamAlias object.

[Remove\_Member:]
Permission to remove a user or group from an existing SamAlias object.

[List\_Members:]
Permission to view the users and groups associated with an SamAlias object.

[Read\_Information:]
Permission to read to determine certain information about a SamAlias object (e.g., SID, membership count, description)

[Write\_Account:]
Permission to modify the comment field of a SamAlias object.

Mapping to Generic Access Rights:

GenericRead: List\_Members  
GenericWrite: Write\_Account  
Add\_Member  
Remove\_Member  
GenericExecute: Read\_Information  

Default Protection:

The default owner of all SamAlias objects is Administrators. The DACL for all objects of this type can be changed. The default DACL for the SamAlias object defining the Administrators local group is:

User/Group SID	Access Granted
Administrators	GenericAll
Account operators	GenericAll
World	GenericRead GenericExecute

For the Windows NT Workstation product, any local group (alias) created by a member of the Power User group will have the following default DACL:

User/Group SID	Access Granted
Administrators	GenericAll
Power users	GenericAll
World	GenericRead GenericExecute

All other SamAlias objects will have the following default DACL:

User/Group SID	Access Granted
Administrators	GenericAll
Account operators	GenericAll
World	GenericRead GenericExecute

OBJECT TYPE: SamDomain (also known as Trusted Domain)

A SamDomain object represents all the security-relevant data of a given domain, and serves as a means to protect user and group account information. A SamDomain object also contains domain-wide parameters such as minimum password size.

There are only two instances of a SamDomain object defined: Built-in and Accounts. Built-in contains the SamAccount objects describing the built-in groups (see "Built-in Accounts"). Accounts contains the SamAccount objects describing user accounts and administrator-defined groups.

Managing Server: Security Accounts Manager

Specific Access Rights:

[Read\_Password\_Parameters:]
Permission to view the password parameters (e.g., required password length, password age constraints, password complexity rules) for a domain.

[Write\_Password\_Parameters:]
Permission to change the domain password parameters.

[Read\_Other\_Parameters:]
Permission to view non-password parameters of SAM (e.g., count of user and group accounts, the state and role of the SAM server).

[Write\_Other\_Parameters:]
Permission to change the domain non-password parameters.

[Create\_User:]
Permission to create a new SamUser object in the domain.

[Create\_Group:]
Permission to create a new SamGroup object in the domain.

[Create\_Alias:]
Permission to create a new SamAlias object in the domain.

[Get\_Alias\_Membership:]
Permission to scan all associated SamAlias objects to determine all the local groups to which a given SID is a member.

[List\_Accounts:]
Permission to enumerate the users, groups, and aliases associated with a domain.

[Lookup:]
Permission to translated a SID into a logical name and vice versa.

[Administer\_Server:]
Permission to change the configuration of a domain server (e.g., role, state).

Mapping to Generic Access Rights:

GenericRead: Get\_Alias\_Membership 
Read\_Other\_Parameters 
GenericWrite: Write\_Other\_Parameters 
Write\_Password\_Parameters 
Create\_User 
Create\_Group 
Create\_Alias  
Administer\_Server  
GenericExecute: Read\_Password\_Parameters  
List\_Accounts  
Lookup  

The owner of both Built-in and Account domains is Administrators. The default DACL for both objects can be changed by an authorized user. The initial DACL for the Built-in SamDomain object is:

User/Group SID	Access Granted
Administrators	GenericRead GenericExecute Create\_Alias
World	GenericExecute

The initial DACL for the Account SamDomain object is:

User/Group SID	Access Granted
Administrators	GenericAll
Account Operators	GenericRead GenericExecute Create\_User Create\_Group Create\_Alias
Power Users	GenericExecute GenericExecute Create\_User Create\_Group Create\_Alias
Users	GenericRead GenericExecute Create\_Alias
World	GenericRead GenericExecute

OBJECT TYPE: SamGroup (also known as a Global Group)

A SamGroup object contains all the information necessary to describe a group account. A group account is essentially a separate SID that represents a list of individual user SIDs.

Managing Server: Security Accounts Manager

Specific Access Rights:

[Add\_Member:]
Permission to assign a new user SID to a SamGroup object.

[Remove\_Member:]
Permission to delete a user SID from a SamGroup object.

[List\_Members:]
Permission to list the SIDs that are a member of the global group represented by the SamGroup object.

[Read\_Information:]
Permission to determine certain information about a group (e.g., SID, name, and membership count, attributes).

[Write\_Account:]
Permission to modify the name, comment field, and attributes (e.g., enabled/disabled state) associated with a SamGroup object.

Mapping to Generic Access Rights:

GenericRead: List\_Members  
GenericWrite: Add\_Member  
Write\_Account  
Remove\_Member  
GenericExecute: Read\_Information  

Default Protection:

The default owner of all SamGroup objects is Administrators. The DACL for all objects of this type can be changed.

Any SamGroup object representing a global group that is a member of the Administrators local group (including the Domain Admins built-in global group) will have the following DACL:

User/Group SID	Access Granted
Administrators	GenericAll
World	GenericRead GenericExecute

All other SamAlias objects will have the following default DACL:

User/Group SID	Access Granted
Administrators	GenericAll
Account Operators	GenericAll
World	GenericRead GenericExecute

OBJECT TYPE: SamServer

The SamServer object controls access to the \SAM\ server and certain server-wide configuration parameters. There is exactly one SamServer object instance per Windows NT system.

Managing Server: Security Accounts Manager

Specific Access Rights:

[Server\_Connect:]
Permission to connect to the SAM server for purposes of SAM administration (this access right is not needed to use SAM for authentication or password management).

[Server\_Shutdown:]
Permission to request the SAM server to perform an orderly shutdown.

[Server\_Initialize:]
Permission to cause the SAM server to initialize (or re-initialize) itself.

[Server\_Create\_Domain:]
Permission to create a new SamDomain object. This access right is currently not supported.

[Enumerate\_Domains:]
Permission to list the domains currently serviced by this SAM server. Currently, SAM only supports one domain.

[Lookup\_Domain:]
Permission to translate a logical domain name into a SID.

Mapping to Generic Access Rights:

GenericRead: Server\_Enumerate\_Domains  
GenericWrite: Server\_Shutdown  
Server\_Initialize  
Server\_Create\_Domain  
GenericExecute: Server\_Connect  
Lookup\_Domain  

Default Protection:

The owner of the SamServer object is Administrators. The DACL can be changed by an authorized user.

The SamServer object has the following default DACL:

User/Group SID	Access Granted
Administrators	GenericAll
Everyone	GenericRead GenericExecute

OBJECT TYPE: SamUser

A SamUser object contains all the information necessary to describe a user account (e.g., name, password, home directory, user SID).

Managing Server: Security Accounts Manager

Specific Access Rights:

[Read\_General:]
Permission to determine the user SID, name, primary group SID, and user and administrator comment fields in a SamUser object.

[Read\_Preferences:]
Permission to read a generic parameter field (not used by Windows NT, but available for application use), and country and language preferences associated with a user.

[Write\_Preferences:]
Permission to modify the preference information and the user comment field in a SamUser object.

[Read\_Logon:]
Permission to view information about a user's logon session (e.g., home directory, last logon date, number of active logons, path to logon script, user account expiration date).

[Write\_Account:]
Permission to change most information associated with a user account, to include user name, primary group SID, home directory, logon script path name, administrator comment field, and password.

[Change\_Password:]
Permission to change the password in a SamUser object after demonstrating knowledge of the current password.

[Force\_Password\_Change:]
Permission to change the password in a SamUser object without knowledge of the current password.

[Read\_Group\_Information:]
This access right is currently unused and implies no access to a SamUser object.

[Write\_Group\_Information:]
This access right is currently unused and implies no access to a SamUser object.

Mapping to Generic Access Rights:

GenericRead: Read\_Preferences  
Read\_Logon  
Read\_Account  
List\_Groups  
Read\_Group\_Information  
GenericWrite: Write\_Preferences  
Change\_Password  
GenericExecute: Read\_General 

Default Protection:

The default owner of all SamUser objects is Administrators. The DACL for all objects of this type can be changed.

Any SamUser object representing a user who is a member of the Administrators local group (including the Administrator built-in user account) will have the following DACL:

User/Group SID	Access Granted
Administrators	GenericAll
the user himself	GenericWrite
World	GenericRead GenericExecute

The Guest built-in user account will have the following default DACL:

User/Group SID	Access Granted
Administrators	GenericAll
Account operators	GenericAll
World	deny Change\_Password GenericRead GenericExecute

All other SamUser objects will have the following default DACL:

User/Group SID	Access Granted
Administrators	GenericAll
Account operators	GenericAll
the user himself	GenericWrite
World	GenericRead GenericExecute

OBJECT TYPE: Service

A service object represents a system service (e.g., the Event Logger) currently installed by the Service Controller.

Managing Server: Service Controller

Specific Access Rights:

[Query\_Config:]
Permission to determine the configuration parameters associated with a service object.

[Change\_Config:]
Permission to change the configuration of a service.

[Start:]
Permission to start a service.

[Stop:]
Permission to stop a service.

[Pause\_Continue:]
Permission to pause and continue a service.

[Interrogate:]
Permission to request a service to immediately report its status.

[Query\_Status:]
Permission to query the service for its current status.

[Enumerate\_Dependents:]
Permission to determine all the other services that are dependent on this service (i.e., cannot start without this service being started).

[User\_Define\_Control:]
Permission to send a user-defined control request (i.e., a request that is specific to the service) to the service.

Mapping to Generic Access Rights:

GenericRead: Query\_Config  
Query\_Status  
Enumerate\_Dependents   
Interrogate   
GenericWrite: Change\_Config  
GenericExecute: Start  
Stop  
Pause\_Continue  
User\_Defined\_Control 

Default Protection:

The owner of all service objects is SYSTEM. The DACL for service objects can be changed by an authorized user.

New instances of Service object type have the following default DACL:

User/Group SID	Access Granted
SYSTEM	GenericRead GenericExecute
Administrators	GenericAll
Power Users	GenericRead GenericExecute
Everyone	GenericRead User\_Defined\_Control

OBJECT TYPE: SCManager

An SCManager object represents a database of installed services managed by the Service Controller. It also controls access to the Service Controller server. There is only one instance of a SCManager object: ServicesActive. ServicesActive represents the database of services currently being used by the Service Controller. No other SCManager object instances cannot be created and this one instance cannot be destroyed.

Managing Server: Service Controller

Specific Access Rights:

[Connect:]
Permission to connect to the Service Controller server.

[Create\_Service:]
Permission to create a new service object and add it to the SCManager object database.

[Enumerate\_Services:]
Permission to list the services in the SCManager object database.

[Lock:]
Permission to acquire a lock on the database.

[Query\_Lock\_Status:]
Permission to determine the current lock state of the database.

[Modify\_Boot\_Config:]
Permission to replace the last-known-good configuration with a new configuration.

Mapping to Generic Access Rights:

GenericRead: Enumerate\_Services  
Query\_Lock\_Status  
GenericWrite: Create\_Service  
Modify\_Boot\_Config  
GenericExecute: Connect  
Lock  

Default Protection:

The owner of the SCManager object is SYSTEM. The SCManager object has the following pre-defined DACL. This DACL cannot be changed.

User/Group SID	Access Granted
SYSTEM	GenericRead Connect Modify\_Boot\_Config
Administrators	GenericAll
Everyone	GenericRead Connect

OBJECT TYPE: Print Server

The print server object represents the local Print Spooler. Access to the server object is necessary in order create new printer objects, cause the Spooler to connect to new physical printers, and to include print drivers for a given printer type.

Managing Server: Print Spooler

Specific Access Rights:

[Server\_Access\_Administer:]
Permission to manage the Print Spooler to include creating new printers, defining new form definitions (e.g., 8.5 x 11, A4), and defining new printer port connections.

[Server\_Access\_Enumerate:]
Permission to list global information of the spooler (e.g., currently connected printers, loaded print drivers DLLs).

Mapping to Generic Access Rights:

GenericRead: Server\_Access\_Enumerate  
GenericWrite: Server\_Access\_Administer  
Server\_Access\_Enumerate  
GenericExecute: Server\_Access\_Enumerate 

Default Protection:

The owner and DACL on the Printer Server object is fixed, and cannot be changed. The owner is always the SYSTEM \SID. The DACL, which differs between the Server and Workstation products, is listed below:

For both products:

User/Group SID	Access Granted
SYSTEM	GenericAll
Administrators	GenericAll
Everyone	GenericExecute

For the Server product only:

User/Group SID	Access Granted
Print Operators	GenericAll
Server Operators	GenericAll

For the Workstation product only:

User/Group SID	Access Granted
Power Users	GenericAll

OBJECT TYPE: Print Job

An instance of a print job object represents a document that has been spooled to a printer object. All print job objects are associated with a particular printer object.

Managing Server: Print Spooler

[Job\_Access\_Administer:]
Permission to pause the print job and set other job-specific parameters.

Mapping to Generic Access Rights:

GenericRead: Job\_Access\_Administer  
GenericWrite: Job\_Access\_Administer  
GenericExecute: Job\_Access\_Administer  

Default Protection:

The DACL for job objects is always inherited from the associated printer object. The owner of a job object is always the job creator. The DACL and owner of a print job object, once assigned, cannot be changed.

OBJECT TYPE: Printer

A printer object represents an interface to a printer device and an associated printer queue. Print jobs can be spooled to a print object.

Managing Server: Print Spooler

Specific Access Rights:

[Printer\_Access\_Administer:]
Permission to manage a printer (e.g., renaming the printer, connecting to a printer port, pausing the printer, changing the default parameters).

[Printer\_Access\_Use:]
Permission to spool a job to a printer, and to read the printer's default parameters.

Mapping to Generic Access Rights:

GenericRead: Printer\_Access\_Use 
GenericWrite: Printer\_Access\_Use 
GenericExecute: Printer\_Access\_Use 

Default Protection:

There is no fixed default protection for Printers. The DACL and owner for printer objects are determined as for executive objects.

OBJECT TYPE: WindowStation

A WindowStation object includes certain attributes and contains Desktop objects. There is one WindowStation object assigned to the system's interactive user (there is only one interactive user at a time in a \sn\ system). This WindowStation also includes represents access to the monitor, keyboard, and mouse. Other WindowStation objects do not provide access to these devices. Other WindowStation objects are created by TCB services.

Managing Server: Win32 Server

Specific Access Rights:

[AccessClipBoard:]
Permission to read and write the clipboard attribute associated with a WindowStation.

[CreateDesktop:]
Permission to create new Desktop objects within the WindowStation.

The following is no longer true. Currently, only WINLOGON is granted this permission:

[EnumDesktops:]
Permission to list the existing Desktop objects within the WindowStation.

[ReadAttributes:]
Permission to determine certain attributes of the WindowStation such as color settings.

[WriteAttributes:]
Permission to change certain WindowStation attributes.

[AccessGlobalAtoms:]
Permission to read, create, modify, or destroy global atoms (i.e., variables defined within the WindowStation whose contents are cleared after the user logs off).

[Enumerate:]
Permission to list all attributes and objects associated with the WindowStation object.

[ReadScreen:]
Permission to read the current contents of the monitor screen.

[ExitWindows:]
Permission to have the Win32 server to cause a logoff or a system shutdown.

Mapping to Generic Access Rights:

GenericRead: EnumDesktops  
ReadAttributes  
Enumerate  
ReadScreen  
GenericWrite: AccessClipBoard  
CreateDesktop  
WriteAttributes  
GenericExecute: AccessGlobalAtoms  
ExitWindows  

Default Protection:

The owner of the primary WindowStation object is SYSTEM. The DACL associated with this object can be changed by an authorized user. After Win32 and Winlogon initialization, the default DACL for this object is:

User/Group SID	Access Granted
SYSTEM	GenericAll
Administrators	ReadAttributes Enumerate

The WindowStation DACL is also set to the above value after an interactive user logs off the system. After a successful logon, the WindowStation DACL has the following values:

User/Group SID	Access Granted
SYSTEM	GenericAll
logon SID	GenericAll
Administrators	ReadAttributes Enumerate