Security

This topic discusses Windows 2000 security: how you can ensure that data access, storage, and exchange complies with your security needs.

  • Before proceeding, see Checklists.
  • For information on new ways to do familiar security tasks, see New ways to do familiar tasks.
  • For recommendation on how to implement system security, see Best practices.
  • For help with specific tasks, see How to ....
  • For general background information, see Concepts.
  • For troubleshooting information, see Troubleshooting.


Checklists

To get help on specific security administration tasks, see the following:

  • Checklist: Defining a security template for Group Policy
  • Checklist: Defining a security template for a local computer
  • Checklist: Analyzing security
  • Checklist: Configuring system security
  • Checklist: Deploying certification authorities and PKI for an intranet
  • Checklist: Deploying certification authorities and PKI for the Internet
  • Checklist: Creating a certification hierarchy with an offline root certification authority
  • Checklist: Deploying smart cards for logging on to Windows
  • Common tasks for managing security


Common tasks for managing security

The following are common tasks that you do when managing security for a Windows 2000 environment:

Task | Reference
For multi-domain environments, manage trust relationships between domains. | Trust
Delegate administration of domain resources, including Active Directory objects and shares. | Active Directory objects
Manage default groups and create new groups. | Groups
Customize security policies, such as user account policies, user rights policies, and audit policies. | Security Templates overview
Set up public key infrastructure. | Public Key Infrastructure


New Ways to Do Familiar Tasks

This table lists common tasks for managing domain security. For most tasks, the user interface is different in Windows 2000 than in Windows NT 4.0.

If you want to | In Windows NT 4.0 use | In Windows 2000 use
Edit user rights for domain groups and users that apply to domain controllers | User Manager for Domains | Active Directory Users and Computers. For more information, see To define a security template.
Edit account policies for users in a domain | User Manager for Domains | Active Directory Users and Computers. For more information, see To define a security template.
Edit audit policies for groups and users that apply to domain controllers or specific computers | User Manager for Domains | Active Directory Users and Computers. For more information, see To establish an audit policy.
Establish domain trust relationships | User Manager for Domains | Active Directory Domains and Trusts. For more information, see To create an explicit domain trust.
Promote member server to a domain controller | Not available. | Active Directory Installation wizard
Assign permissions to files, folders, and registry keys | Appropriate object manager and Properties page | Appropriate object manager and Properties page. For more information, see Control access to objects.
Audit security events | User Manager for Domains | Appropriate object manager and Properties page. For more information, see To set, view, change, or remove auditing for a file or folder.
View security log | Event Viewer | Event Viewer. For more information, see To view the security log.
Create users and groups | User Manager for Domains | Active Directory Users and Computers. For more information, see To add a user account and To add a group.
Manage a Windows NT 4.0 domain | User Manager for Domains | User Manager for Domains on Windows 2000


Best Practices

For product support recommendations and tips on managing security, see the following:

  • Best practices for access control
  • Best practices for auditing
  • Best practices for Certificate Services
  • Best practices for Encrypting File System
  • Best practices for security configuration and analysis
  • Best practices for managing security templates


Best practices for access control

Distributed security greatly simplifies the work of assigning rights and permissions across a container tree--hierarchy of containers, groups, users, computers, and other resource objects. To take best advantage of this, apply the following general principles:

  • Assign user rights on a group basis.
  • Rely on inheritance from group assignments. Because it is inefficient to maintain user accounts directly, assigning rights on a user basis should be the exception.
  • Assign rights as high in the container tree as possible. By doing this, you gain the greatest breadth of effect with the least effort. The rights you establish should be adequate for the majority of the security principals.
  • Apply inheritance to propagate rights through the container tree. Just as applying access control from a higher level of the tree provides breadth of scope, inheritance provides the depth. You can quickly and effectively apply access control settings to all children of a parent object.
  • Delegate the administration of containers to the administrators that manage the computers where those containers reside. By delegating authority to administer the rights for a container, you can decentralize administrative operations and issues. This reduces the cost of ownership by distributing administration closer to its point of service.

  • When you deploy Windows 2000 in your organization, you must address the default level of security you should use. The main issue is the installed base of applications you need to support on workstations.

    Windows 2000 defines three levels of security for clean-installed systems – Users, Power Users, and Administrators. By default, all end-users are members of the Users group, which is fine if you are only going to run certified Windows 2000 applications. However, if you need to support applications that have not been certified for Windows 2000, then you must do one of the following:

    • Make all of your end users Power Users rather than Users.
    • Modify the default security settings to increase the privileges granted to Users.

    Either of these steps can be implemented as part of an overall security policy or can be applied to individual computers as part of the setup process. A security template is provided with Windows 2000 Server that "opens up" the proper security levels for Users. The template is systemroot\security\templates\compatws.inf

    There are additional issues with computers that have been upgraded to Windows 2000 Server from Windows NT:

    1. Security is not modified during the upgrade, so applications not certified for WIndows 2000 should continue to run without modification after the upgrade.
    2. If you want the upgraded computer to use the new Windows 2000 security defaults, the Windows 2000 default security settings are supplied in systemroot\security\templates\basicwk.inf.


Best practices for auditing

To minimize the risk of security threats, there are a number of auditing steps you can take. The following table lists various events that you should audit, as well as the specific security threat that the audit event monitors.

Audit Event | Potential Threat
Failure audit for logon/logoff | Random password hack
Success audit for logon/logoff | Stolen password break-in
Success audit for user rights, user and group management, security change policies, restart, shutdown, and system events | Misuse of privileges
Success and failure audit for file-access and object-access events. File Manager success and failure audit of Read/Write access by suspect users or groups for the sensitive files. | Improper access to sensitive files
Success and failure audit for file-access printers and object-access events. Print Manager success and failure audit of print access by suspect users or groups for the printers. | Improper access to printers
Success and failure write access auditing for program files (.EXE and .DLL extensions). Success and failure auditing for process tracking. Run suspect programs; examine security log for unexpected attempts to modify program files or create unexpected processes. Run only when actively monitoring the system log. | Virus outbreak


Best practices

Users working with encrypted files and folders should keep the following information and recommendations in mind.

Important EFS Information

The following information is important for users when encrypting or decrypting files.

  • Only files and folders on NTFS volumes can be encrypted.
  • Only the user who encrypted the file can open it.
  • Users cannot share encrypted files.
  • Encrypted files can become decrypted if the user copies or moves the file to a FAT volume.
  • Users must use copying and pasting to retain encryption when moving files into an encrypted folder. If using a drag-and-drop operation to move the files, files are not automatically encrypted in the new folder.
  • System files and compressed files cannot be encrypted.
  • Encrypting a folder or file does not protect against deletion. Anyone with delete permission can delete encrypted folders or files.
  • Temporary files, which are created by some programs when documents are edited, are also encrypted as long as all the files are on an NTFS volume and in an encrypted folder.
  • Users can encrypt or decrypt files and folders located on a remote computer that has been enabled for remote encryption.
  • Data that is transferred over the network is not encrypted during the transfer. Other protocols, such as SSL/PCT or IPSec must be used to encrypt data over the wire.
  • A recovery policy is automatically implemented when users encrypt a file or folder for the first time. This ensures that users who lose their file encryption certificates and associated private keys are able to use a recovery agent to decrypt their files.

Important

  • When attempting to use EFS on any Windows NT partition, Windows 2000 performs a checkdisk operation, which upgrades the partition to Windows 2000 format.

EFS Recommendations

The following practices are recommended for users when encrypting or decrypting files.

  • Users should encrypt the My Documents folder if this is where they save most of their documents. This ensures that their personal documents are encrypted by default.
  • Users should encrypt their Temp folder, so that any temporary files created by programs are automatically encrypted.
  • Users should encrypt folders instead of individual files so that, if a program creates temporary files during editing, these will be encrypted as well.
  • The designated recovery agent should export the data recovery certificate, secure it in a safe place, and delete the data recovery certificate from the system hard disk. In this way, the only person who can recover data for the system is the person who has physical access to the data recovery certificate.

When data recovery must be done, the recovery agent can obtain the data recovery certificate from the safe storage location and import the certificate back into the system. With the data recovery certificate on the system, the recovery agent can perform the recovery of the data from the user's encrypted file. After completing the data recovery task, the recovery agent should again delete the data recovery certificate from the system. (You need not re-export the certificate; you can import the certificate over and over again.)


How to ...

  • Log on to a domain controller as a non-administrative user
  • Use the Run as command to start a program as an administrator
  • Authenticate with smart cards
  • Control access to objects
  • Audit events
  • Manage on-disk data encryption
  • Manage Certificates
  • Manage Certificate Services
  • Manage Security Templates
  • Utilizing Security Configuration and Analysis
  • Automating security configuration tasks


Log on to a Domain Controller as a Non-administrative User

To log on to a domain controller as a non-administrative user

  1. Open Active Directory Users and Computers.
  2. In the console tree, click User Rights.

    3. Where?

    • Group Policy
    • Windows Settings
    • Security Settings
    • Local Policies
    • User Rights
  3. Specify the user name.

Notes

  • To open Active Directory Users and Computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • Before you can change the policy for user rights, the Group Policy snap-in and must be installed on your computer.


Authenticate with smart cards

  • Install a smart card reader on a computer
  • Log on to a computer with a smart card
  • Administer smart cards


Control Access to Objects

  • Set, view, change, or remove file or folder permissions
  • Set, view, change, or remove permissions for a shared folder or drive
  • Take ownership of a file or folder
  • Delegate control to a child domain or organizational unit


Delegate control to a child domain or organizational unit

To delegate control to a child domain or organizational unit

  1. Open Active Directory Users and Computers.
  2. In the console tree, expand the domain object to display the child domains or organizational units.
  3. Right-click the child domain or organizational unit to which you want to delegate administration, then click Delegate Control.
  4. Complete the instructions in the Delegation of Control wizard.

Note

  • To open Active Directory Users and Computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

Related Topics


Audit Events

  • Establish an auditing policy
  • Set, view, change, or remove auditing for a file or folder
  • View the security log


Establish an audit policy

To establish an audit policy

  1. Open Computer Management.
  2. In the console tree, click Audit Policy.

    Where?

    • System Tools
    • Group Policy
    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Local Policies
    • Audit Policy
  3. In the details pane, select those categories of events that you would like to audit.

Note


View the security log

To view the security log

  1. Open Computer Management.
  2. In the console tree, click Event Viewer.

    Where?

    • System Tools
    • Group Policy
    • Computer Configuration
    • Event Viewer
  3. Double-click Security Log.
  4. In the details pane, examine the list of audit events.

Note


Manage on-disk data encryption

  • Designate a remote server for file encryption
  • Encrypt or decrypt files
  • Copy, move, or rename files or folders
  • Recover files or folders


Designate a remote server for file encryption

To designate a remote server for file encryption

  1. Open Active Directory Users and Computers.
  2. Locate the remote server name.
  3. Right-click on the remote server name, then click Properties.
  4. Select the Trusted for Delegation check box.

Note

  • To open Active Directory Users and Computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.


Encrypt or Decrypt Files

  • Encrypt a file or folder
  • Decrypt a file or folder
  • Encrypt a file or folder on a remote computer


Copy, move, or rename encrypted files or folders

  • Copy an encrypted file or folder
  • Move an encrypted file or folder
  • Move or restore encrypted files or folder to a different computer
  • Change the name of an encrypted file or folder


Recover files or folders

  • Recover an encrypted file or folder if you are a designated recover agent
  • Recover an encrypted file or folder when your file encryption certificate is not available
  • Back up default recovery keys to a floppy disk
  • Add a recovery agent for a domain
  • Change the recovery policy for a domain


Add a recovery agent for a domain

To add a recovery agent for a domain

  1. Open Active Directory Users and Computers.
  2. Right-click the domain whose recovery policy you wish to change and click Properties.
  3. Click the recovery policy you wish to change and click Edit.
  4. In the console tree, click Encrypted Data Recovery Agents.

    5. Where?

    • Computer Configuration
    • Windows Settings
    • Public Key Policies
    • Encrypted Data Recovery Agents
  5. Right-click in the details pane, click Add, and follow the instructions that are given.

Notes

  • You must be logged on as an administrator to add a recovery agent.
  • To open Active Directory Users and Computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • Adding a recovery agent from a file identifies the user as USER_UNKNOWN.
  • Before you can add or create a recovery agent, the Group Policy snap-in and its Public Key Policies extension must be installed on your computer. For more information about using Group Policy, see Related Topics.

Related Topics


Change the recovery policy for a domain

To change the recovery policy for a domain

  1. Open Active Directory Users and Computers.
  2. Right-click the domain whose recovery policy you wish to change and click Properties.
  3. Click the recovery policy you wish to change and click Edit.
  4. In the console tree, click Encrypted Data Recovery Agents.

    5. Where?

    • Computer Configuration
    • Windows Settings
    • Public Key Policies
    • Encrypted Data Recovery Agents
  5. Right-click in the details pane and click the appropriate action you wish to take.

Notes

  • You must be logged on as an administrator to change the recovery policy.
  • To open Active Directory Users and Computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
    • You can right-click Encrypted Data Recovery Agents to see the changes you can make.
  • The computer issues a default self-signed certificate that designates the local administrator as the default recovery agent. If you delete this certificate without another policy in place, the computer has an empty recovery policy. An empty recovery policy means that no one is a recovery agent. This turns Encrypted File System (EFS) off, so users cannot encrypt files on computers.
  • Before changing the recovery policy in any way, you should first secure the recovery keys.
  • In a domain, a default recovery policy is implemented for the domain when the first domain controller is set up. The domain administrator is issued the self-signed certificate, which designates the domain administrator as the recovery agent. To change the default recovery policy for a domain, log on to the first domain controller as an administrator.

Related Topics


Manage Certificates

  • Add the Certificates Snap-in to the MMC Console
  • Set display options in of the Certificates snap-in
  • Request Certificates
  • Manage an individual certificate
  • Import and export certificates
  • Use Certificate Services Web pages


Manage Certificate Services

  • Set up a certification authority
  • Administer a certification authority
  • Establish public key policies for Group Policy objects


Establish public key policies for Group Policy objects

  • Add a trusted root certification authority to a Group Policy object
  • Delete a trusted root certification authority from a Group Policy object
  • Create an automatic certificate request for computers in a Group Policy object
  • Delete an automatic certificate request for computers in a Group Policy object
  • Create a certificate trust list for a Group Policy object
  • Edit a certificate trust list for a Group Policy object
  • Delete a certificate trust list for a Group Policy object
  • Add an encrypted recovery agent for a local computer
  • Add an encrypted data recovery agent for a Group Policy object
  • Change the encrypted data recovery policy for the local computer


Manage Security Templates

  • Start security templates
  • Customize a predefined security template
  • Define a security template
  • Delete a security template
  • Refresh the security template list
  • Set a description for a security template
  • Apply a security template to a local computer
  • Import a security template to Group Policy
  • View effective security settings


Utilizing Security Configuration and Analysis

  • Start Security Configuration and Analysis
  • Set a working database
  • Import a security template
  • Analyze system security
  • Review security analysis results
  • Configure system security
  • Edit the base security configuration
  • View effective security settings
  • Export a security template


Concepts

This section provides information about securing data for your organization or on your local computer.

  • Security overview
  • Understanding security
  • Using security
  • Resources


Security overview

Before you can begin to plan and implement security for your computing environment, you should familiarize yourself with some basic Windows 2000 security concepts. These concepts are:

  • New security features
  • Security model
  • Domain architecture
  • Authentication
  • Authorization
  • Auditing
  • Security policies
  • Trust
  • Data protection
  • Public key infrastructure

For more information, see the Microsoft Security Advisor Web site (http://www.microsoft.com/).


New security features

Before setting up and managing security on a Windows 2000 system, it is helpful to understand the benefits of securing your computing environment, and the new features that Windows 2000 offers to users and administrators.

Security Benefits

Implementing security in your computing environment provides several important benefits:

First, a good security system confirms the identity of the people that are attempting to access the resources in your computing environment. This prevents imposters from accessing, stealing, or damaging system resources, such as sensitive data or mission-critical computer programs.

Second, a good security system protects specific resources in the environment from inappropriate access by users. For example, by implementing system security, you can ensure that only corporate management personnel have access to employee payroll information.

Finally, a good security system provides a simple, efficient way to set up and maintain security in your environment. For example, you can set up password policies that can be globally applied to all users within your environment.

Through proper implementation of system security that is tailored for your specific business needs, you can create a computing environment that provides your users with all of the information and resources they need to be successful, while protecting the information and resources from damage and unauthorized access.

Security features

To help you accomplish these goals, Windows 2000 introduces a number of new security features:

  • Central storage of security policy and account information
  • Automatic updating and synchronization of all security policy and account information across domain controllers
  • Per-property access control for objects
  • Transitive trust relationships between domains
  • Multiple authentication mechanisms, for authenticating both internal and external users, including users of Windows NT Version 4.0
  • Common administrative tools to manage access control and account information
  • Smart card support for secure storage of user credentials
  • Encryption for data that is transported over the network or stored on disk.


Security model

The primary features of the Windows 2000 security model are user authentication and access control. To ensure that administrators can manage these features easily and efficiently, Windows 2000 makes use of Active Directory. The following sections describe these features of the security model.

User authentication

The Windows 2000 security model includes the concept of user authentication, which gives users the ability to log on to a system to access network resources. Within this authentication model, the security system provides two types of authentication:

  • Interactive logon, which confirms the user's identification to the user's local computer or Active Directory account.

  • Network authentication, which confirms the user's identification to any network service that the user is attempting to access. To provide this type of authentication, the Windows 2000 security system includes three different authentication mechanisms: Kerberos V5, public key certificates, and NTLM (for compatibility with Windows 2000 4.0 systems).

For more information, see Authentication.

Object-based access control

Along with user authentication, Windows 2000 allows administrators to control access to resources, or objects, on the network. Windows 2000 implements access control by allowing administrators to assign security descriptors to objects stored in Active Directory. A security descriptor lists the users and groups that are granted access to an object, and the specific permissions assigned to those users and groups. A security descriptor also specifies the various access events to be audited for an object. Examples of objects are files, printers, and services. By managing properties on objects, administrators can set permissions, assign ownership, and monitor user access.

Not only can administrators control access to a specific object, they can also control access to a specific attribute of that object. For example, through proper configuration of an object's security descriptor , a user could be allowed to access a subset of information, such as employees' names and phone numbers but not their home addresses.

For more information, see Authorization.

Active Directory and Security

Active Directory provides protected storage of user account and group information by using access control on objects and user credentials. Because Active Directory stores not only user credentials but also access control information, users who log on to the network obtain both authentication and authorization to access system resources.

For example, when a user logs on to the network, the Windows 2000 security system authenticates the user with information stored in the Active Directory. Then, when the user attempts to access a service on the network, the system checks the properties defined in the discretionary access control list (DACL) for that service.

Because Active Directory allows administrators to create group accounts, administrators can manage system security more efficiently. For example, by adjusting a file's properties, an administrator can permit all users in a group to read that file. In this way, access to objects in Active Directory is based on group membership.

Other Security Factors

In addition to authentication and access control, there are other important aspects of the Windows 2000 security model. For more information, see Security policies, Auditing, Data protection, Trust, and Public key infrastructure.


Domain architecture

Understanding and using domains in your security administration will make your job much easier. This section provides a basic understanding of how you can implement domains in your environment.

Domains and security

A domain is a grouping of network objects, such as users, groups, and computers. All objects in a domain are stored in Active Directory. Active Directory can reside on one or more domain controllers within a domain.

Each domain is a security boundary, meaning that security policies and settings (such as administrative rights, security policies, and access control lists) do not cross from one domain to another. The administrator of a particular domain has rights to set policies within that domain only.

Because a domain is a security boundary, different administrators can create and manage different domains in your organization.

Some key points to understand about domains are:
  • Security policy can be implemented throughout a domain.
  • Active Directory, which includes security information, is replicated at regular intervals to each domain controller in the domain, so that databases are always synchronized.
  • Objects in Active Directory can be organized and managed at the organizational unit level.
  • Transitive trust relationships can be established between domains in a domain tree.

For more information on domains, see Understanding Domains.

Single vs. multiple domains

Windows NT 4.0 limited the number of user accounts that a directory could store. Thus, to accommodate large computing environments, organizations found it necessary to create and manage several domains, each with its own directory of user accounts. Domains were typically organized into two types: master domains (which stored user and group accounts) and resource domains (which stored files, printers, application services, and so on).

This multiple-domain computing environment was known as a multi-master domain model. A multi-master domain model meant that resource domains needed multiple trust relationships with all master domains. These trust relationships allowed users in master domains to access resources in resource domains.

Active Directory replaces the need for multiple domains by scaling to a large capacity to store user, group, and computer accounts. With Active Directory, administrators can consolidate all accounts (which formerly had to be stored on master domains) and all resources (which formerly had to be stored on resource domains) across domains into a single domain. Then, to maintain logical groupings of objects for administrative purposes, administrators can group objects into organizational units (OUs) within the domain. In some cases, however, you might want to retain multiple domains, for policy reasons.

Transitive trust relationships

When you move objects from multiple domains into a single domain, you lower the number of domain trust relationships you must establish and maintain. Also, when you join domains together into a single domain forest, those domains automatically have transitive trust relationships, which reduces the number of trust relationships that need to be manually established between domains. Each domain requires only one trust relationship with another domain in the forest to have access to all other domains in the domain forest.

For more information on managing trust relationships, see Trust.

Server roles

Servers within a domain function in one of two roles:

  • Domain controllers, which run Active Directory and provide authentication and policies
  • Member servers, which provide services, such as file, print, and application services

For more information on domain controllers and member servers, see Server Roles.


Authentication

Authentication is a fundamental aspect of system security. It confirms the identity of any user trying to log on to a domain or access network resources. Windows 2000 authentication enables single sign-on to all network resources. With single sign-on, a user can log on to the domain once, using a single password or smart card, and authenticate to any computer in the domain.

Authentication processes

Successful user authentication in a Windows 2000 computing environment consists of two separate processes: interactive logon, which confirms the user's identification to either a domain account or a local computer, and network authentication, which confirms the user's identification to any network service that the user attempts to access.

Authentication types

Windows 2000 supports several industry-standard types of authentication. When attempting to authenticate a user, Windows 2000 uses different types of authentication, depending on a variety of factors. The types of authentication that Windows 2000 supports are:

Authentication Type | Description
Kerberos V5 authentication | Used with either a password or a smart card for interactive logon. It is also the default method of network authentication for services.
Secure Sockets Layer/Transport Layer Security (SSL/TLS) authentication | Used when a user attempts to access a secure Web server.
NTLM authentication | Used when either the client or server uses a previous version of Windows.

For more information on authentication types, see Authentication mechanisms.


Authorization

Windows 2000 security is based on two fundamental concepts: authentication and authorization. Access control is the model for implementing authorization. Once a user account has received authentication and can access an object, the type of access granted is determined by either the user rights that are assigned to the user or the permissions that are attached to the object. For objects within a domain, the object manager for that object type enforces access control. For example, the registry enforces access control on registry keys.

Every object controlled by an object manager has an owner, a set of permissions that apply to specific users or groups, and auditing information. By setting the permissions on an object, the owner of the object controls which users and groups on the network are allowed to access the object. The permission settings also define what type of access is allowed (such as read/write permission for a file). The auditing information defines which users or groups are audited when attempting to access that object.

For more information on access control, see Access Control.


Auditing

Security auditing is a feature of Windows 2000 that monitors various security-related events. Monitoring system events is necessary to detect intruders and to detect attempts to compromise data on the system. An example of an event that can be audited is a failed logon attempt.

The most common types of events to be audited are:

  • Access to objects, such as files and folders
  • Management of user and group accounts
  • When users log on to and log off of the system

In addition to auditing security-related events, Windows 2000 generates a security log and provides a way for you view the security events reported in the log.

Finally, the Windows 2000 auditing feature generates an audit trail to help you keep track of all security administration events that occur on the system. For example, if an administrator changes the auditing policy so that failed logon attempts are no longer audited, the audit trail will show this event.

For more information on auditing, see Auditing security events.


Security policies

Security settings define the security-relevant behavior of the system. Through the use of Group Policy objects in the Active Directory, administrators can centrally apply the security levels required to protect enterprise systems.

When determining settings for a Group Policy object that contains multiple computers, the organizational and functional character of that given site, domain, or organizational unit must be considered. For example, the security levels necessary for an organizational unit containing computers in a sales department would be very different from that for an organizational unit containing finance department computers.

Security settings

The term security settings is interchangeable with security configuration. Security settings include Security Policies (account and local policies), access control (services, files, registry), event log, group membership (restricted groups), Internet Protocol security Security policies, and Public Key policies.

Security templates

A security template is a physical representation of a security configuration: a file where a group of security settings may be stored. Windows 2000 includes a set of security templates, each based on the role of a computer: from security settings for low security domain clients to highly secure domain controllers. These templates can be used as provided, modified, or serve as a basis for creating custom security templates.

Security configuration tools

To define and use security templates, administrators use the Security Templates snap-in.

To configure and analyze security locally, administrators use the Security Configuration and Analysis snap-in.

To configure security centrally in Active Directory, administrators use the Group Policy snap-in.


Trust

Windows 2000 supports two types of trust: Domain trust and certificate authority (CA) trust.

Domain trust allows a user to authenticate to resources in another domain. Also, an administrator is able to administer user rights for users in the other domain. For more information on establishing and managing domain trust relationships, see Understanding domain trusts.

CA trust allows you to trust certificates issued by another certificate authority. For more information on certificate authorities, see Public-key infrastructure.


Data protection

Data privacy and integrity begin with network authentication. With proper credentials (either a strong password or public-key credentials), a user can log on to the network and, in the process, obtain permission to access stored data.

Windows 2000 supports two types of data protection--stored data and network data. The following sections describe these types of protection.

Stored data protection

Stored data (online or offline) can be protected using:

  • Encrypting File System (EFS). EFS uses public key encryption to encrypt local NTFS data.
  • Digital signatures. Digital signatures sign software components, ensuring their validity.

Network data protection

Network data within your site (local network and subnets) is secured by the authentication protocol. For an additional level of security, you can also choose to encrypt network data within a site. Using Internet Protocol security, you can encrypt all network communication for specific clients, or for all clients in a domain.

Network data passing in and out of your site (across intranets, extranets, or an Internet gateway) can be secured using the following utilities:

  • Internet Protocol Security. Encrypts all TCP/IP communication for a client.
  • Routing and Remote Access. Configures remote access protocols and routing.
  • Proxy Server. Provides a firewall and proxy server for a site.

In addition, programs such as Microsoft Exchange, Microsoft Outlook, and Microsoft Internet Explorer provide public key encryption of messages and transactions either within a site or across networks.

For more information, see Stored data security and Network layer security.


Public key infrastructure

Computer networks are no longer closed systems in which a user's mere presence on the network can serve as proof of identity. In this age of information interconnection, an organization's network may consist of intranets, Internet sites, and extranets--all of which are potentially susceptible to access by unauthorized individuals who intend to maliciously view or alter an organization's digital information assets.

There are many potential opportunities for unauthorized access to information on networks. A person can attempt to monitor or alter information streams such as e-mail, electronic commerce transactions, and file transfers. Your organization may work with partners on projects of limited scope and duration, with employees whom you know nothing about, but who, nonetheless, must be given access to some of your information resources. If your users have a multitude of passwords to remember for accessing different secure systems, they may choose weak or common passwords to more easily remember them. This not only provides a hacker with a password that is easy to crack, but also one that will provide access to multiple secure systems and stored data.

How can a system administrator be sure of the identity of a person accessing information and, given that identity, control which information that person has access to? Additionally, how can a system administrator easily and securely distribute and manage identification credentials across an organization? These are issues that can be addressed with a well-planned public key infrastructure.

A public key infrastructure, often shortened to PKI, is a system of digital certificates, certification authorities (CAs) and other registration authorities that verify and authenticate the validity of each party involved in an electronic transaction through the use of public key cryptography. Standards for public key infrastructure (PKI) are still evolving even as they are being widely implemented as a necessary element of electronic commerce. For detailed information about planning a PKI and and using public key cryptography, refer to the resources listed on Resources: Public Key Infrastructure

There are a number of reasons why an organization may choose to deploy a PKI using Windows 2000:

  • Strong security . You can have strong authentication with smart cards. You can also maintain confidentiality and the integrity of transmitted data on public networks by using Internet Protocol security and the confidentially of stored data using EFS (encrypting file system). Additionally, an administrator can use security permissions in Windows 2000 to determine what certificates can be issued to which users.

  • Simplified administration. Your organization can issue certificates instead of passwords. You can revoke certificates as necessary and publish certificate revocation lists (CRLs). There is also large scalability for managing trust relationships across enterprises. You can also take advantage of Certificate Services integration with Active Directory and Group Policy The capability to map certificates to user accounts in Active Directory or via Internet Information Services is also provided in Windows 2000.

  • New opportunities. You can exchange files and data securely over public networks, such as the Internet. You have the ability to implement secure e-mail using S/MIME (Secure Multipurpose Internet Mail Extensions) and secure Web connections using Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

    And, as an important element of electronic commerce, you can establish nonrepudiation by the use of digital signatures.

Windows 2000 features to help your organization implement a public key infrastructure include:

  • Certificates. A certificate is basically a digital statement issued by an authority that vouches for the identity of the certificate holder. A certificate binds a public key to the identity of the person, computer, or service who holds the corresponding private key. Certificates are used by a variety of public key security services and applications that provide authentication, data integrity and secure communications across networks such as the Internet.

    The standard certificate format used by Windows 2000 certificate-based processes is X.509v3. An X.509 certificate includes information about the person or entity to whom the certificate is issued, information about the certificate, plus optional information about the certification authority issuing the certificate. Subject information may include the entity's name, the public key, the public-key algorithm, and an optional unique subject ID. Standard extensions for version 3 certificates accommodate information related to key identifiers, key usage, certificate policy, alternate names and attributes, certification path constraints, and enhancements for certificate revocation including revocation reasons and CRL partitioning by CA renewal.

    Users can manage certificates using the Certificates MMC console. For more information see Certificates overview

  • Certificate Services on Windows 2000 Server. Certificate Services is the component in Windows 2000 used to create and manage certification authorities (CAs). A CA is responsible for establishing and vouching for the identity of certificate holders. A CA also revokes certificates if they should no longer be considered valid and publishes certificate revocation lists (CRLs) to be used by certificate verifiers. The simplest PKI design has only one root CA. In practice, however, the majority of organizations deploying a PKI will use a number of CAs, organized into trusted groups known as certification hierarchies.

    A separate component of Certificate Services is the CA Web enrollment pages. These Web pages are installed by default when you set up a CA and allow certificate requesters the ability to submit certificate requests using a Web browser. Additionally, the CA Web pages can be installed on Windows 2000 servers that do not have a certification authority installed. In this case, the Web pages are used to direct certificate requests to a CA that, for whatever reason, you do not want requesters to directly access. If you choose to create custom Web pages for your organization to access a CA, the Web pages provided in Windows 2000 can be used as samples. Refer to the Microsoft Platform Software Development Kit for information about customizing Certificate Services and CA Web pages.

    Users can manage Certificate Services using the Certification Authority MMC console. For more information see Certificate Services overview.

  • Smart Card Support. Windows 2000 supports logon via certificates on smart cards, as well as the use of smart cards to store certificates used for Web authentication, secure e-mail and other public key cryptography-related activities. For more information see Smart Cards.

  • Public Key Policies. You can use Group Policy in Windows 2000 to distribute certificates to computers automatically, establish certificate trusts lists and common trusted certification authorities, as well as managing recovery policies for EFS (Encrypting File System). For more information, see Public Key Policies overview

To get started with deploying a PKI using Windows 2000, see the Certificate Services Checklists


Understanding security

The Windows 2000 security framework is designed to fulfill the most stringent security requirements. However, software alone can quickly become ineffective without careful planning and assessment, effective security guidelines, and user education.

The foundations of your security solution are built upon the following concepts:

  • Server roles
  • Users, groups, and computers
  • Authentication mechanisms
  • Public key infrastructure
  • Security policies
  • User rights
  • Access control
  • Auditing security events
  • Stored data security
  • Network data security
  • Security Configuration and Analysis
  • Managing security templates


Server roles

At any given time, a server in a domain functions as either a domain controller or a member server. Windows 2000 supports the capability to either demote a domain controller to a member server, or to promote a member server to a domain controller, to accommodate the changing needs of your organization.

For more information on the security aspects of domain controllers and member servers, see the following:

  • Domain controller
  • Member server
  • Changing server roles


Domain controllers

Systems that function as servers within a domain can have one of two roles: domain controller or member server.

A domain controller is a Windows 2000 server that is running Active Directory. On a domain controller, Active Directory stores all domainwide account and policy information, such as system and security policies, user authentication data, and directory search. Account information can pertain to user, service, and computer accounts. Due to Active Directory, domain controllers do not require the Security Account Manager (SAM).

A single domain can contain one or more computers configured as domain controllers. For example, a small company using a single local area network may need only one or two domain controllers, while a large company with many network locations will need more domain controllers in each location to provide high availability and fault tolerance.

Administrators can make updates to Active Directory on any Windows 2000 domain controller in the domain. For Windows NT 4.0 backup domain controllers, one of the Windows 2000 domain controllers acts as a primary domain controller to replicate a read-only copy of Active Directory to the Windows NT 4.0 computer.

Because domain controllers store all user account information for a domain, each domain controller should reside in a physically secure environment. Also, only administrators should be allowed to log on interactively to the console of a domain controller.

For more information, see Domain controllers.

For information on member servers, see Member servers.


Member servers

Systems that function as servers within a domain can have one of two roles: domain controller or member server.

A member server is a computer that is:

  • Running Windows 2000 Server
  • A member of a domain
  • Not a domain controller

Because it is not a domain controller, a member server does not perform user authentication and does not store security policy information.

Member servers typically function as the following types of servers:

  • File servers
  • Application servers
  • Database servers
  • Web servers
  • Certificate Services
  • Firewalls
  • Remote access servers

These member server types have a common set of security-related features:

  • Member servers adhere to policies that are defined for the domain and stored in Active Directory.
  • Resources that are available on a member server are configured for access control.
  • Member server users have user rights assigned to them.
  • Member servers contain a local security account database, the Security Account Manager (SAM).

For information on domain controllers, see Domain controllers.


Changing server roles

A server within a domain can function in one of two roles--either as a domain controller or a member server.

As the needs of your computing environment change, you might want to change the role of a server. Using the Active Directory Installation wizard, you can promote a member server to a domain controller, or you can demote a domain controller to a member server.


Users, Computers, and Groups

The users, computers, and groups defined within a domain are managed through Active Directory Users and Computers. From a security perspective, you can view or set the permissions for an Active Directory object, and the users or groups to which these permissions are granted.

Through Active Directory Users and Computers, you can also view or set the auditing events for an object, and the owner of the object.

For more information, see the following:

  • Active Directory user and computer accounts
  • Understanding groups


Authentication mechanisms

To authenticate a user to access a network service, Windows 2000 uses one of several authentication methods. Active Directory can securely store multiple security credentials for any of these authentication methods.

For more information on these authentication methods, see the following:

  • Introduction to authentication
  • Kerberos V5 authentication
  • Secure Sockets Layer/Transport Layer Security (SSL/TLS) authentication
  • NTLM authentication
  • Interoperability with RFC-1510 Kerberos implementations


Introduction to authentication

A key feature of Windows 2000 authentication is its support of single sign-on. Single sign-on allows a user to log on to the domain once, using a single password, and authenticate to any computer in the domain.

Single sign-on provides two main security benefits:

  • For a user, the use of a single password or smart card reduces confusion and improves work efficiency.
  • For administrators, the amount of administrative support required for domain users is reduced, because the administrator only needs to manage one account per user.

Windows 2000 authentication, including single sign-on, is implemented as a two-part process: interactive logon and network authentication. Successful user authentication depends on both of these processes.

Interactive logon

Interactive logon confirms the user's identification to either a domain account or a local computer. This process is different, depending on the type of user account:

  • With a domain account, a user logs on to the network with a password or smart card, using single sign-on credentials stored in Active Directory. By logging in with a domain account, an authorized user can access resources in the domain and any trusting domains. If a password is used to log on to a domain account, Windows 2000 uses Kerberos V5 for authentication. If a smart card is used instead, Windows 2000 uses Kerberos V5 authentication with certificates.
  • With a local computer account, a user logs on to a local computer, using credentials stored in Security Account Manager (SAM), which is the local security account database. Any workstation or member server can store local user accounts, but those accounts can only be used for access to that local computer.

Network authentication

Network authentication confirms the user's identification to any network service that the user is attempting to access. To provide this type of authentication, the Windows 2000 security system supports many different authentication mechanisms, including Kerberos V5, Secure Socket Layer/Transport Layer Security (SSL/TLS), and, for compatibility with Windows NT 4.0, NTLM.

Users using a domain account do not see network authentication . Users using a local computer account, must provide credentials (such as a user name and password) every time they access a network resource. By using the domain account, the user has credentials that can be used for single sign-on.


Kerberos V5 authentication

Kerberos V5 is the primary security protocol for authentication within a domain. The Kerberos V5 protocol verifies both the identity of the user and network services. This dual verification is known as mutual authentication.

How Kerberos V5 works

The Kerberos V5 authentication mechanism issues tickets for accessing network services. These tickets contain encrypted data, including an encrypted password, that confirms the user's identity to the requested service. Except for entering a password or smart card credentials, the entire authentication process is invisible to the user.

An important service within Kerberos V5 is the Key Distribution Center (KDC). The KDC runs on each domain controller as part of Active Directory, which stores all client passwords and other account information.

The Kerberos V5 authentication process works as follows:

  1. The user on a client system, using a password or a smart card, authenticates to the KDC.
  2. The KDC issues a special ticket-granting ticket to the client. The client system uses this TGT to access the ticket-granting service (TGS), which is part of the Kerberos V5 authentication mechanism on the domain controller.
  3. The TGS then issues a service ticket to the client.
  4. The client presents this service ticket to the requested network service. The service ticket proves both the user's identity to the service and the service's identity to the user.

For more information on how Kerberos V5 provides authentication, see the Windows 2000 Resource Kit.

Kerberos V5 and domain controllers

The Kerberos V5 services are installed on each domain controller, and a Kerberos client is installed on each Windows 2000 workstation and server.

Every domain controller acts as a KDC. A Windows 2000 system uses a Domain Name Service (DNS) lookup to locate the nearest available domain controller. That domain controller then functions as the preferred KDC for that user during the user's logon session. If the preferred KDC becomes unavailable, the Windows 2000 system locates an alternate KDC to provide authentication.

Delegation of authentication

Delegation of authentication is a privilege that an administrator can grant to a user or computer account. By default, only domain administrators are assigned this privilege. This privilege must be assigned selectively, to services that can be trusted.

In an N-tier application, the user authenticates to a middle-tier service. The middle-tier service authenticates to a back-end data server on behalf of the user.

Delegation depends on the middle-tier service being trusted for delegation. Trusted for delegation means that that service can impersonate a user to use other network services.

Kerberos V5 interoperability

Windows 2000 supports two types of Kerberos V5 interoperability:

  • A trust relationship can be established between a domain and an MIT-based Kerberos realm. This means that a client in a Kerberos realm can authenticate to an Active Directory domain to access network resources in that domain.
  • Within a domain, UNIX clients and servers can have Active Directory accounts, and therefore obtain authentication from a domain controller.

    • For more information on interoperability between the MIT-based versions of the Kerberos protocol and the Windows 2000 implementation of the Kerberos protocol, see the Windows 2000 Resource Kit.

Note

  • The Group Policy editor user interface, which you use to modify the Kerberos policy for individual user and group accounts, refers to the TGT as a user ticket.


Secure Socket Layer/Transport Layer Security (SSL/TLS) authentication

For conceptual information about certificates and Secure Socket Layer connections and authentication, see About Certificates in the IIS 5.0 Documentation. (http://localhost/iishelp/iis/htm/core/iiabcsc.htm)

For instructions on how to map certificates to user accounts in InterInternetent Information Services (IIS), see Mapping Client Certificates to User Accounts in the IIS 5.0 Documentation. (http://localhost/iishelp/iis/htm/core/iimapsc.htm)

Note

  • You need to have IIS installed to have access to the documentation.


NTLM authentication

In Windows 2000, NTLM is used as the authentication protocol for transactions between two computers in a domain, where one or both computers is running Windows NT 4.0 or earlier.

Windows 2000 is installed in a mixed-mode network configuration by default. A mixed-mode network configuration uses any combination of Windows NT 4.0 and Windows 2000. If you do not have a mixed-mode network, you can disable NTLM authentication by switching to native mode at a domain controller.

As examples, the following configurations would use NTLM as the authentication mechanism:

  • A Windows 2000 Professional client authenticating to a Windows NT 4.0 domain controller.
  • A Windows NT 4.0 Workstation client authenticating to a Windows 2000 domain controller.
  • A Windows NT 4.0 Workstation client authenticating to a Windows NT 4.0 domain controller.
  • Users in a Windows NT 4.0 domain authenticating to a Windows 2000 domain.

In addition, NTLM is the authentication protocol for computers that are not participating in a domain, such as stand-alone servers and workgroups.

For more information about NTLM authentication, see the Windows 2000 Server Resource Kit documentation.


Interoperability with RFC-1510 Kerberos implementations

Kerberos V5 is designed for interoperability with other security services that are based on the RFC-1510 Kerberos reference implementation.

Kerberos V5 interoperates with other RFC-1510 implementations of the Kerberos protocol in the following ways:

  • A Windows 2000 domain controller can provide authentication for client systems running implementations of RFC-1510 Kerberos, including clients running an operating system other than Windows 2000.
  • Windows 2000 Professional systems can authenticate to an RFC-1510 Kerberos server within a realm, with single sign-on to both the server and a local Windows 2000 Professional account.
  • Client applications for Win32 and operating systems other than Windows 2000 that are based on the General Security Service Application Program Interface (GSS API) can obtain session tickets for services within a Windows 2000 domain.

For more information on enabling these interoperability features, see the Windows 2000 Server Resource Kit.


Public Key Infrastructure

For conceptual topics related to public key infrastructure components in Windows 2000, see:

  • Smart cards overview
  • Certificates overview
  • Certificate Services overview
  • Public Key Policies overview


User Rights

User rights grant specific privileges and logon rights to users and groups in your computing environment. For information on user rights, see the following:

  • Introduction to user rights
  • Privileges
  • Logon rights


Introduction to user rights

Administrators can assign specific rights to group accounts or to individual user accounts. These rights authorize users to perform specific actions, such as logging on to a system interactively or backing up files and directories. User rights are different from permissions because user rights apply to user accounts, and permissions are attached to objects. For information on permissions, see How inheritance affects file and folder permissions.

User rights define capabilities at the local level. Although user rights can apply to individual user accounts, user rights are best administered on a group account basis. This ensures that a user logging on as a member of a group automatically inherits the rights associated with that group. By assigning user rights to groups rather than individual users, you simplify the task of user account administration. When users in a group all require the same user rights, you can assign the set of user rights once to the group, rather than repeatedly assigning the same set of user rights to each individual user account.

User rights that are assigned to a group are applied to all members of the group while they remain members. If a user is a member of multiple groups, the user's rights are cumulative, which means that the user has more than one set of rights. The only time that rights assigned to one group might conflict with those assigned to another is in the case of certain logon rights. In general, however, user rights assigned to one group do not conflict with the rights assigned to another group. To remove rights from a user, the administrator simply removes the user from the group. In this case, the user no longer has the rights assigned to that group.

There are two types of user rights: privileges and logon rights.

  • Privilege. An example of a privilege is the right to back up files and directories.
  • Logon right. An example of a logon right is the right to log on to a system locally.

Privileges

The following list shows the privileges that can be assigned to a user. These privileges can be managed with the User Rights policy.

  • Act as Part of the Operating System
  • Add Workstations to a Domain
  • Back Up Files and Directories
  • Bypass Traverse Checking
  • Change the System Time
  • Create a Token Object
  • Create Permanent Shared Objects
  • Create a Pagefile
  • Debug Programs
  • Enable Trusted for Delegation on User and Computer Accounts
  • Force Shutdown from a Remote System
  • Generate Security Audits
  • Increase Quotas
  • Increase Scheduling Priority
  • Load and Unload Device Drivers
  • Lock Pages in Memory
  • Manage Auditing and Security Log
  • Modify Firmware Environment Values
  • Profile a Single Process
  • Profile System Performance
  • Replace a Process-Level Token
  • Restore Files and Directories
  • Shut Down the System
  • Take Ownership of Files or Other Objects
  • Unlock a Laptop

Some of these privileges can override permissions set on an object. For example, a user logged on to a domain account as a member of the Backup Operators group has the right to perform backup operations for all domain servers. However, this requires the ability to read all files on those servers, even files on which their owners have set permissions that explicitly deny access to all users, including members of the Backup Operators group. A user right, in this case, the right to perform a backup, takes precedence over all file and directory permissions.

Logon Rights

The following list shows the logon rights that can be assigned to a user. These logon rights can be managed with the User Rights policy.

  • Access This Computer from Network
  • Log On Locally
  • Log On as a Batch Job
  • Log On as a Service
  • Deny Access to This Computer from the Network
  • Deny Logon as a Batch Job
  • Deny Logon as a Service
  • Deny Local Logon

The special user account LocalSystem has almost all privileges and logon rights assigned to it, because all processes that are running as part of the operating system are associated with this account, and these processes require a complete set of user rights.


Privileges

To ease the task of user account administration, you should assign privileges primarily to group accounts, rather than to individual user accounts. When you assign privileges to a group account, users are automatically assigned those privileges when they become a member of that group. This method of administering privileges is far easier than assigning individual privileges to each user account when the account is created.

The following table lists and describes the privileges that can be granted to a user.

Privilege | Description
Act as part of the operating system This privilege allows a process to authenticate as any user, and therefore gain access to the same resources as any user. Only low-level authentication services should require this privilege.

The potential access is not limited to what is associated with the user by default, because the calling process may request that arbitrary additional accesses be put in the access token. Of even more concern is that the calling process can build an anonymous token that can provide any and all accesses. Additionally, this token does not provide a primary identity for tracking events in the audit log.

Processes that require this privilege should use the LocalSystem account, which already includes this privilege, rather than using a separate user account with this privilege specially assigned.

Add workstations to a domain | Allows the user to add a computer to a specific domain . The user specifies the domain through an administrative user interface on the computer being added, creating an object in the Computer container of Active Directory. The behavior of this privilege is duplicated in Windows 2000 by another access control mechanism (permissions attached to the Computer container or organizational unit).
Back up files and directories | Allows the user to circumvent file and directory permissions to back up the system. Specifically, the privilege is similar to granting the following permissions on all files and folders on the local computer: Traverse Folder/Execute File, List Folder/Read Data, Read Attributes, Read Extended Attributes, and Read Permissions. See also Restore files and directories.
Bypass traverse checking | Allows the user to pass through directories to which the user otherwise has no access, while navigating an object path in any Windows file system or in the registry. This privilege does not allow the user to list the contents of a directory, only to traverse directories.
Change the system time | Allows the user to set the time for the internal clock of the computer.
Create a token object Allows a process to create a token which it can then use to get access to any local resources when the process uses NtCreateToken() or other token-creation APIs.

It is recommended that processes requiring this privilege use the LocalSystem account, which already includes this privilege, rather than using a separate user account with this privilege specially assigned
Create permanent shared objects | Allows a process to create a directory object in the Windows 2000 object manager. This privilege is useful to kernel-mode components that plan to extend the Windows 2000 object name space. Because components running in kernel mode already have this privilege assigned to them, it is not necessary to specifically assign this privilege.
Create a pagefile | Allows the user to create and change the size of a pagefile. This is done by specifying a paging file size for a given drive in the System Properties Performance Options.
Debug programs | Allows the user to attach a debugger to any process. This privilege provides powerful access to sensitive and critical system operating components.
Enable Trusted for Delegation on user and computer accounts | Allows the user to set the Trusted for Delegation setting on a user or computer object. The user or object that is granted this privilege must have write access to the account control flags on the user or computer object. A server process either running on a computer that is trusted for delegation or run by a user that is trusted for delegation can access resources on another computer. This uses a client's delegated credentials, as long as the client account does not have the Account Cannot Be Delegated account control flag set. Misuse of this privilege or of the Trusted for Delegation settings could make the network vulnerable to sophisticated attacks using Trojan horse programs that impersonate incoming clients and use their credentials to gain access to network resources.
Force shutdown of a remote system | Allows a user to shut down a computer from a remote location on the network. See also the Shut Down the System privilege.
Generate security audits | Allows a process to make entries in the security log for object access auditing. The process can also generate other security audits. The security log is used to trace unauthorized system access. See also the privilege Manage auditing and security log.
Increase quotas | Allows a process with write property access to another process to increase the processor quota assigned to that other process. This privilege is useful for system tuning, but can be abused, as in a denial-of-service attack.
Increase scheduling priority | Allows a process with write property access to another process to increase the execution priority of that other process. A user with this privilege can change the scheduling priority of a process through the Task Manager user interface.
Load and unload device drivers | Allows a user to install and uninstall Plug and Play device drivers. Device drivers that are not Plug and Play are not affected by this privilege and can only be installed by administrators. Since device drivers run as trusted (highly-privileged) programs, this privilege could be misused to install hostile programs and give these programs destructive access to resources.
Lock pages in memory | Allows a process to keep data in physical memory, preventing the system from paging the data to virtual memory on disk. Exercising this privilege could significantly affect system performance. This privilege is obsolete and is therefore never checked.
Manage auditing and security log Allows a user to specify object access auditing options for individual resources such as files, Active Directory objects, and registry keys. Object access auditing is not actually performed unless you have enabled it in the computerwide audit policy settings under Group Policy or under Group Policy defined in Active Directory; This privilege does not grant access to the computer-wide audit policy.

A user with this privilege can also view and clear the security log from the Event Viewer.
Modify firmware environment values | Allows modification of the system environment variables, either by a user through the System Properties or by a process.
Profile a single process | Allows a user to use Windows NT and Windows 2000 performance-monitoring tools to monitor the performance of non-system processes.
Profile system performance | Allows a user to use Windows NT and Windows 2000 performance-monitoring tools to monitor the performance of system processes.
Replace a process-level token | Allows a process to replace the default token associated with a sub-process that has been started.
Restore files and directories | Allows a user to circumvent file and directory permissions when restoring backed up files and directories, and to set any valid security principal as the owner of an object. See also the Back up files and directories privilege.
Shut down the system | Allows a user to shut down the local computer.
Take ownership of files or other objects | Allows a user to take ownership of any securable object in the system, including Active Directory objects, files and folders, printers, registry keys, processes, and threads.
Undock a laptop | Allows a user to undock a laptop with the Windows 2000 user interface.

Logon rights


Logon rights

The following table lists and describes Windows 2000 logon rights.

Logon Right | Description
Access this computer from a network | Allows a user to connect to the computer over the network. By default, this privilege is granted to Administrators, Everyone, and Power Users.
Log on as a batch job | Allows a user to log on using a batch-queue facility. By default, this privilege is granted to Administrators.
Log on as a service | Allows a security principal to log on as a service, as a way of establishing a security context. The LocalSystem account always retains the right to log on as a service. Any service that runs under a separate account must be granted this right. By default, this right is not granted to anyone.
Log on locally | Allows a user to log on at the computer's keyboard. By default, this right is granted to Administrators, Account Operators, Backup Operators, Print Operators, and Server Operators.

For information on privileges, see Privileges.


Access control

Access control is the process of authorizing users and groups to access objects on the network. Key concepts that make up access control are described in the following sections.

Ownership of objects

Windows 2000 assigns an owner to an object when the object is created. By default, the owner is the creator of the object.

Permissions attached to objects

The primary means for access control is permissions, or access rights. Permissions allow or deny users and groups particular actions for users and groups. Permissions are implemented primarily by way of security descriptors, which also define auditing and ownership. An example of a permission attached to an object is Read permission on a file.

Inheritance of permissions

Windows 2000 provides a feature for administrators to easily assign and manage permissions. Known as inheritance, this feature automatically causes objects within a container to inherit the permissions of that container. For example, the files within a folder, when created, inherit the permissions of the folder.

Object managers

If you need to change the permissions on an individual object, you can simply start the appropriate tool and change the properties for that object. For example, to change the permissions on a file, you can start Windows Explorer, right-click on the file name, and click Properties. You can use this dialog box to change permissions on the file.

Object auditing

Windows 2000 allows you to audit users' access to objects. You can then view these security-related events in the security log with the Event Viewer.

For more information, see the following:

  • Security descriptors
  • Ownership
  • Auditing access to objects
  • Permissions
  • Objects and object managers


Security descriptors

Every container and object on the network has a set of access control information attached to it. Known as a security descriptor, this information controls the type of access allowed by users and groups. Windows 2000 automatically creates the security descriptor when a container or object is created. A typical example of an object with a security descriptor is a file.

For more information on security descriptors, see the following:

  • Permissions
  • Auditing access to objects


Ownership

Every object (whether in the Active Directory or in an NTFS volume) has an owner. The owner controls how permissions are set on object and to whom permissions are granted.

When an object is created, the person creating the object automatically becomes its owner. Administrators will create and own most objects in Active Directory and on network servers (when installing programs on the server). Users will create and own data files in their home directories, and some data files on network servers.

Ownership can be transferred in the following ways:

  • The current owner can grant the Take Ownership permission to other users, allowing those users to take ownership at any time.
  • An administrator can take ownership of any object under his or her administrative control. For example, if an employee leaves the company suddenly, the administrator can take control of the employee's files.

Although an administrator can take ownership, the administrator cannot transfer ownership to others. This restriction keeps administrators accountable for their actions.


Auditing access to objects

With Windows 2000, administrators can monitor access to specific objects in Active Directory. Additionally, they can monitor use of special privileges by users, as well as user logons, failed logon attempts, and logoffs.

For more information, see Audit settings on objects.


Permissions

Permissions define the type of access granted to a user or group for an object or object property. For example, the Finance group can be granted Read, Write, and Delete permissions for the file payroll.dat.

The permissions attached to an object depend on type of object. For example, the permissions that can be attached to a file are different from those that can be attached to a registry key.

Some permissions, however, are common to all types of objects. These common permissions are:

  • Read permissions
  • Modify permissions
  • Change owner
  • Delete

For specific permissions that can be attached to each type of object, see Objects and object managers.

For more information on permissions, see Permissions and security descriptors, Explicit vs. inherited permissions, Object-type and per-property permissions, and How inheritance affects file and folder permissions.


Permissions and security descriptors

Permissions are defined within an object's security descriptor. Permissions are associated with, or assigned to, specific users and groups. For example, for the file temp.dat, the Administrator group might be assigned Read, Write, and Delete permissions, while the Operator group might be assigned Read and Write permissions only.

Each assignment of permissions to a user or group is known as a permission entry, or access control entry (ACE). The entire set of permission entries in a security descriptor is known as a permission set. Thus, for the file temp.dat, the permission set includes two permission entries: one for the Administrator group and one for the Operator group.

Permissions can be applied to any object in Active Directory or on a local computer, but the majority of permissions should be applied to groups, rather than individual users. This eases the task of managing permissions on objects.

You can assign permissions for objects to:

  • Groups, users, and special identities in the domain.
  • Groups and users in that domain and any trusted domains.
  • Local groups and users on the computer where the object resides.


Explicit vs. inherited permissions

There are two types of permissions: explicit permissions and inherited permissions.

Explicit permissions are those that are attached directly to an object, either when the object is created, or by user action. For example, if you create a folder called Programs, the permissions attached to this folder are explicit permissions.

Inherited permissions are those that are propagated to an object from a parent object. Inherited permissions ease the task of managing permissions and ensure consistency of permissions among all objects within a given container.

By default, objects within a container inherit the permissions from that container when the objects are created. For example, when you create the Programs folder, all subfolders and files created within the Programs folder automatically inherit the permissions from that folder. Thus, the Programs folder has explicit permissions, while all subfolders and files within it have inherited permissions.

For more information on inherited permissions, see How inheritance affects file and folder permissions.

For information on changing explicit and inherited permissions, see Permissions.


Object-type and per-property permissions

There are two types of granularity: Object-type permissions and per-property permissions. These two types of permissions provide more precise access control.

Object-type permissions

Object-type permissions define the types of objects that a user or group is allowed to create or delete. A permission entry for object-type permissions has the following syntax:

Group: Permission: Object-type

For example, permissions for a file could look as follows:

Everyone: create;delete: file

You cannot manage this type of permission through the Properties dialog box.

For more information on setting permissions for specific types of objects, see the following:

  • File permissions
  • Folder permissions
  • Shared folder permissions
  • Active Directory object permissions
  • Registry key permissions
  • Services permissions
  • Assigning printer permissions

Per-property permissions

For Active Directory objects, per-property permissions are supported. You can control not only who can see an object, but also who has Read and Write access to specific object properties. A permission entry for per-property permission is as follows:

Group: Permission: Property

For example, for object properties such as e-mail and phone information, you can assign Read access to the Everyone group, and Read and Write access to the Receptionist group, as follows:

Everyone: Read: email;phone
Receptionist: Read;Write: email;phone

Permissions for a single property are the finest level of granularity you can set.


Objects and object managers

Each type of object is controlled by an object manager. There is a different object manager for each type of object. The object types, their object managers, and the tools you use to manage these objects are as follows:

Object Type | Object Manager | Management Tool
Files and folders | NTFS | Windows Explorer
Shares | Server service | Windows Explorer
Active Directory objects | Active Directory | Active Directory Users and Computers
Registry keys | The registry | regedit32 command
Services | Service controllers | Security Templates, Security Configuration and Analysis
Printer | Print spooler | Start menu

For a list of the default permissions attached to each object type, see the following:

  • File permissions
  • Folder permissions
  • Shared folder permissions
  • Active Directory object permissions
  • Registry key permissions
  • Services permissions
  • Assigning printer permissions


Active Directory object permissions

In controlling access to Active Directory objects, there are two things to consider: the permissions that you are allowed to attach to the object and the ways in which you can attach these permissions in order to delegate administrative responsibility for Active Directory objects.

Active Directory objects can have the following permissions attached to them:

  • Create Child (can be specific to the type of object or general for any object under the container)
  • Delete Child (can be specific to the type of object or general for any object under the container)
  • Read Property (can be specific to an individual property of the object or general for all attributes of the object)
  • Write Property (can be specific to an individual property of the object or general for all attributes of the object)
  • List Contents
  • Write Self
  • Delete Tree
  • List Object
  • Control Access (can be specific to an individual control operation or general for all control operations on the object)

For information on using permissions to delegate administrative control to users within organizational units and groups, see Delegating administrative control.


Registry key permissions

Registry keys can have the following permissions attached to them:

  • Query Value
  • Set Value
  • Create subkey
  • Enumerate subkeys
  • Notify changes
  • Create link


Services permissions

Unlike other programs, which are executed by a security principal (user or computer), services run in their own security context. In order to establish a security context, a service needs to log on the system, just as security principals do. By default, a service logs on to the system using the System account.

You can choose to have a service use a different account. This may be useful when you need to provide a service with specific permissions. Services may often impersonate security principals, carrying out processes on their behalf. This occurs through the use of a service by a client program.

Files and folders can have the following permissions attached to them:

  • Query Configuration
  • Change Configuration
  • Query Status
  • Enumerate dependent services
  • Start Service
  • Stop Service
  • Pause and Continue Service
  • Interrogate Service
  • Issue user defined control

Note

  • You should use the System account for service logons. This ensures that the service has the security context appropriate for its own operations, as well as when acting on behalf of clients.


Auditing security events

Establishing an audit trail is an important facet of security. Monitoring the creation or modification of objects gives you a way to track potential security problems, helps assure user accountability, and provides evidence in the event of a security breach.

There are three main steps to implementing security-related auditing for your system.

First, you must turn on the categories of events you wish to audit. Examples of event categories are user logon and logoff and account management. The categories of events you select constitute your audit policy. When you first install Windows 2000, no categories are selected, and therefore no audit policy is in force. Computer Management lists the event categories that you can audit.

Second, you must set the size and behavior of the security log.

Finally, if you have selected either the audit directory service access category or the audit object access category, you must determine the objects to which you want to monitor access and modify their security descriptors accordingly. For example, if you want to audit any attempts by users to open a particular file, you can set a Success or Failure attribute directly on that file for that particular event.

For more information on auditing security events, see Auditing policies, Viewing security logs, Audit settings on objects, How inheritance affects file and folder auditing, and Selecting where to apply auditing entries.


Auditing policies

Before you implement auditing, you must decide on an auditing policy. An auditing policy specifies categories of security-related events that you wish to audit. When Windows 2000 is first installed, all auditing categories are turned off. By turning on various auditing event categories, you can implement an auditing policy, one that suits the security needs of your organization.

Auditing categories are turned on and off with Computer Management.

The event categories that you can choose to audit are:

  • Audit account logon events
  • Audit account management
  • Audit directory service access
  • Audit logon events
  • Audit object access
  • Audit policy change
  • Audit privilege use
  • Audit process tracking
  • Audit system events

If you choose to audit access to objects as part of your audit policy, you must turn on either the audit directory service access category (for auditing objects on a domain controller), or the audit object access category (for auditing objects on a member server). Once you have turned on the correct object access category, you can use each individual object's Properties to specify whether to audit successes or failures for the permissions granted to each group or user. For more information on setting auditing on objects, see Audit settings on objects.

Note

  • To enable auditing of local objects, you must be logged on as a member of the Administrators group.


Viewing security logs

Auditing a local object creates an entry in the security log. The security entries that appear in the security log depend on the auditing categories selected for your auditing policy. For events concerning access to objects, the entries in the security log also depend on the audit settings defined for each object.

For example, if your auditing policy specifies auditing of files and folders, and a file's properties specify that failed deletions of that file are to be audited, then each failed attempt by a user to delete the file will appear in the security log.

You can view the security log using Event Viewer.

Size of the security log

It is important that you set the size of the security log appropriately. Because the security log is limited in size, you should select the categories of events to be audited carefully. You should also consider the amount of disk space you are willing to devote to the security log. The maximum size is defined in Event Viewer.

For information on what to do when the security log is full, see Halting the computer when the security log is full.

Events that can be audited

When examining the security log, you will see events according to the event category to which they pertain. The types of events that can be audited and that appear in the security log are as follows. The following list shows the events that can be audited:

  • System restart
  • System shutdown
  • Authentication package loading
  • Registered logon process
  • Audit log cleared
  • Number of audits discarded
  • Logon successful
  • Unknown user name or password
  • Time restricted logon failure
  • Account disabled
  • Account expired
  • Invalid workstation
  • Logon type restricted
  • Password expired
  • Failed logon
  • Logoff
  • Open object
  • Close handle
  • Assign special privilege
  • Privileged service
  • Privileged object access
  • Process created
  • Process exit
  • Duplicate handle
  • Indirect reference
  • Privilege assigned
  • Audit policy change
  • Domain changed
  • User changed
  • User created
  • User deleted
  • Global group member removed
  • Global group member added
  • Domain local group changed
  • Domain local group created
  • Domain local group member removed
  • Domain local group member added
  • Domain local group member deleted

For information on the categories of events that can be audited, see Auditing policies.


Audit settings on objects

Each object has a set of security information, or security descriptor, attached to it. Part of the security descriptor specifies the groups or users that can access an object, and the types of access (permissions) granted to those groups or users. This part of the security descriptor is known as a discretionary access control list (DACL).

In addition to containing permissions information, however, a security descriptor for an object also contains auditing information. This auditing information is known as a system access control list (SACL). More specifically, a SACL specifies the following:

  • The group or user accounts to audit when accessing the object.
  • The access events to be audited for each group or user. An example of an access event is modifying a file.
  • A Success or Failure attribute for each access event, based on the permissions granted to each group and user in the object's DACL

In general, the types of access that can be audited depend on whether you are auditing access to files and folders or to Active Directory objects. The types of access are listed in the following sections.

Files and folders

You can audit the access of files and folders on NTFS volumes to identify who took various types of actions with the files and folders.

When you audit a file or folder, an entry is written to the Event Viewer security log whenever the file or folder is accessed in a certain way. You specify which files and folders to audit, whose actions to audit, and what types of actions are audited.

To set auditing on a file or folder, use Group Policy to enable auditing, and then use Windows Explorer to specify which files to audit and which type of file access events to audit.

You can audit successful and failed attempts of the following types of folder and file access:

Types of folder access | Types of file access
Displaying names of files in the folder | Displaying the file's data
Displaying folder attributes | Displaying file attributes
Changing folder attributes | Displaying the file's owner and permissions
Creating subdirectories and files | Changing the file
Going to the folder's subdirectories | Changing file attributes
Displaying the folder's owner and permissions | Running the file
Deleting the folder | Deleting the file
Changing folder permissions | Changing the file's permissions
Changing folder ownership | Changing the file's ownership

You can apply auditing to an object and, through inheritance, the auditing can apply to any child objects. For example, if you want to audit failed write access to a folder, this auditing event can be inherited by all files within the folder. For more information, see How inheritance affects file and folder auditing.

Active Directory objects

For auditing Active Directory objects, you can also audit the following actions:

  • Read/write all properties.
  • Read/write individual properties.

Note

  • To audit files and folders, you must be logged on as a member of the Administrators group.


Stored Data Security

Data that is to be stored locally may require additional methods of protection. The data may be something you want to protect (such as a sensitive file), or it may be something you want to protect yourself from (such as an unknown software component).

For more information, see the following:

  • Introduction to stored data security
  • Encrypting File System


Introduction to stored data security

Access to files that you want to protect can be restricted through the use of user rights and permissions. However, if an intruder gains access to a user's disk drive, the intruder could remove the drive, install it on another system, and, with administrative privileges, access the data stored on the drive. To ensure against this scenario, Windows 2000 provides the best solution possible, data encryption. Data encryption is provided transparently within Windows 2000 by a feature known as Encrypting File System (EFS).

In addition to allowing users to protect their data from intrusion or theft, Windows 2000 also supports digital signing, which protects users from unwanted software components.


Encrypting File System (EFS)

Encrypting File System (EFS) provides the core file encryption technology used to store encrypted files on NTFS file system volumes.

For more information on EFS, see the following:

  • Introduction to Encrypting File System
  • Data encryption and decryption
  • Data recovery


Introduction to Encrypting File System

Encrypting File System (EFS) enables users to encrypt and decrypt files. Users use EFS to keep their files safe from intruders who might gain unauthorized physical access to their sensitive, stored data (for example, by stealing a laptop or external disk drive).

Users work with encrypted files and folders just as they do with any other files and folders. Encryption is transparent. If the EFS user is the same person that encrypted the file or folder, the system automatically decrypts the file or folder when the user accesses it later. However, an intruder is prevented from accessing any encrypted files or folders.


Data encryption and decryption

Encrypting File System (EFS) allows users to store data securely on local computers. EFS does this by encrypting data in selected NTFS files and folders.

Because EFS is integrated with the file system, it is easy to manage, difficult to attack, and transparent to the user. This is particularly useful for securing data on computers that may be vulnerable to theft, such as mobile computers.

Files and folders cannot be encrypted or decrypted on FAT volumes. Also, EFS is designed to store data securely on local computers. As such, it does not support the sharing of encrypted data.

EFS encryption keys

Once a user has specified that a file be encrypted, the actual process of data encryption and decryption is completely transparent to the user. The user does not need to understand this process. However, the following explanation of how data encryption and decryption works might be useful for administrators.

This explanation only applies to files, not folders. Folders themselves are not encrypted, only the contents of the files within a folder. Like folders, sub-folders are not encrypted; however, they are marked to indicate that they contain encrypted file data.

Encryption of files works as follows:

  • Each file has a unique file encryption key, which is later used to decrypt the file's data.
  • The file encryption key is in itself encrypted--it is protected by the user's public key corresponding to the user's EFS certificate.
  • The file encryption key is also protected by the public key of an authorized recovery agent.

Decryption of files works as follows:

  • To decrypt a file, the file encryption key must first be decrypted. The file encryption key is decrypted when the user has a private key that matches the public key.
  • The user is not the only person that can decrypt the file encryption key. A recovery agent can also decrypt the file encryption key, by using the recovery agent's private key.
  • Once the file encryption key is decrypted, it can be used by either the user or the recovery agent to decrypt the data in the file.

Private keys are held in a protective key store, and not in the Security Account Manager (SAM) or in a separate directory. For more information, see the Windows 2000 Server Resource Kit.

Storing encrypted files on remote servers

If users in your Windows 2000 computing environment want to store encrypted files on remote servers, it is useful to know the following:

  • Windows 2000 supports the storage of encrypted files on remote servers. However, this is feature is not intended to support the remote sharing of encrypted files by multiple users.
  • Users should never store highly-sensitive data on servers where physical security might be at risk.
  • Encrypted data is not encrypted when in transit over the network, but only when stored on disk. The exception to this is when your system includes Internet Protocol security (IPSec). IPSec encrypts data while it is transported over a TCP/IP network.
  • Encrypted files are not accessible from Macintosh clients.

Before users can encrypt files that reside on a remote server, an administrator must designate the remote server as trusted for delegation. This allows all users with files on that server to encrypt those files. For more information, see Designating a remote server for file encryption.


Data recovery

Data recovery is important when you need to be able to recover data encrypted by an employee after the employee leaves, or when the user's private key is lost.

For more information, see the following:

  • Encrypting File System and data recovery
  • Recovery policy
  • Recovery agents


Recovery policy

A recovery policy refers to the policy that users in your computing environment adhere to when recovering encrypted data. A recovery policy is a type of public key policy.

When Windows 2000 Server is installed, a recovery policy is automatically implemented for the domain when the first domain controller is set up. The domain administrator is issued the self-signed certificate, which designates the domain administrator as the recovery agent.

EFS provides built-in data recovery by enforcing a recovery policy requirement. The requirement is that a recovery policy must be in place before users can encrypt files. The recovery policy provides for a person to be designated as the recovery agent. A recovery policy is automatically put in place when the administrator logs on to the system for the first time, making the administrator the recovery agent.

Configuring a recovery policy

The default recovery policy is configured locally for stand-alone computers. For computers that are part of a network, the recovery policy is configured at either the domain, organizational unit, or individual computer level, and applies to all Windows 2000-based computers within the defined scope of influence. Recovery certificates are issued by a Certificate Authority (CA) and managed using Certificates in the Microsoft Management Console (MMC).

On a network, the recovery policy is set up by a domain administrator or recovery agent who controls the recovery keys for all computers in the scope of influence for the policy.

Because the security subsystem handles enforcing, replicating, and caching of the recovery policy, users can implement file encryption on a system that is temporarily offline, such as a portable computer. (This process is similar to logging on to their domain account using cached credentials).

Types of recovery policies

Administrators can define one of three kinds of policies: a no-recovery policy, an empty recovery policy, or a recovery policy with one or more recovery agents.

  • Recovery-agent policy. When an administrator adds one or more recovery agents, a recovery-agent policy is in effect. These agents are responsible for recovering any encrypted data within their scope of administration. This is the most common type of recovery policy.
  • Empty recovery policy. When an administrator deletes all recovery agents and their public-key certificates, an empty recovery policy is in effect. An empty recovery policy means that no one is a recovery agent, and that users cannot encrypt data on computers within the scope of influence of the recovery policy. The effect of an empty recovery policy is to turn off EFS altogether.
  • No-recovery policy. When an administrator deletes the group recovery policy, a no-recovery policy is in effect. Because there is no group recovery policy, the default local policy on individual computers is used for data recovery. This means that local administrators control the recovery of data on their computers.

Changing the recovery policy

To change the default recovery policy for a domain, you must log on to the first domain controller as an Administrator. Then, you must invoke Group Policy through the Active Directory Users and Computers snap-in, and select Security Settings, Public Key Policies, and Encrypted Data Recovery Agents.

Note

  • Group policy overrides any locally-defined policies.


Recovery agents

A recovery agent is an administrator authorized to decrypt data that was encrypted by another user. Recovery agents are useful, for example, when employees leave the company and their remaining data needs to be decrypted. Before you can add a recovery agent for a domain, you must ensure that each recovery agent has been issued an X509 Version 3 certificate.

The recovery agent has a special certificate and associated private key that allow data recovery for the scope of influence of the recovery policy. If you are the recovery agent, you should be sure to use the Export command from Certificates in Microsoft Management Console (MMC) to back up the recovery certificate and associated private key to a secure location. After backing them up, you should use Certificates in MMC to delete the recovery certificate. Then, when you need to perform a recovery operation for a user, you should first restore the recovery certificate and associated private key using the Import command from Certificates in MMC. After recovering the data, you should again delete the recovery certificate. You do not have to repeat the export process.

To add recovery agents for a domain, you add their certificates to the existing recovery policy. This is done by using the Active Directory Users and Computers snap-in to invoke the Add Recovery Agents wizard.


Network data security

Network data can be protected on the wire or at the network interface. Securing data on the wire requires cryptographic methods and a supporting protocol. This is the purpose of Internet Protocol security (IPSec) and the Router Service. Securing data at the network interface requires a firewall to proxy services and mediate connections between the internal network (LAN) and external network (Internet). This is the purpose of Proxy Server.

These facilities are all integrated in Windows NT Server, and are full participants in the Windows NT security framework.

Internet Protocol security

Internet Protocol security (IPSec) is a framework of open standards for ensuring secure private communications over Internet Protocol networks, using cryptographic security services. IPSec is based on an end-to-end security model, meaning that the only computers which must know about IPSec are the sending and receiving computers. The Windows 2000 implementation of IPSec is based on standards developed by the Internet Engineering Task Force (IETF) IPSec working group.

For more information, see IPSec concepts and deployment.

Router service

The Windows 2000 Router service provides routing services in the LAN and WAN environments, and over the Internet using secure virtual private network (VPN) connections. The VPN connections are based on the Point-to-Point Tunneling Protocol (PPTP) and the Layer 2 Tunneling Protocol (L2TP).

The Router Service is intended for use by system administrators already familiar with routing protocols and routing services. Use the Routing and Remote access feature to view and manage both routers and dial-up servers.

Proxy Server

Intranet applications such as Web browsers are often more valuable when their LAN is connected to the Internet, but installing an unregulated Internet connection can compromise the LAN's security. Microsoft Proxy Server helps reduce this potential danger by regulating LAN-Internet traffic to maximize the security and efficiency of intranet applications. Microsoft Proxy Server acts as a gateway with firewall-class security between your network and the Internet.

A proxy server manages traffic between programs on one network and servers on another. When a client program makes a request, the proxy server responds by translating the request and passing it to the Internet. When a computer on the Internet responds, the proxy server passes that response back to the client program on the computer that made the request. The proxy server computer has two network interfaces: one connected to the LAN and one connected to the Internet.

The primary security features of Proxy Server are:

  • It blocks inbound connections.
  • LAN clients can initiate connections to Internet servers, but Internet clients cannot initiate connections to LAN servers.
  • It restricts outbound connections.

LAN clients are authenticated using their standard Windows NT security credentials. Proxy Server can restrict outbound connections in several ways, including by user, program protocol, TCP/IP port number, time of day, and destination domain name or Internet Protocol address.

Programs must behave differently when using a proxy server than when directly accessing network resources. As a rule, Web browsers must be reconfigured, but require no additional software. Other WinSock programs require no reconfiguration, but the client system requires a replacement WinSock driver.

For more information, see your Proxy Server documentation.


Security Configuration and Analysis

Security Configuration and Analysis can be used to analyze and configure local computer security.

  • Introduction to Security Configuration and Analysis
  • Understanding Security Configuration and Analysis


Managing Security Templates

Security Templates defines security templates which can be applied to a Group Policy object in the Active Directory or a local computer.

For more information, see Security templates.


Security areas

The following security areas may be configured for a system:

  • Account Policies
  • Local Policies
  • Event Log
  • Restricted Groups
  • File System, Registry, System Services

This list does not include Public Key or Internet Protocol security policies. For information on configuring these, see Public Key Policy or Internet Protocol security.


Using security

Security considerations are also influenced by the operational context: the server's role within the organization, such as whether it is used as a domain controller, Web server, file server, or database server.

If your organization's network is comprised of intranets, extranets, or Internet sites, you will also need to incorporate a public key infrastructure into your overall security solution. This infrastructure may include one or more dedicated certification authorities for your organization.

This section introduces the methods and operations you can use to secure data for your organization or on your local computer. For more information about these methods and operations, see the following:

  • Working with built-in and predefined groups
  • Setting up auditing
  • Managing trust relationships
  • Assigning user rights
  • Delegating administrative control
  • Enabling Kerberos V5 authentication
  • Starting programs as an administrator
  • Certificate-based authentication
  • Public key infrastructure and certificates
  • Using security templates
  • Security configuration and analysis
  • Permissions
  • Storing Data Securely


Working with built-in and predefined groups

You can use the global groups of a domain to collect the various types of user accounts in that domain into groups. (User accounts might include regular users, administrators, and guests.) These groups can then be placed in domain local groups in that domain and others.

The built-in domain local groups of a domain are primarily used to assign default sets of permissions to users who will have some administrative control in that domain. For example, the Administrators group in a domain has a broad set of administrative authority over all user accounts and resources in the domain.

Global Group | Description
Domain Users By default, any user account you create in a domain is automatically added to the Domain Users global group. You can use the Domain Users group to represent all the user accounts created in the domain. For example, if you want all the users in this domain to have access to a printer, you can assign permissions for the printer to the Domain Users group (or you can put the Domain Users group into a domain local group that has permissions for the printer).

By default, the Domain Users group in a domain is a member of the Users group in the same domain.
Domain Admins The Domain Admins global group can represent the users who have broad administrative rights in a domain. Windows 2000 Server places all users with an Administrator account into this group automatically.

Because Windows 2000 Server supports administration and delegation of authority, you should not have to grant these broad administrative rights to many users. In fact, it is recommended that you limit the number of users that you place in the Domain Admins group.

By default, the Domain Admins group in a domain is a member of the Administrators group in the same domain.
Domain Guests | By default, the Domain Guests global group is a member of the Guests group in the same domain, and automatically contains the domain's default Guest user account.

For descriptions of available user rights, see User Rights.


Setting up auditing

An audit records an entry whenever users perform certain actions that you specify. For example, the modification of a file or a policy can trigger an audit entry. The audit entry shows the action performed, the associated user account, and the date and time of the action. You can audit both successful and failed attempts at actions.

Actions are not audited by default. If you have the appropriate administrative permissions, you can specify what types of actions are audited. When you enable auditing, you:

  1. Establish a local audit policy on the computer where the actions occur.
  2. Choose the actions to audit.

There are different auditing tools to use, depending on whether you want to audit Active Directory objects or local objects:

  • For Active Directory objects, use Active Directory Users and Computers.
  • For files and folders, registry keys, and network printers, use the Security tab in the object's Properties dialog box. This allows you to specify which types of access to those objects you would like to audit.

For information on configuring auditing settings, see Local Policies.


Managing trust relationships

When joining a Windows 2000 domain to a Windows 2000 domain forest, a trust relationship is established automatically. This trust relationship is a two-way, transitive trust relationship. No administrative tasks are required to establish this trust relationship.

Trust relationships within a domain forest are established at the time that the domain is created. Once established, these trust relationships do not need to be managed. The two exceptions to this are:

  • Trust relationships between Windows 2000 forests
  • Trust relationships between domains in Windows NT 4.0 and earlier.

To set up a trust relationship between a Windows 2000 domain and a Windows NT domain, you must explicitly establish the trust relationship. To do this, use Active Directory Domains and Trusts.

If you have upgraded a Windows NT 4.0 domain to a Windows 2000 domain, the existing trust relationship remains in the same state.

For more information on trust relationships within a domain, see Domain trusts.


Assigning user rights

You assign user rights by configuring user rights settings for local policies. Assigning user rights is one way that you can delegate or restrict administrative control within a domain.

For more information on assigning user rights, see Local policies.

For information on delegating administrative control through the assignment of user rights, see Delegating administration.


Delegating administrative control

You define delegation of responsibility to create new users or groups at the level of the organizational unit, or container, where the accounts are created. Group administrators for one organizational unit do not necessarily have the ability to create and manage accounts for another organizational unit within a domain. However, policy settings that are domainwide and permissions that are defined at higher levels in the directory tree can apply throughout the tree by using inheritance of permissions.

You can delegate administration of a domain or organizational unit by using the Delegation of Control wizard available in Active Directory Users and Computers.

There are three ways to define the delegation of administration responsibilities:

  • Delegate permissions to change properties on a particular container.
  • Delegate permissions to create and delete objects of a specific type under an organizational unit, such as users, groups, or printers.
  • Delegate permissions to update specific properties on objects of a specific type under an organizational unit. For example, you can delegate the right to set a password on a User object.

You can delegate administration of particular resources to a specific individual or group, eliminating the need for multiple administrators to have authority over an entire domain or site. With appropriate delegation, the user or group who has been granted the appropriate permissions can, in turn, delegate administration of a subset of their accounts and resources.

You can configure the scope of delegated administrative responsibility in many different ways. Although you generally grant permissions at the organizational unit level by applying inheritance, you can also delegate administration for an entire domain within a forest.

Administrators can view the delegation information that is defined for containers by using Active Directory Users and Computers.

For more information on delegating administrative responsibilities, see Delegating administration.

Related Topics


Enabling Kerberos V5 authentication

Kerberos V5 authentication is automatically enabled when you install Windows 2000 Server.

The account policies for user accounts define policies regarding the use of Kerberos V5. For example, a user account policy for Kerberos V5 sets the lifetime of users' Kerberos V5 tickets. As an administrator, you can use the default account policies or you can change it to suit the needs of your environment.

Successful authentication using Kerberos V5 requires that both the client system and the server running the desired service must run the Windows 2000 operating system.

If a Windows 2000 client system tries to authenticate to a server running another operating system, Windows 2000 uses the NTLM protocol as the authentication mechanism.

For more information on account policies related to Kerberos V5, see Account policies.

For a basic understanding of how Kerberos V5 works, see Kerberos V5 authentication.


Starting programs as an administrator

In some cases, you might want to run a program that requires you to be logged on as an administrator. To do this, you can use the Run as program, which allows you to become either a local or a domain administrator.

The Run as command can be used to start any program or Microsoft Management Console (MMC), as long as:

  • You provide the appropriate user account and password information.
  • The user account has the ability to log on to the computer.
  • The program or administrative tool is available on the system and to the user account.

Some applications, such as Windows Explorer, the Printers folder, and desktop items are started indirectly by Windows 2000 and therefore cannot be started with the Run as command.

For more information, see Using the Run as command to start a program as an administrator.


Certificate-based authentication

This section covers:

  • Enabling certificate-based authentication
  • Using smart cards


Enabling certificate-based authentication

Your organization may need to support authentication of external users, individuals who do not have an account in Active Directory. There are a number of instances where you may want to provide external users with secure access to specific data within the enterprise. For example, corporate partners may need extranet access, a department may need access to another department's intranet pages, or you may want to provide selective public access.

Authenticating external users requires the following:

  • The external user must have a certificate.
  • You must establish a user account for use by one or more external users.
  • The external user's certificate must be issued by a certification authority (CA) that is listed in the certificate trust list for (or trusted by) the site, domain, or organizational unit in which you have created the user account.
  • You must create a name mapping between the external user certificate and the Active Directory account you have created for authenticated access.

    Any external user whose client program presents a mapped certificate can then access the permitted locations published on the appropriate Web site for your organization. The authentication process is transparent to the external user.

    For more information on account mapping procedures, see Map a certificate to a user account in Active Directory.

Note

  • You should verify that rights and permissions to the necessary data meet your security policy and are adequate for the needs of the external users.


Public key certificates

To implement the use of and manage public key certificates, see the following:

  • Using Windows 2000 Certificate Services Web pages
  • Using the Certificates snap-in
  • Using Certificate Services
  • Using public key policies
  • Certificate Services command-line functions


Using Security Templates

This section covers:

  • Defining security templates
  • Predefined templates
  • Applying security templates


Security Configuration and Analysis

Security Configuration and Analysis offers the ability to configure security, analyze security, view results, and resolve any discrepancies revealed by analysis.

  • Predefined security templates
  • Importing and exporting security templates
  • Security analysis
  • Viewing analysis results
  • Configuring system security
  • Resolving security discrepancies


Permissions

This section covers:

  • Permissions for Active Directory objects
  • Permissions on a file server


Permissions for Active Directory objects

To ease the task of controlling access to Active Directory objects, Windows 2000 provides two new features--delegated access control and object-specific inheritance. The following sections describe these features.

Delegating access control

You can delegate administration of a domain or organizational unit by using the Delegation of Control wizard available in Active Directory Users and Computers.

For more information on delegating administration of Active Directory objects, see Delegating administrative control.

Object-specific inheritance

Access control information that is defined at higher-level containers of Active Directory flows down to subcontainers and their objects. This is called inheritance of access rights, or permissions.

Through inheritance, you can make changes to a specific container that automatically affect all subcontainers and their objects. For ease of administration, it is recommended that you define permissions on high-level containers, such as a high-level folder; these permissions will then automatically flow down to objects within that folder. Where appropriate, you can define exceptions, but you should minimize the number of exceptions as much as possible.

To apply inheritance of permissions for Active Directory objects, you use Active Directory Users and Computers, view the properties for an object, and click the Security tab.

You can choose the types of objects within a high-level container that you would like inheritance to apply to. For example, you can apply inheritance to only subfolders within a folder, but not files within the subfolders, or you can apply inheritance to all subfolders and files within a folder.


Permissions on a file server

One possible scenario for working with permissions is when you must assign permissions for the files on a file server. For example, suppose you need to set file permissions on a server used by a small department. The file server includes an applications folder, home folders for each of the department's users, a public folder where users can share files, and a drop folder where users can file confidential reports that only the group manager can read.

Applications folder. In this folder, make all executable programs read-only to all users, to prevent viruses and Trojan horses. You can also grant Change permission to members of the Administrators group, so that administrators can grant themselves Write permission when it is time to update a program.

If none of your programs needs to write any files (such as initialization files) in their own folders, you should also set all of the folders containing programs to read-only.

Home folders. In these folders, give each user Full Control over his or her own folder, and do not give anyone permissions for any other folder.

Public folder. In this folder, you can give all users Change permission. Change permission is more appropriate than Full Control, because Full Control also allows users to set permissions for the public folder and take ownership of it.

Drop folder. To create a drop folder, grant the Users or Everyone built-in groups Add permission for the folder, and grant Change permission to the manager who is to read the files in the folder.

Give access to local system folders or subfolders only to Administrators or Server Operators.


Storing Data Securely

Stored data security refers to the ability to store data on disk in an encrypted form. By using Encrypting File System (EFS), users can encrypt their data as it is stored on disk.

To help you administer EFS, it is recommended that you read the following topics.

  • Introduction to using Encrypting File System
  • Encrypting and decrypting data using Encrypting File System
  • Backing up, restoring, and recovering data


Introduction to using Encrypting File System

Encrypting File System (EFS) allows users to store their on-disk data in encrypted format.

Encryption is the process of converting data into a format that cannot be read by another user. Once a user has encrypted a file, the file automatically remains encrypted whenever the file is stored on disk.

Decryption is the process of converting data from encrypted format back to its original format. Once a user has decrypted a file, the file remains decrypted whenever the file is stored on disk.

EFS provides the following features:

  • Users can encrypt their files when storing them on disk. Encryption is as easy as selecting a check box in the file's Properties dialog box.
  • Accessing encrypted files is fast and easy. Users see their data in plain text when accessing the data from disk.
  • Encryption of data is accomplished automatically, and is completely transparent to the user.
  • Users can actively decrypt a file by clearing the Encryption check box on the file's Properties dialog box.
  • Administrators can recover data that was encrypted by another user. This ensures that data is accessible if the user that encrypted the data is no longer available or has lost their private key.

EFS only encrypts data when it is stored on disk. To encrypt data as it is transported over a TCP/IP network, two optional features are available--Internet Protocol security (IPSec) and PPTP encryption.


Encrypting and decrypting data with Encrypting File System

You can use Encrypting File System (EFS) to:

  • Encrypt their files
  • Access their encrypted files
  • Move or rename their encrypted files
  • Copy their encrypted files
  • Decrypt their files

Encrypting data

The default configuration of the Encrypting File System (EFS) requires no administrative effort--users can begin encrypting files immediately. EFS automatically generates an encryption key pair for a user if one does not exist.

EFS uses the expanded Data Encryption Standard (DESX) as the encryption algorithm.

Encryption services are available from Windows Explorer. Users can also encrypt a file or folder using the command-line function cipher. For more information about the cipher command, type cipher /? at a command-line prompt.

Users encrypt a file or folder by setting the encryption property for files and folders just as you set any other attribute, such as read-only, compressed, or hidden. If a user encrypts a folder, all files and subfolders created in or added to the encrypted folder are automatically encrypted. It is recommended that users encrypt at the folder level.

Compressed files cannot be encrypted. Also, folders that are marked for encryption are not actually encrypted. Only the files within the folder are encrypted.

Accessing encrypted data

Users access encrypted files just as they do unencrypted files. Thus, when a user accesses an encrypted file that is stored on disk, the user is able to read the contents of the file in the normal way. When the user stores the file on disk again, EFS transparently encrypts the file again.

Only the user that encrypted a file can access it later. This is assured because users have private keys that allow them access to their own encrypted files. If another user tries to access an encrypted file, that user receives an Access Denied message.

Moving or renaming encrypted files

If a user moves a file to another folder, the file retains its encryption state, regardless of whether the destination folder is encrypted or unencrypted. For example, when moving an encrypted file to an unencrypted folder, the file remains encrypted. When moving an unencrypted file to an encrypted folder, the file remains unencrypted. Similarly, renaming an encrypted file does not alter its encrypted status.

Copying encrypted files

When copying encrypted files to an unencrypted folder, encryption always takes priority. Thus, when copying an unencrypted file to an encrypted folder, EFS automatically encrypts the file. When copying an encrypted file to an unencrypted folder, the file remains encrypted.

Decrypting data

You can decrypt a file by clearing the Encryption check box in a the file's Properties dialog box. Once decrypted, the file remains decrypted until you encrypt the file again.

Once a user has encrypted a file, decryption will never be necessary as long as the user is the only one that needs to access the file. The only reason a user might need to decrypt a file is when the user wants to share the file with another user or make the file available to users across the network.

Users can decrypt a file by either clearing the Encryption check box on the file's Properties dialog box, or using the cypher command.

By default, encryption provided by EFS is standard, 56-bit encryption. For additional security, North American users can obtain 128-bit encryption by ordering the Enhanced CryptoPAK from Microsoft. However, files encrypted with the Enhanced CryptoPAK cannot be decrypted, accessed, or recovered on a system that only supports 56-bit encryption.


Backing up and recovering encrypted data

Backing up, restoring, and recovering data

The main administrative tasks associated with the Encrypting File System (EFS) are backing up and restoring encrypted files, configuring a recovery policy, and recovering encrypted data.

Backing up and restoring encrypted files

Backup copies of encrypted files will also be encrypted, provided you use a backup program designed for Windows 2000.

When restoring encrypted data, the data will remain encrypted after the restore operation.

Recovering encrypted data

Data recovery refers to the process of decrypting a file without having the private key of the user who encrypted the file.

You might need to recover data with a recovery agent if:

  • A user leaves the company.
  • A user loses the private key.
  • A law enforcement agency makes a request.

To recover a file, the recovery agent:

  1. Backs up the encrypted files.
  2. Moves the backup copies to a secure system.
  3. Imports their recovery certificate and private key on that system.
  4. Restores the backup files.
  5. Decrypts the files, using Windows Explorer or the EFS cipher command.

Configuring a recovery policy

You can use the Group Policy snap-in to define a data recovery policy for domain member servers or for stand-alone or workgroup servers. You can either request a recovery certificate, or export and import your recovery certificates.

You may want to delegate administration of the recovery policy to a designated administrator. Although you should limit who is authorized to recover encrypted data, allowing multiple administrators to act as recovery agents provides you with an alternate source if recovery is necessary.


Resources

For additional information, see the following security-related resources:

  • Microsoft Security Advisory
  • Resources: Public Key Infrastructure


Troubleshooting

To help you troubleshoot specific problems that might arise, see the following topics:

  • Troubleshooting Encrypting File System
  • Troubleshooting Certificate Services
  • Troubleshooting IP Security
  • Troubleshooting Security Templates
  • Troubleshooting Security Configuration and Analysis


Troubleshooting Encrypting File System

What problem are you having?

Cannot encrypt a file.

Cause: Encrypting File System (EFS) only works on files and folders on NTFS file system volumes. In addition, it cannot encrypt any file that is a compressed file, a read-only file, or a system file.

Solutions:

  • If you have the proper permissions, you can uncompress the file.
    1. In Windows Explorer, right-click the name of the file, then click Properties.
    2. Click Advanced.
    3. In Compress or Encrypt attributes, clear the Compress contents to save disk space check box.
  • If you have the proper permissions, you can change the read-only property.
    1. In Windows Explorer, right-click the name of the file, then click Properties.
    2. In Attributes, clear the Read-only check box.
  • If it is a system file, you cannot encrypt the file.
  • If you notice that a new document you created or an attachment you opened in Microsoft Outlook is encrypted in a folder that is not an encrypted folder, check to see whether you have encrypted your Temp folder. Encrypting your Temp folder is recommended to ensure that your encrypted documents remain encrypted even during the editing process when some applications create temporary documents. However, some applications create new documents in the Temp folder by default. If you choose to save your document to another location on an NTFS volume, the document is encrypted in the new location.


Network Security

For problem-solving instructions on Internet Protocol security, see Troubleshooting.


Server roles

The requirements for securing data are partly determined by the intended role of the server that is managing or storing the data. Your infrastructure may only need a single Windows 2000 server to function in more than one capacity, or you may need to distribute these operations among a number of Windows 2000 servers. Each server's role or capacity generally warrants special or additional security considerations.

For a discussion of the primary types of roles for Windows 2000 servers, see Understanding server roles.


Network printers

Auditing enables you to track a printer's usage. For a particular printer, you can specify which groups or users and which actions to audit. You can audit both successful and failed actions. Windows NT stores the resulting audit information in the security log file, which you can view by using Event Viewer.


Active Directory security

Distributed security makes domain administration easier and more effective at a number of levels:

  • Authentication of users and computers is distributed across the enterprise.
  • Security credentials for users and computers are stored in Active Directory. Computers are authenticated when started.
  • Transitive trust, where security credentials valid for one domain are accepted by all other domains in the domain tree, is the default. This means that users authenticated for one domain are also authenticated in any other domains within the domain tree. However, you can define explicit trust relationships between domains where appropriate.
  • Single sign-on to the enterprise.

    Because security credentials are stored in Active Directory, users have a secure single sign-on to the enterprise.

  • All Active Directory objects are replicated to every domain controller in a domain.
  • Accounts, policies, and resources are managed and accessed at the nearest domain controller.
  • All Active Directory objects can inherit properties from their parent object.
  • Account and policy properties can be created at the group level and applied to all new and existing members.
  • Administrative responsibilities can be delegated to specific users or groups.

    By applying inheritance to the assignment of rights and permissions, you can distribute across enterprise management the administration of accounts, policies, and resources. The administrative component of your security policy can effectively parallel an organizational chart: a tree of administrators with a successively limited scope of authority.

  • Certificate-based authentication is used within the enterprise for connections via intranet or the Internet, and for logon with smart cards.

    Smart card users have a single sign-on to the domain.

  • Servers have the ability to authenticate on behalf of clients.

    Servers transparently impersonate clients when authenticating to other servers in a client transaction requiring multiple servers, and when acting on behalf of local (client) system services.


Network Policies

IPSec policies can be applied to Local or Group Policy (Active Directory objects). The IP Security Policy Management snap-in is designed to centrally manage policies, which are based on IP filtering methodologies. Default policies are provided which can be used as is, or modified to meet your needs, eliminating the need to create custom policies unless you have special requirements.

For more information, see IP Security.