Organizations that use Microsoft Exchange 2000 Server can face many different types of security risks. Features available in Microsoft Windows 2000 Server and Exchange 2000 Server help protect your organization from many of these security risks. Windows 2000 and Exchange 2000 also provide security features to help secure your connection to the Internet. Implementing these security features is important to securing your messaging system, and can prevent disruption of messaging for your users.

Security Risks

An Exchange organization can face many different types of attacks based on a variety of different factors. These factors can range from the type of data your users send, to the type of connections your network has. Without security measures and controls in place, your data might be subject to attacks. Some attacks are passive, meaning that information is monitored; whereas others are active, meaning that the information is altered with intent to corrupt or destroy the data on the network.

Table 30.1 lists the kinds of attacks your Exchange organization might face. Implementing one or more of the security measures described in this chapter can prevent each of these attacks. You should start by identifying which of these security risks is a threat to your organization.

Table 30.1 Potential security attacks 

Security Risk	Description
Identity interception	The intruder discovers the user name and password of a valid user. This can occur by a variety of methods, both social and technical.
Masquerade	An unauthorized user pretends to be a valid user. This could be a user who assumes the IP address of a trusted system and uses it to gain the access rights that are granted to the impersonated device or system.
Replay attack	The intruder records a network exchange between a user and a server and replays it at a later time to impersonate the user.
Data interception	Unauthorized users monitor and capture data moving across the network as plaintext.
Manipulation	The intruder modifies or corrupts network data. Unencrypted network financial transactions are vulnerable to manipulation. Viruses can corrupt network data.
Repudiation	Network-based business and financial transactions are compromised if the recipient of the transaction cannot be certain who sent the message.
Macro viruses	Application-specific viruses can exploit the macro language of sophisticated documents and spreadsheets.
Denial of service	The intruder floods a server with requests that consume system resources and either cause the server to stop responding or become too busy to process legitimate work. Causing the server to stop responding sometimes provides opportunities to penetrate the system.
Malicious mobile code	Malicious code runs as an auto-executed Microsoft ActiveX control or Java Applet uploaded from the Internet on a Web server.
Misuse of privileges	An administrator knowingly or mistakenly uses full privileges over the operating system to obtain private data.
Trojan horse	A malicious program that masquerades as a desirable and harmless utility.
Social engineering attack	The intruder breaks into a network by calling new employees, telling them they are from the IT department, and asking the user to verify their password for their records.

Windows 2000 Security Features

Windows 2000 Server offers you many different options for protecting your Exchange 2000 organization from the different types of possible attacks. The following are Windows 2000 Server features that relate to securing Windows 2000 Server and Exchange 2000 Server:

• Active Directory directory service 

• Access Control 

• Auditing 

• Kerberos 

• Certificate Services 

• Encrypting File System 

• Internet Protocol security (IPSec) 

• TCP/IP filtering 

• Security Configuration Tool Set 

Active Directory

The Windows 2000 Server Active Directory directory service replaces the Security Accounts Manager (SAM) in Microsoft Windows NT 4.0 as a security database. On Windows NT 4.0–based servers running Microsoft Exchange Server version 5.5, there are two different sets of objects. The directory structure in Exchange 5.5 is separate from the directory structure of Windows NT 4.0. Active Directory unifies these directories to reduce administrative tasks. A security identifier (SID) essentially links Active Directory objects used in Windows 2000 and Exchange 2000 Server.

Security Subsystem

Active Directory is part of a component called the security subsystem. Discretionary access control lists (DACLs) protect all objects in Active Directory. Any attempt to gain access to an object or attribute in Active Directory is validated against the DACL by access validation routines.

Windows 2000 Server security infrastructure has four main functions:

• It is a directory service store for security policies and account information. 

• It implements security models for all objects. 

• It authenticates Active Directory access. 

• It stores trust information for Active Directory. 

Local Security Authority

The security subsystem has several components, one of which is the Local Security Authority (LSA). LSA is a protected subsystem that maintains the security for the local computer. LSA ensures that users have system access permissions. In general, LSA performs the following functions:

• It generates tokens, which contain user and group information, and the security privileges for that user. 

• It manages local security policies. 

• It provides interactive user authentication services. 

• It manages the Audit policy and settings. 

When a computer running Windows 2000 Server is configured as a member of a domain, the system's LSA uses the domain's authentication services to authenticate users. These services are in addition to the system's own local account database. The system trusts the domain to provide accurate information about security principals on the network. Figure 30.1 illustrates the components and functions of the LSA.

Figure 30.1 Components of the LSA 

The following points describe each feature in Figure 30.1:

• Netlogon.dll The Net Logon service. Net Logon maintains the computer's secure channel to a domain controller. It passes the user's credentials through a secure channel to the domain controller and returns the domain SIDs and user rights for the user. In Windows 2000 Server, the Net Logon service uses Domain Name System (DNS) to resolve names to the Internet Protocol (IP) addresses of domain controllers. Net Logon is the replication protocol for Windows NT 4.0 primary domain controllers and backup domain controllers. 

• Msv1_0.dll The NTLM authentication protocol. This protocol authenticates clients that do not use Kerberos authentication. 

• Kdcsvc.dll The Kerberos Key Distribution Center (KDC) service, which is responsible for granting tickets to clients. 

• Schannel.dll The Secure Sockets Layer (SSL) authentication protocol. This protocol provides authentication over an encrypted channel instead of a less-secure clear channel. 

• Kerberos.dll The Kerberos V5 authentication protocol. 

• Lsasrv.dll The LSA server service, which enforces security policies. 

• Samsrv.dll The Security Accounts Manager (SAM), which stores local security accounts, enforces locally stored policies, and supports application programming interfaces (APIs). 

• Ntdsa.dll The directory service module, which supports the Windows 2000 Server replication protocol and Lightweight Directory Access Protocol (LDAP), and manages partitions of data. 

• Secur32.dll The multiple authentication provider that holds all of the components together. 

Groups in Active Directory

Active Directory provides support for different types of groups, in addition to offering options for the scope of a group—that is, whether the group spans multiple domains or is limited to a single domain.

Two group types exist in Active Directory: security groups and distribution groups. Each of these supports one of the three group scopes: domain local, global, or universal.

The domain mode limits the choice of group type and group scope.

Group Types

The equivalent of a distribution list in an earlier version of Exchange Server is called a group in Active Directory. There are two types of groups:

• Security groups Groups that can be used to administer permissions for users and other domain objects. These groups are used to grant permissions on the Exchange 2000 organization to administrators and users. 

• Distribution groups Groups that are used only for e-mail. 

Group Scope

Security and distribution groups have a scope attribute. The scope of a group determines who can be a member of the group and where you can use that group in the network. Three group scopes are available: domain local, global, and universal.

• Domain local groups Domain local groups can have as their members groups and accounts from a Windows 2000 Server or Windows NT domain. They can be used to grant permissions only within a domain. 

• Global groups Global groups can have as their members groups and accounts only from the domain in which the group is defined. They can be granted permissions in any domain in the forest. 

• Universal groups Universal groups can have as their members groups and accounts from any Windows 2000 Server domain in the domain tree or forest. They can be granted permissions in any domain in the domain tree or forest. 

Note If you have multiple forests, users defined in only one forest cannot be placed into groups in another forest. Likewise, if you define groups in one forest, they cannot be assigned permissions in another forest.

Table 30.2 Security group membership rules 

Domain Local Groups	Global Groups	Universal Groups
In native mode, domain local groups can have member accounts, global groups, and universal groups from any domain, and domain local groups from the same domain as members.	In native mode, global groups can have member accounts, and global groups from the same domain as members.	In native mode, universal groups can have member accounts, global groups, and universal groups from any domain as members.
Domain local groups can be put into other domain local groups and assigned permissions only in the same domain.	Global groups can be put into other groups and assigned permissions in any domain.	In native mode, universal groups can be put into other groups and assigned permissions in any domain.

Selecting a Group Scope

The global catalog maintains a list of universal group memberships. Global and domain local groups are listed in the global catalog, but their membership is not. Each change to the membership of a universal group is replicated to all global catalog servers. By minimizing the use of universal groups, you reduce the size of the global catalog, and reduce the amount of traffic on your network caused by replication of the global catalog.

• Limit membership in universal groups to other groups You can reduce replication network traffic by limiting membership in universal groups only to groups rather than individual accounts. To do this, you adjust the user accounts that are members of the universal group by adjusting the membership of the groups that are part of the universal group. This does not directly affect the membership of the universal group and does not generate replication network traffic. 

• Limit the use of universal groups Limiting the use of universal groups can help you to reduce the size of access tokens when resources are in different domains. If you use global and domain local groups, the access tokens contain the global and domain local groups that are applicable to the domain in which the resource exits. If you use universal groups, the access tokens contain a list of all the universal groups to which the user belongs, even if these universal groups are not used in that domain. 

Domain Local Groups

Domain local groups are best used for granting access rights to resources such as file systems or printers that are located on any computer in the domain where common access permissions are required. The advantage of using domain local groups to protect resources is that members of the domain local groups can come from both inside the same domain and outside the domain. Typically, resource servers are in domains that have trust to one or more Master User Domains, or what are known as account domains. You can use a domain local group to grant access to resources on any computer only in native mode domains. In mixed mode, domain local groups must be on domain controllers only. Table 30.3 outlines the advantages and disadvantages of domain local groups.

Table 30.3 Advantages and disadvantages of domain local groups 

Advantages	Disadvantages
Membership is not published to the global catalog server, which means that changes do not incur global catalog replication.	They cannot be assigned permissions to resources in other domains.
Microsoft Outlook clients can view full user membership if they are located in the same domain as the group.	Outlook users in other domains cannot view the full memberships.
	Group membership must be retrieved on demand if expansion takes places in a remote domain.

Global Groups

You use global groups for combining users who share a common access profile based on job function or business role. Typically, organizations use global groups for all groups in which membership is expected to change frequently. The members of these groups can only be user accounts defined in the same domain as the global group. You can nest global groups to allow for overlapping access needs or to scale for very large group structures. The most convenient way to grant access to global groups is by making the global group a member of a resource group that is granted access permissions to a set of related project resources. Table 30.4 outlines the advantages and disadvantages of global groups.

Table 30.4 Advantages and disadvantages of global groups 

Advantages	Disadvantages
Membership is not published to the global catalog server, which means that changes do not incur global catalog replication.	They can only contain objects from the same domain.
Outlook clients can view full user membership if they are located in the same domain as the group.	Outlook users in other domains cannot view the full memberships.
They can be used for assigning permissions to resources in the same domain.	Group membership must be retrieved on demand if expansion takes place in a remote domain.

Universal Groups

You use universal groups in larger, multi-domain organizations where you need to grant access to similar groups of accounts defined in multiple domains. It is better to use global groups as members of universal groups to reduce overall replication traffic from changes to universal group membership. You can add and remove users from the corresponding global group within their account domains. A small number of global groups are the direct members of the universal group. You can easily grant access permissions to universal groups by making them a member of a domain local group, which grants access permissions to resources. Table 30.5 outlines the advantages and disadvantages of universal groups.

Table 30.5 Advantages and disadvantages of universal groups 

Advantages	Disadvantages
Membership can consist of any object in the forest.	Membership modifications incur replication to the global catalog servers.
Outlook users in any domain can view full membership.
Membership never has to be retrieved from remote domain controllers.

Designing a Group Implementation Strategy

The type and scope of group that you implement for Exchange 2000 depends upon your business and user requirements. To optimize flexibility, you can implement universal security groups. You can mail-enable the universal group and view it in the global address list by adding a Simple Mail Transfer Protocol (SMTP) e-mail address.

However, a disadvantage of using universal groups is that membership is fully populated to every global catalog server, which causes replication network traffic when membership changes. For this reason, groups that might have frequent membership changes should be domain local or global groups. Because membership for these group types is not promoted to the global catalog servers, when a message is sent to the group from a remote domain, the expansion server must connect to a domain controller within the home domain for the group and retrieve the membership. This configuration has the following effects:

• The expansion server must have an IP connection to a domain controller in the remote domain. 

• Retrieving membership from a remote domain can take time and slow down message delivery, which in turn can slow performance for the retrieving server. 

  Note If an Exchange server already exists in the remote domain, it might be more efficient to set the expansion server to that server instead of remotely retrieving the membership. For more information about setting expansion servers, see Exchange 2000 Server Help. 

You must decide whether it is better to create a universal group for the list or use domain local or global groups and accept the membership retrieval for remote domains whenever the list needs to be expanded. Consider the following for each configuration:

Note When implementing domain local or global groups, Outlook users cannot view the user membership of the group unless the domain local or global groups are also contained within the local domain.

Access Control

Along with user authentication, Windows 2000 Server allows you to control access to resources, or objects, on the network. Windows 2000 Server implements access control by allowing you to assign security descriptors to objects stored in Active Directory. A security descriptor lists the users and groups that have access to an object, and the specific permissions assigned to those users and groups. A security descriptor also specifies the various access events to audit for an object.

How Access Control Works

Access control works in the following way: a program with threads of execution works on a file. The program runs as a process with threads of execution. It is actually one of those threads that opens the file. Threads are the only real agents of action on a computer.

For a thread to gain access to an object, it must identify itself to the operating system's security subsystem. A thread does not have a security identity, so it must borrow one from a security principal, such as the user. When the user logs on, the user's security identity is encapsulated in an access token that is associated with the user's logon session. When a user starts an application, the application runs as a process within the user's logon session. The application process and each of its threads of execution receive copies of the user's access token. When one of the application's threads needs to open a file, the thread identifies itself as the user's agent by presenting its access token. Thus responsibility for anything that the thread does to the file on the user's behalf is charged to the user.

Threads do not open files in the same way that users do. Threads are pieces of program code that execute on the computer, and they interact with objects through one of several APIs provided by the operating system. If a thread's job is to open a file, its code might contain the following instruction:

hfile=CreateFile(pszFile,GENERIC_WRITE,0,NULL,OPEN_EXISTING,0,NULL); 

The second argument in the call to CreateFile specifies a desired set of access rights, GENERIC_WRITE, which indicates to the operating system that the thread wants to open the file and modify it. Other APIs work in a similar fashion. The caller must signal its intentions for an object by specifying the level of access that it wants.

Before allowing the thread of execution to proceed, Windows 2000 performs an access check to determine whether the security principal associated with the thread has the level of access authorization that the thread has requested. An access check compares information in the thread's access token with information in the object's security descriptor:

• The access token contains a SID that identifies the user associated with the thread and SIDs that identify the groups whose members include the user. 

• The security descriptor contains a DACL with access control entries (ACEs) that specify the access rights allowed or denied to specific users or groups. 

The security subsystem checks the object's DACL, looking for ACEs that apply to the user and group SIDs from the thread's access token. It steps through each ACE until it finds one that either allows or denies access to the user or one of the user's groups, or until there are no more ACEs to check. If it comes to the end of the DACL and the thread's desired access is still not explicitly allowed or denied, the security subsystem denies access to the object. Figure 30.2 illustrates this process.

Figure 30.2 Security subsystem check 

The order in which ACEs are listed in a DACL is important. For example, an object's DACL might contain one ACE that allows access to a group and another ACE that denies access to a user who is a member of the group. If access checking reaches the ACE that allows access to the user's group before it reaches the ACE that denies access to the user, the user is allowed to access the object. This is clearly not a wanted outcome.

In general, ACEs are listed in what is called canonical order, which places the Deny ACEs before the Allow ACEs. When the canonical order is used, an access check processes all ACEs that deny access before any ACE that allows access.

The canonical order described earlier is simplified somewhat for the purpose of this overview. It does not, for example, account for the ordering of ACEs inherited from a parent object. For the precise canonical order, see the Windows 2000 Server Resource Kit Distributed Systems Guide.

Exchange 2000 Access Control Model

The access control model used in Exchange 2000 Server follows that of Windows 2000 Server. The new access control model differs completely from the model used in Exchange 5.5 and allows greater access control. In Exchange 5.5, access control is based on a container-level grant, whereas Exchange 2000 allows you to set access control at the container, item, or property level.

Auditing

Security auditing is a feature of Windows 2000 Server 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 you can audit is a failed logon attempt.

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

The Windows 2000 Server auditing feature generates an audit trail to help you keep track of all security administration events that occur on the system. For example, if you change the auditing policy so failed logon attempts are not audited, the audit trail shows this event. For more information about how to enable auditing in Windows 2000 Server, see Windows 2000 Server Help.

How Auditing Works

You can specify that an audit entry is written to the security event log whenever certain actions are performed or files are accessed. The audit entry shows the action performed, the user who performed it, and the date and time of the action. You can audit both successful and failed attempts at actions, so the audit trail can show who performed actions on the network and who tried to perform actions that are not permitted. You can view the security log in Event Viewer.

If you examine the security log regularly, you can detect some types of attacks before they succeed, such as password attacks. After a break-in, the security log can help you determine how the intruder entered the system and what they did.

Audit logging is a policy in its own right. Recording security events is a form of intrusion detection.

Auditing Exchange Active Directory Objects

Security auditing is not enabled by default. You have to activate the types of auditing you require by using the Group Policy snap-in to Microsoft Management Console (MMC).

By setting auditing on Exchange objects, such as stores and servers, you can track configuration changes to your Exchange 2000 server in the Windows 2000 Server event logs. You can audit changes in an Exchange object's configuration, permissions, or ownership. You can also perform an audit to check whether an object is written to, read, or deleted.

For more information about enabling auditing on your Exchange 2000 server, see Exchange 2000 Server Help.

Kerberos

Kerberos is the fundamental security protocol in Windows 2000 Server. Kerberos provides secure communication between Windows 2000 Server domains and clients, and is integrated into the administrative and security model.

How Kerberos Works

The Kerberos V5 authentication mechanism issues tickets for accessing network services. These tickets contain encrypted data, including an encrypted password, which confirms the user's identity to the requested service. Except for entering a password, 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. Figure 30.3 illustrates how the Kerberos V5 authentication process works.

 

Figure 30.3 The Kerberos V5 authentication process 

The Kerberos V5 authentication process performs the following steps:

1. The user on a client system, using a password, authenticates to the KDC. 

2. The KDC issues a special ticket-granting ticket (TGT) 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. The TGS then issues a service ticket to the client. 

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

4. The user on the client successfully authenticates with the requested network service. 

Kerberos and Exchange

Exchange 2000 runs as a service in Windows 2000 Server and is treated as a network service with respect to Kerberos. When the client needs to access Exchange, the client requests an Exchange service ticket from the Kerberos service. The service ticket is then used for authentication with Exchange 2000 Server. For subsequent access to the Exchange 2000 server, the client uses the service ticket, which increases authentication performance.

Kerberos Delegation of Authentication

If a client has already authenticated to a server, the server needs to make a request to another server, before the first can request the ticket on behalf of the client. The Windows 2000 Server Kerberos service supports delegation of authentication. Authentication across different domains is also possible, provided there is a trust relationship.

You can perform delegation in two ways. One way is for the client to get a session ticket for the back-end server and give it to the front-end server. Tickets obtained in this way—by a client for a proxy—are called proxy tickets. The difficulty with using proxy tickets is that the client must know the name of the back-end server. This difficulty is overcome by the second method of delegation, which allows the client to give the front-end server a TGT that the front-end server can use to request session tickets for the back-end server, as needed. Session tickets obtained in this way—with credentials forwarded by a client—are called forwarded tickets. Whether the KDC allows clients to obtain proxy tickets or forwarded TGTs is determined by the Kerberos policy set by an administrator for the domain.

Kerberos delegation is a property that you can set on the computer account in Active Directory. When the account is trusted for delegation, any computer can forward the credentials of the account. For more information about enabling a computer account for delegation, see Windows 2000 Server Help.

Delegation of Authentication in Exchange

Figure 30.4 is an example of how Exchange 2000 Server uses Kerberos delegation of authentication in a front-end/back-end Outlook Web Access environment.

 

Figure 30.4 Delegation of authentication in Exchange 

The Outlook Web Access deployment consists of a front-end and back-end Exchange 2000 Server, a computer running Windows 2000 Server in the same domain, and a client to make the requests. The front-end Exchange 2000 Server receives requests from clients and proxies them to the back-end server. The computer running Windows 2000 Server in the same domain functions as the Kerberos KDC. The following is an example of delegation of authentication in this environment.

1. The user on a client system, using a password, authenticates to the KDC. The KDC issues to the client a TGT that can be forwarded. 

2. The client system uses this TGT that can be forwarded 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 forwarded service ticket to the client. 

4. The user on a client system presents the forwarded ticket to the front-end server. 

5. The front-end server presents the client's TGT—which can be forwarded—to the KDC. When the KDC issues a session ticket for the back-end server, it sees the FORWARDABLE flag in the TGT, sets the FORWARDED flag in the session ticket for the requested server, and returns the session ticket to the front-end server. 

6. The front-end server authenticates with the back-end server on behalf of the client. 

Note This example assumes that all servers are running Windows 2000 Server, and that all clients are running Windows 2000 Professional.

Certificate Services

Certificate Services provides customizable services for issuing and managing certificates used in software security systems that employ public key technologies. For more information about public key cryptography and the benefits of having a public key infrastructure (PKI), see Windows 2000 Server Help.

You can use Certificate Services in Windows 2000 Server to create a certification authority (CA), which receives certificate requests, verifies the information in the request and the identity of the requester, issues certificates, revokes certificates, and publishes a certificate revocation list (CRL). Certificate Services is a Windows 2000 Server security feature that is required to use the Key Management Service (KMS) in Exchange 2000. For more information about KMS, see "Key Management Service" later in this chapter.

Certificate Service and Active Directory

The user tabs in the Active Directory Users and Computers snap-in contain security options for each user such as Enable, Revoke, and Recover certificates.

Note Every time the computer running Windows 2000 Server starts, and every 24 hours thereafter, all certificates are downloaded and added to the root store.

Encrypting File System

The Encrypting File System (EFS) is a feature of Windows 2000 Server that allows users to encrypt data directly on volumes that use NTFS file system. EFS operates by using certificates based on the X.509 standard. If no certification authority is available from which to request certificates, the EFS automatically generates its own self-signed certificates for users and default recovery agents.

The EFS supports transparent encryption and decryption of files stored on a hard disk in NTFS. A recovery policy is automatically implemented when users encrypt a file or folder for the first time. This ensures that users who lose there file encryption certificates and associated private keys can use a recovery agent to decrypt their files.

EFS is useful for mobile users who need to encrypt files or folders, such as personal mail. If the user's portable computer is lost, the data cannot be read.

Disabling EFS for All Computers in a Windows 2000 Domain

You might want to prevent users from encrypting data on their workstations. You can do this by modifying a controlling Group Policy object on domain clients, or on local computers by modifying a local Group Policy object. To disable EFS throughout a Windows 2000 domain, modify the "Default Domain Policy" Group Policy object.

To modify a Group Policy object and disable EFS throughout a Windows 2000 domain 

1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers. 

2. Right-click the appropriate node for your domain, and then click Properties. 

3. Click the Group Policy tab, click the Default Domain Policy Group Policy object, and then click Edit. You do not need to use the Default Domain Policy; you can use a new Group Policy object such as Disable EFS to accomplish the same task. 

4. In the Group Policy Editor snap-in, view the following node: 

   Default Domain Policy\Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Encrypted Data Recovery Agents 

5. If any certificates exist in the details pane, delete them. 

6. Right-click the Encrypted Data Recovery Agents node, click Delete Policy, and then click Yes. 

7. Right-click the Encrypted Data Recovery Agents node, and then click Initialize Empty Policy. 

Users on client workstations to which this policy is applied cannot encrypt files or folders. Also, if users attempt to apply encryption attributes, they receive the following error message:

Error Applying Attributes 
An error occurred applying attributes to the file:
file name
There is no encryption recovery policy configured for this system.

A data recovery policy must be present to use EFS. A data recovery policy configured as Empty is not treated the same as one configured as No Policy. Deleting a policy and setting it to No Policy enables the default local policy on computers. This permits users who are local administrators to control the recovery of data on their computer. Setting a policy to Empty turns EFS off, so users cannot encrypt files on computers that fall into this category. Because policies are cumulative, enforcing an Empty policy at the domain level ensures that all Windows 2000 domain clients are denied EFS capabilities.

EFS Limitations

When an encrypted file leaves the hard disk, it is no longer encrypted. When a user sends a file as an attachment, the file is not encrypted. Files transferred over the network will require Internet Protocol security (IPSec) to maintain encryption. EFS encrypts files on the hard disk so when the directory is opened for sharing, the files cannot be read. When a legitimate user runs an application that retrieves a file from the hard disk, the file is decrypted.

Internet Protocol Security

IPSec is a framework of open standards for ensuring private, secure communications over IP networks, by using cryptographic security services. IPSec is based on standards developed by the Internet Engineering Task Force (IETF) IPSec work group.

Although Certificate Services and KMS provide security on the application layer, IPSec provides security on the IP transportation layer (that is, Layer 3). IPSec also provides protection for the TCP/IP protocol stack, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), and other protocols that send traffic at the IP layer. IPSec communication can transmit in blocks of data, with each block secured by a different key. This prevents an attacker from obtaining an entire communication with a single compromised key.

• For complete information about IPSec and IPSec planning, see the Windows 2000 Server Resource Kit TCP/IP Core Networking Guide. 

Layer 3 Protection

Security mechanisms that operate above Layer 3, such as Secure Sockets Layer (SSL), can only provide security to applications that can use SSL. An example of this type of application is a Web browser.

Using security at Layer 3 provides protection for all IP and upper layer protocols in the TCP/IP protocol stack. The primary benefit of securing information at a lower layer is that IPSec can protect all applications and services that use IP to transport data, such as Exchange 2000, without any modification to the applications or services. IPSec security at Layer 3 secures messages between Exchange 2000 servers in a way that is transparent to the servers. Figure 30.5 illustrates Layer 3 Protection.

Figure 30.5 Layer 3 protection 

The IPSec Model

IPSec is based on an end-to-end security model, meaning that the only computers that must know about the traffic being secured are the sending and receiving computers. Each handles security at its respective end, with the assumption that the medium over which the communication takes place is not secure. Figure 30.6 is an example Exchange organization using IPSec to secure its intranet messaging.

Figure 30.6 Exchange organization using IPSec to secure its intranet messaging 

To secure its intranet messaging, Exchange uses IPSec in the following steps:

1. Exchange Server A sends a message to Exchange Server B. 

2. The IPSec driver on server A checks its stored IP Filter Lists to see whether the packets should be secured. 

3. The driver notifies Internet Key Exchange to begin negotiations. 

4. The Internet Key Exchange service on server B receives a message requesting secure negotiation. 

5. The two computers establish a Phase I security association (SA) and shared master key. 

6. A pair of Phase II SAs are negotiated: one inbound SA, and one outbound SA. The SAs include the keys used to secure the information, and the Security Parameters Index. 

7. The IPSec driver on server A uses the outbound SA to sign and encrypt the packets. 

8. The driver passes the packets to the IP layer, which routes the packets toward server B. 

9. Server B's network adapter driver receives the secure IP packets and passes them to the IPSec driver. 

10. The IPSec driver on server B uses the inbound SA to check the integrity signature and decrypt the packets. 

11. The driver passes the decrypted packets up to the TCP/IP driver, which passes them to the receiving Exchange 2000 Server virtual server. 

Note Any routers or switches in the data path between the communicating computers will forward the secure IP packets to their destination. However, if there is a firewall, security router, or proxy server, it must have IP forwarding enabled, so that IPSec and Internet Key Exchange protocol traffic can pass through a network address translator. The Internet Key Exchange negotiation contains IP addresses in the encrypted messages, which a network address translator cannot change because the integrity hash is broken, or because the packets are encrypted.

TCP/IP Filtering

Windows 2000 Server includes support for TCP/IP filtering, using the TCP/IP filtering feature. TCP/IP filtering allows you to specify exactly which types of incoming IP traffic are processed for each IP interface. This feature isolates the traffic that Internet and intranet servers process in the absence of TCP/IP filtering provided by Routing and Remote Access or other TCP/IP applications or services. TCP/IP filtering is disabled by default.

You can enable or disable TCP/IP filtering for all adapters using a single check box. Figure 30.7 shows the TCP/IP filtering dialog box, which you use to enable or disable TCP/IP filtering.

Figure 30.7 TCP/IP Filtering dialog box 

You can troubleshoot connectivity problems that might relate to filtering by using the TCP/IP filtering feature. Filters that are too restrictive might not allow the kinds of connectivity that you expect. For example, if you specify a list of UDP ports and do not include UDP port 520, your computer does not receive Routing Information Protocol (RIP) announcements. This can impair the computer's ability to be a RIP router or a silent RIP host when using the RIP Listener service.

A packet is accepted for processing if it meets one of the following criteria:

• The destination TCP port matches the list of TCP ports. By default, all TCP ports are permitted. 

• The destination UDP port matches the list of UDP ports. By default, all UDP ports are permitted. 

• The IP protocol matches the list of IP protocols. By default, all IP protocols are permitted. 

• It is an ICMP packet. 

Security Configuration Tool Set

The Security Configuration Tool Set is comprised of two tools: the Security Configuration and Analysis tool, and the Security Templates tool. You can use these tools to analyze and configure security policies for your Exchange organization.

Security Configuration and Analysis uses a database to perform analysis and configuration functions. The database architecture allows you to use personal databases, import and export security templates, and combine multiple base security templates into one composite security template that you can use for analysis or configuration. The security templates feature allows you to use security templates you define or existing security templates provided with Windows 2000 Server.

The security configuration and analysis database is a computer-specific data store. The database is the starting point for security analysis and configuration. You can incrementally add new security templates to the database and create a composite security template. You can also create personal databases for storing your own customized security templates.

Security Configuration

You can use the Security Configuration and Analysis tool to directly configure local system security. The tool uses personal databases, which allows you to import security templates created with the Security Templates tool, and apply these templates to the Group Policy object for the local computer. This immediately configures the system security with the levels specified in the template.

Security Templates

Windows 2000 Server provides a centralized method of defining security with the Security Template tool. It is a single point-of-entry where you can view the full range of system security settings, which are adjusted and applied to a local computer or imported to a Group Policy object. The Security Templates tool does not introduce new security parameters—it only organizes all the existing security attributes into one place to ease security administration. You can use the Security Templates tool as a base configuration for security analysis when you use it with the Security Configuration and Analysis tool.

You can create your own security template or use a Windows 2000 predefined security template. Windows 2000 Server includes several incremental security templates. By default, these templates are stored in %SystemRoot%\Security\Templates.

You can customize these predefined templates by using the Security Templates tool and you can import them into the Security Settings extension of the Group Policy snap-in.

Caution These security templates are constructed with the assumption that they apply to computers running Windows 2000 Server that use the default security settings for Windows 2000 Server. You cannot secure computers running Windows 2000 Server that are installed on file allocation table (FAT) file systems. You should not apply predefined security templates to production systems without testing to ensure that it maintains the correct level of application features for your network and system architecture.

The templates provided with Windows 2000 Server are designed to provide a starting point for configuring security based on the planned usage of the computer running Windows 2000 Server. To fully use the Security Configuration Tool Set you should do the following:

• Use the template that closest matches your organization's security policies as a base template for configuring security on Exchange 2000 servers. 

• Investigate security settings specific to your organization. 

• Expand your base template to include security settings specific to your organization. 

• Save your updated version of the base template for quick configuration of new or restored Exchange 2000 servers. 

Table 30.6 outlines the predefined Windows 2000 Server security templates.

Table 30.6 Predefined Windows 2000 Server security templates 

Template	Description
Basic (basic*.inf)	The basic configuration templates can reverse the application of a different security configuration. The basic configurations apply the Windows 2000 Server default security settings to all security areas except those pertaining to user rights. The Basic template does not modify user rights settings because application setup programs commonly modify user rights to enable successful use of the application. It is not the intent of the basic configuration files to undo such modifications.
Compatible (compat*.inf)	The default Windows 2000 Server security configuration gives members of the local Users group strict security settings, while members of the local Power Users group have security settings that are compatible with Windows NT 4.0 user assignments. This default configuration enables certified Windows 2000 Server applications to run in the standard Windows 2000 Server environment for Users, while still allowing applications that are not certified for Windows 2000 Server to run successfully under the less secure Power Users configuration. However, if Windows 2000 Server users become members of the Power Users group in order to run applications not certified for Windows 2000 Server, this may be too permissive for some environments. Some organizations might prefer to assign users, by default, only as members of the Users group and then decrease the security privileges for the Users group to the level where applications not certified for Windows 2000 Server run successfully. The compatible template is designed for such organizations. By lowering the security levels on specific files, folders, and registry keys that are commonly accessed by applications, the Compatible template allows most applications to run successfully under a User context. In addition, because it is assumed that the administrator applying the Compatible template does not want these users to be Power Users, all members of the Power Users group are removed.
Secure (secure*.inf)	The Secure template implements recommended security settings for all security areas except files, folders, and registry keys. It does not modify these because file system and registry permissions are configured securely by default.
Highly secure (hisec*.inf)	The Highly secure templates define security settings for Windows 2000 Server network communications. The security areas are set to require maximum protection for network traffic and protocols used between computers running Windows 2000 Server. As a result, such computers configured with a Highly secure template can only communicate with other computers running Windows 2000 Server. They will not be able to communicate with computers running Microsoft Windows 95, Microsoft Windows 98, or Windows NT. As a result, the Highly secure templates should be used only with Exchange deployments running in native mode.
Dedicated Domain Controller (dedica*.inf)	Local user security on domain controllers running Windows 2000 Server is not secure by default. Although it is not recommended, this allows you to run existing server-based applications on domain controllers in a way that is compatible with earlier versions of Windows. If you do not run server–based applications on domain controllers, as recommended, you can define the default file system and registry permission for the local Users group in the same way as the default permissions for workstations and stand-alone servers running Windows 2000. When you implement a dedicated security template, the security settings for local Users on Windows 2000 domain controllers are applied.

Analyzing Security

The Security Configuration and Analysis tool performs security analysis by comparing the current state of system security against a security template that you import to a personal database. This template is the base configuration, and it is the template that contains your preferred or recommended security settings for that system.

Security Configuration and Analysis queries the system's security settings for all security areas in the base configuration. Values found are compared to the base configuration. If the current system settings match the base configuration settings, it is assumed that they are correct. If not, the attributes in question display as potential problems that you need to investigate.

You can create personal databases into which you can import templates for analysis. You can repeat the import process and load multiple templates. The database merges the various templates to create a composite template that resolves conflicts in the order of their importance; the most recently–imported template takes precedence when there is a conflict. After the templates are imported to the selected database, you can analyze or configure the system. For more information about the Security Configuration and Analysis tool, see Windows 2000 Server Help.

Exchange 2000 Security Features

Exchange 2000 Server provides security features specifically for securing messages. These features can secure messaging between users, help deter unsolicited e-mail, separate administrative abilities in your organization, and give users secure methods of communicating with Exchange 2000 Server. The main security features of Exchange 2000 are as follows:

• Key Management Service 

• Virtual server security 

• Permissions 

• Securing client and server communication 

Key Management Service

The KMS is a service of Exchange 2000 Server that uses Windows 2000 Certificate Services to provide secure messaging. KMS uses a variety of cryptographic technologies and methods. With the increasing need to communicate mission–critical data over public networks such as the Internet, it is important to keep data private. Cryptography is a way to protect data, thus keeping data private. However, keeping data private is only a part of cryptography. There are several other features of cryptography, which are discussed the following sections. The main KMS features are as follows:

• Encryption 

• Hash functions 

• Ciphers 

• Algorithms 

• Certificate Services and the Key Management Service 

For more information about the Key Management Service, see Exchange 2000 Server Help.

Encryption

Encryption is the mathematical transformation of data from a readable, clear text form, into an unreadable, cipher text form. The transformation generally requires additional secret information available only to the sender and intended recipient. This information is called a key. The key allows the message to be encrypted by the sender, and decrypted only by the intended recipient. Decryption is the opposite of encryption—it transforms unreadable, cipher text data back into readable, clear text form.

Using cryptography provides not only privacy, but it provides an identity every time a user logs on to a network, accesses voice mail, or uses a user name and password to access anything. This identification is called authentication. Authentication is a crucial part of network data security.

As electronic transaction use increases over networks, it is important to sign documents electronically. Cryptography provides the ability to create digital signatures, which in many cases are as legally binding as a written one.

Hash Functions

A hash function provides a means of computing an electronic fingerprint, or checksum of a message. This electronic fingerprint is called the hash of a message.

Hashing secures messages and private key data by using them as elements in a mathematical function that creates a checksum of the package. The algorithm then is used on the receiving end to decrypt the message. Hashes typically compute quickly, and are designed so that every imaginable message can have a unique hash. Hash algorithms include MD-4, MD-5, and SHA-1.

Ciphers

A cipher is a mathematical function for encrypting and decrypting data. It is performed on readable clear text data to convert it to an unreadable version called cipher text. There are four types of ciphers: symmetric, asymmetric, block, and stream.

• Symmetric cipher Symmetric, or shared-key, ciphers are a form of data encryption in which a single key, known by the sender and the recipient, is used to encrypt and decrypt a message. While this form of encryption is efficient and effective, it is often difficult to share the key between both parties in a secure manner. It requires that the sender communicate the key to the recipient in a secure way. 

• Asymmetric cipher The asymmetric cipher, or public-key cipher, is a means of solving the key management problem of symmetric key encryption. This system involves using two keys, one for encryption, and the other for decryption. One of the keys is called the public key, and the other is called the private key. You can use either the public or private key for encryption, and you use the opposite key for decryption. The public key is placed in a directory, or a location available to other users, but the private key is kept in a secure location, and is available only to the owner of the key pair. By using an asymmetric cipher, the sender and recipient do not need to agree on a key before sending data. 

• Block cipher A block cipher uses shared-key encryption. It takes a message and breaks it into fixed length blocks, and applies the shared-key to each block. In most cases, this block size is 64 bits. The decryption operation takes the encrypted blocks, decrypts each with the same shared-key, and rebuilds the original message. 

• Stream cipher A stream cipher is another use of symmetric encryption. Stream ciphers process small units of plaintext, usually bits. Stream ciphers are much faster than block ciphers, and can be applied to data as it is sent or received. You do not need to know the size of the message, or receive the entire message before beginning to decrypt the message. This is useful for encrypted conversations over a network such as SSL rather than individually–encrypted messages. 

Algorithms

Exchange 2000 Server can use any of the following encryption algorithms:

• CAST-64 

• CAST-40 

• DES 

• 3DES 

• RC2-128 

• RC2-64 

• RC2-40 

Certificate Services and the Key Management Service

Exchange 2000 KMS uses Certificate Services to provide security on the application layer of the messaging system. It produces X.509v3 user certificates that Exchange 2000 and Outlook 2000 use for digital signature and encryption. The X.509v3 user certificates are recognized by Secure/Multipurpose Internet Mail Extension (S/MIME) clients and ensure interoperability among different clients when used across the Internet.

Note The Enroll Agent (Computer), Exchange User, and Exchange User Signature templates of the CA must be enabled before KMS installs.

KMS can be configured to require more than one administrator to be present before performing each KMS task. Each task is initially configured to require only one password, and the first password is always "password" until it is changed.

KMS implements a dual-key architecture, which gives each enrolled user two key pairs and certificates, one used for encryption, and the other used for signing. KMS uses this architecture so the signing key does not need to be archived in KMS.

Earlier versions of KMS restricted KMS to just one server per site. However, Exchange 2000 KMS fits the site-based model. The KMS organizational unit becomes the Administrator Group and each new administrator group created allows KMS to install on or point to an existing KMS server. You can also enroll users in bulk by enrolling selected users, groups, or servers.

Caution When you implement encryption on the application layer, content filtering or virus checking across gateways is compromised.

Virtual Server Security

Exchange 2000 Server allows you to control which users can connect to your virtual servers by explicitly allowing or denying connections for IP addresses or domains. Exchange 2000 Server also allows you to view the transactions your virtual servers are involved with to help you identify attacks.

Virtual Server Connection Control

Controlling connections to virtual servers can prevent many of the possible network attacks listed earlier in this chapter. You can selectively include or exclude single computers, subnets, and entire domains from accessing a virtual server. By default, all computers are allowed access until you add them to a list of restricted computers. You can restrict access to a virtual server by either listing a few computers that can access the server, or by specifying a group of computers that cannot.

For example, if logging is enabled on your SMTP virtual server, you can log the IP address of the connecting client. If your Exchange server is receiving unsolicited mail from this client, for example from the IP address 172.16.0.1 as illustrated in Figure 30.8, you can deny connections to your SMTP virtual server from the client's IP address, subnet, or domain. Connection control is available on any virtual server residing on your Exchange 2000 Server except for the HTTP virtual server. For more information about how to enable connection control, see Exchange 2000 Help.

 

Figure 30.8 Connection Control dialog box 

Protocol Logging

By setting the configuration properties of the virtual server associated with each messaging transport protocol, you can protect your e-mail system in multiple ways. The Internet protocols (SMTP, HTTP, and NNTP) enable you to use logging to track the commands the virtual server receives from clients. For example, for each message, you can see the client IP address, client domain name, date and time of the message, and number of bytes sent. Table 30.7 shows the variables that can be logged during an SMTP session.

Table 30.7 Variables that can be logged during an SMTP session 

Field	Log Field	Description
Date	Date	Connection date
Time	Time	Connection time
Client IP Address	c-ip	IP address of the client that accessed the server
Client domain name	cs-username	Client that accessed the server
Service Name	s-sitename	IIS service
Server Name	s-computername	Server on which the log entry was generated
Server IP	s-ip	IP address of the server on which the log entry was generated
Method	Cs-method	SMTP protocol command sent by the client
URI Stem	cs-uri-stem	Not applicable to SMTP Service
URI Query	cs-uri-query	Varies for SMTP; depends on the SMTP protocol command
HTTP Status	sc-status	SMTP protocol reply code
Win32 Status	sc-win32-status	Windows 2000 Server status or error code; 0 indicates success
Bytes Sent	sc-bytes	Bytes sent by the server
Bytes Received	cs-bytes	Bytes received by the server
Time Take	time-taken	Length of time the action took, in milliseconds
Server Port	s-port	Not applicable to SMTP Service
User Agent	cs(User-Agent)	Not applicable to SMTP Service
Cookie	cs(Cookie)	Not applicable to SMTP Service
Referrer	cs(Referrer)	Not applicable to SMTP Service

The following is an example of log entries by an SMTP server with logging enabled. The example shows the commands used in a session to send an e-mail message. The fields used that are defined in the previous table are c-ip, cs-username, s-sitename, cs-method, sc-status, sc-bytes, and cs-bytes.

#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 2000-01-13 20:52:07
#Fields: c-ip cs-username s-sitename cs-method sc-status sc-bytes cs-bytes
172.30.180.92 username SMTPSVC1 HELO 250 67 12 
172.30.180.92 username SMTPSVC1 MAIL 250 61 49
172.30.180.92 username SMTPSVC1 RCPT 250 49 47
172.30.180.92 username SMTPSVC1 DATA 250 143 1268
172.30.180.92 username SMTPSVC1 QUIT 0 88 4

When used with Windows 2000 Server event logs, the protocol log enables you to audit use of the virtual server and identify problems.

Note The default Web site provided by Internet Information Services (IIS) appears in Exchange under the HTTP protocol as Exchange Virtual Server. You cannot manage this virtual server from System Manager. It must be administered in IIS.

Permissions

Exchange 2000 Server installs with various predefined permissions for groups of users that are reserved for administering Exchange and the Windows 2000 Server organizations. Within these groups are various levels of administrative permissions that can help you assign appropriate permissions to the users who are responsible for different administrative duties. Exchange 2000 Server setup also provides you alternative methods to install Exchange 2000 Server to accommodate for the typical separation of permissions between network administrators and messaging administrators found in some organizations.

Predefined Permissions

Many different types of permissions exist that you can grant on a per-user or per-group basis. Table 30.8 shows five predefined user groups with permissions already granted. These permissions have been granted on the Exchange organization.

Table 30.8 Predefined user groups with permissions already granted 

Permission	Administrators	Authenticated Users	Domain Admins	Enterprise Admins	Exchange Domain Servers
Full Control	Yes	No	No	Yes	No
Read	Yes	No	Yes	Yes	Yes
Write	Yes	No	Yes	Yes	No
Create All Child Objects	Yes	No	Yes	Yes	No
Delete All Child Objects	Yes	No	No	Yes	No
Administer Information Store	Yes	No	Yes	Yes	No
Create Named Properties in the Information Store	Yes	No	Yes	Yes	No
Create Public Folder	Yes	No	Yes	Yes	No
Create Top Level Public Folder	Yes	No	Yes	Yes	No
Modify Public Folder Admin ACL	Yes	No	Yes	Yes	No
Modify Public Folder Replica List	Yes	No	Yes	Yes	No
View Information Store Status	Yes	No	Yes	Yes	No

Note Domain Admins is the Domain Admins group for the root domain in the forest. The permissions for Enterprise Admins and Domain Admins are inherited from the parent container.

Exchange Administration Delegation Wizard

The Exchange Administration Delegation Wizard helps you delegate control of Exchange configuration objects in Active Directory. By using the Exchange Administration Delegation Wizard, you can assign the task of managing different parts of Exchange to different users. You assign these tasks by assigning roles to users.

Exchange Full Administrator

The Exchange Full Administrator role grants the user permission to fully administer Exchange system information and modify permissions. Users assigned this role will have full control of the Exchange organization.

Exchange Administrator

The Exchange Administrator role grants the users permission to fully administer Exchange system information, but not modify permissions. This role may be useful for support staff who are required to administer the Exchange organization, but do not need to modify permissions.

Exchange View Only Administrator

The Exchange View Only Administrator role grants the user permission to view Exchange configuration information. This role may be useful where support staff need to view Exchange information, but do not need permission to change it.

Levels of Administration

One way to organize Administrator groups and easily grant the appropriate permissions is to create groups of administrators who have the same access privileges. The three levels of administration that should meet most organization's needs are: enterprise administrators, administrative group administrators, and recipient administrators.

Enterprise Administrators

Windows 2000 Server installs default groups in the built-in container in Active Directory Users and Computers. The built-in local security group called Administrators has all permissions to manage the Windows 2000 Server domain. The Domain Admins and Enterprise Admins global security groups are members of the Administrators group and therefore also are granted all permissions in the Windows 2000 domain.

The Domain Admins and Exchange Admins global security groups are granted rights to administer the Exchange 2000 organization. These rights are inherited from the parent object—the server's Configuration container.

Note Exchange System Manager hides the configuration container. You can view the configuration container by running Adsiedit.exe from Windows 2000 Server Support Tools.

To assign users administrative privileges for the entire enterprise, add them to the Enterprise Admins group. By default, members of Enterprise Admins have nearly full control of both Active Directory and Exchange 2000.

Administrative Group Administrators

Many organizations might want to take advantage of the administrative group model. To do this, you create a global security group in Active Directory and grant this group one of the roles in the Exchange Administration Delegation Wizard for the specific administrative group. These permissions should be the same as those for Enterprise Admins, except that they are only valid within the selected administrative group.

Recipient Administrators

Recipient Administrators administer all aspects of user objects. You can use the built-in Windows 2000 Server Account Operators security group as a single location for recipient administrators. You should grant the Account Operators group Exchange View Only permissions role using the Exchange Administration Delegation Wizard. Recipient administrators must be able to create accounts in Active Directory in addition to enabling a mailbox in Exchange 2000.

All user administration permissions must include rights to Active Directory in addition to Exchange. This reflects a change from earlier versions of Exchange where Exchange managed its own directory rather than relying on the operating system.

Note Any user that you want to administer any level of Exchange 2000 must have at least Read permissions on the Exchange organization container.

Organization Preparation

Preparing your organization for Exchange 2000 involves two setup options: ForestPrep and DomainPrep. You can prepare Windows 2000 Server for the setup of Exchange 2000 Server by separating parts of Exchange 2000 Setup that require high level network access permissions from those that don't.

Typically, organizations with messaging systems have two sets of administrators: network administrators and messaging administrators. These two sets of administrators typically do not share the same permissions. To allow for this separation, Exchange 2000 Setup provides ForestPrep, and DomainPrep.

The following are reasons to use ForestPrep and DomainPrep:

• If you want a user that doesn't have high level network permissions to install the first Exchange 2000 Server. 

• If you want to resolve replication latency issues, and speed up the installation of Exchange 2000 Server. 

Using ForestPrep and DomainPrep is not necessary when all of the following conditions are true:

• If all Exchange 2000 Servers are installed in a single domain. 

• If the single domain contains the schema master. 

• If all Exchange users reside in that single domain. 

• If the account installing Exchange 2000 Server has Enterprise and Schema Administrator permissions. 

ForestPrep

The ForestPrep setup option performs all the tasks that require Enterprise and Schema Administrator permissions. It is designed to be used by the highest network administrator, and is only required to run once per forest.

During ForestPrep setup, you can designate the Exchange 2000 Administrator account. When ForestPrep and DomainPrep are complete, the permissions on this account are equivalent to the Delegation Wizard Org-Level Exchange Full Administrator account.

Before running setup /ForestPrep you should do the following:

• Establish the Exchange 2000 Administrator account. 

• Determine if you want to create a new Exchange 2000 organization or join an existing Exchange 5.5 Server organization. 

  Caution This decision is permanent and cannot be reversed. 

• Establish a name for the organization if you are not joining an existing organization. 

• If you are joining an existing Exchange 5.5 organization, you must know the name of the Exchange 5.5 server and the service account and password in the site you want to join. 

The ForestPrep requirements are as follows:

• The ForestPrep setup option must be run in the same domain as the Schema Master. 

• The user running the ForestPrep setup option must be granted Enterprise and Schema Administrator permissions. 

• If the user running the ForestPrep setup option is joining an existing Exchange 5.5 organization, this user must also have administrator permissions on the Exchange 5.5 Site container and Configuration container. 

• If joining an existing Exchange 5.5 organization, Active Directory Connector and Exchange Server version 5.5 Service Pack 3 (SP3) must already be installed. 

The following describes a ForestPrep installation:

• It extends the Active Directory schema. 

• It creates the Organization container and the Global containers underneath it. 

• If joining an existing Exchange 5.5 organization, ForestPrep also replicates objects from the directory service of the Exchange 5.5 server to which you chose to bind. 

• It gives the account specified the same permissions on the MSExchange container as a Delegation Wizard Org-Level Exchange Full Administrator. 

Note After ForestPrep completes, you must still run DomainPrep.

Table 30.9 illustrates when running ForestPrep is required, and when it is not required.

Table 30.9 When ForestPrep is required

Running ForestPrep is Required	Running ForestPrep is Not Required
When installing the first Exchange 2000 server into the Windows 2000 Server organization into a domain that does not contain the Schema Master.	When installing the first Exchange 2000 Server into the Windows 2000 Server organization into a domain that contains the Schema Master.
When an account that doesn't have Enterprise, Schema, or Domain Administrator permissions wants to install the first Exchange 2000 server.	When an account that has Enterprise, Schema, or Domain Admins permissions wants to install the first Exchange 2000 server. This account will automatically become the Exchange 2000 Administrator account.

DomainPrep

The DomainPrep setup option performs the setup tasks that require Domain Administrator permissions. It is designed so that only users with Domain Administrator permissions can use it. You should run setup /DomainPrep in each domain that will have an Exchange 2000 server installed in it. You should also run it in each domain that contains users with Exchange mailboxes. The user running DomainPrep is not required to be an Exchange administrator.

The following are DomainPrep requirements:

• The user running the DomainPrep setup option must have Domain Administrator permissions for the domain. 

• The ForestPrep setup option must run before DomainPrep 

• Replication from ForestPrep must complete. 

Note Exchange Administrator and Exchange 5.5 permissions are not required to run DomainPrep.

The following lists what the DomainPrep installation accomplishes:

• It creates two new domain groups: Exchange Domain Servers and Exchange Enterprise Servers. 

• It creates the PF Proxy container. 

• It grants permissions to the Exchange 2000 Administrators and Exchange Servers on these objects. 

Table 30.10 illustrates the differences between the Exchange Domain Servers group and the Exchange Enterprise Servers Group.

Table 30.10 Differences between Exchange Domain Servers group and Exchange Enterprise Servers group 

Exchange Domain Servers Group	Exchange Enterprise Servers Group
Global Security Group	Domain Local Security Group
Contains the computer accounts for all the Exchange servers in the domain. This group is populated by Setup during the regular installation process, not during DomainPrep.	Contains the Exchange Domain Servers groups from all the domains running Exchange 2000 Server. DomainPrep adds the Exchange Domain Servers group from the current domain; the Recipient Update Service adds the domains that have an active Recipient Update Service.
The Exchange Domain Servers group is needed for the Recipient Update Service.	Exchange Enterprise Servers group is granted permissions on the domain container.

Table 30.11 illustrates when running DomainPrep is required and when it is not required.

Table 30.11 When DomainPrep is required 

Running DomainPrep is Required	Running DomainPrep is Not Required
After running ForestPrep.	When the account installing Exchange 2000 Server is granted Exchange Full Administrator permissions and Domain Administrator permissions. In this case, DomainPrep runs automatically.
Before using a designated Exchange 2000 administrator to install the first Exchange 2000 Server into a domain.
When you want to create a Recipient Update Service for a domain that isn't going to host an Exchange 2000 Server, but will have mail-enabled users.

Active Directory Connector

Active Directory Connector requires the administrator to be granted specific permissions when performing actions such as installing the connector and creating connection agreements. The following are the required permissions for performing specific Active Directory Connector administrative functions.

Active Directory Connector Installation

Installing the first Active Directory Connector in a Windows 2000 Server forest involves extending the Active Directory Schema in addition to copying files to the local computer. Therefore, the administrator performing the installation must be a member of the following groups:

• Schema Admins 

• Enterprise Admins 

• Administrators (of target computer) 

After the first Active Directory Connector installs, the Active Directory Schema is updated. This eliminates the need for the user to be a member of the Schema Admins group. The user performing the installation must be a member of the following groups:

• Domain Admins (local domain) 

• Administrators (of target computer) 

Active Directory Connector Service Account

When you install Active Directory Connector, you must have a service account. This is because some of the technology required for the Active Directory Connector is part of Windows 2000 Server. Exchange 2000 Server has features to prepare Active Directory for installation of the server. Part of this preparation involves setting permissions for LocalSystem services to Active Directory. Because you can use the Active Directory Connector without Exchange 2000 Server installed, a separate service account is used.

The Active Directory Connector service account requires the following permissions:

• Member of the Built-in\Administrators group 

• Member of Enterprise Admins if used only with Windows 2000 

• Member of Enterprise Admins or Exchange Full Administrator role if used with Exchange 2000 Server 

Connection Agreement Credentials

When you create a connection agreement in Active Directory Connector, credentials for accessing Active Directory and the Exchange directory are required. The account you provide should have the following permissions:

Exchange 5.5 

• Exchange Administrator role to the Exchange 5.5 Site (local) naming context 

• Exchange View Only Administrator role to the Exchange 5.5 Site (remote) naming context 

• Exchange View Only Administrator role to the Exchange 5.5 Organization naming context 

Active Directory 

• Domain Admins (local domain) 

• Exchange View Only Administrator role to the Exchange 2000 organization 

Other Permissions Issues

Like Active Directory Connector, there are specific Exchange 2000 administrative functions that require specific permissions to be successfully performed. The following are Exchange functions and administrative actions that require various permissions to perform successfully.

Creating and Deleting Mailboxes

To create a mailbox, you need to have permission to create a user in Active Directory. For example, you can be a Domain Administrator, or you can have delegated access to a specific organizational unit. If you have delegated access, you must have the Exchange View Only Administrator role to the Administrative Group where the target Exchange 2000 Server exists.

Upgrading Mailboxes In The Same Site/Administrative Group

To move a mailbox from Exchange 5.5 to Exchange 2000 using the Active Directory Users and Computers snap-in, you must have the following permissions:

• Exchange 5.5 Administrator privileges to the Site naming context. 

• Active Directory Domain Admins or Server Operators group permissions in the local domain. 

Configuring Routing Groups and Connectors

Because configuring routing groups and connectors does not directly affect user accounts, you only need Exchange Administrator permissions for the Administrative Group where the target routing group exists.

If you need to define the global message formats for specific outbound domains or need to specify global message thresholds, you need Exchange Administrator permissions for the Exchange Organization.

Manipulating Message Queues

To view message queues in Exchange System Manager, you need the following permissions:

• Exchange View Only Administrator on the administrative group where the connector exists. 

• Member of the local Administrators group on the target computers. 

To remove messages from queues, you need the following permissions:

• Exchange Administrator role on the administrative group where the connector exists. 

• Member of the local Administrator group on the target computers. 

Installing Exchange 2000 Server with Exchange Administrator Permissions

The following are issues you should consider when installing Exchange 2000 Server with Exchange permissions:

• The Exchange Administrator must first be an Administrator of the local computer on which Exchange 2000 Server is installed. 

• If joining an Exchange 5.5 organization, the Exchange Administrator must also have administrative permissions on the Exchange 5.5 Site and Configuration containers. 

• The Exchange Administrator must also know the Exchange 5.5 service account and password. 

Exchange 2000 Administrator Limitations

There are certain actions that a user granted Exchange Administrator permissions is not allowed to perform:

• Users granted only Exchange Administrator permissions cannot run ForestPrep or DomainPrep. 

• The Exchange Administrator cannot create new users or give users Exchange mailboxes unless the user also has Account Operators permissions. 

Securing Client and Server Communication

Exchange 2000 Server allows you to secure communication between messaging clients and your servers. Securing communication between the client and server can prevent interception of sensitive e-mail, and help prevent users from sending and receiving unsolicited mail.

Inbound Encryption

You can configure the Exchange 2000 protocol virtual servers such as SMTP servers and Post Office Protocol version 3 (POP3) servers to require inbound encryption when a client is communicating with the server. You can configure each server to use SSL with basic authentication, further securing your messaging environment. Requiring security on your virtual

server, especially your SMTP virtual server, makes it more difficult for users to send and receive unsolicited e-mail. For more information about inbound encryption, see Exchange 2000 Help for the protocol virtual server you want to secure.

Encrypted RPC

You should configure your client to use encrypted remote procedure calls (RPCs). This ensures that messages transmitted over the Internet between clients and servers are secure and no users can tamper with them. Exchange 2000 Server uses RPC when communicating between the client and the server. Exchange uses the security built into RPC to authenticate client-server and server-server communications.

Although Exchange 2000 Server uses SMTP as its native transport protocol between Exchange 2000 servers, there are situations when it uses RPC. You can encrypt RPC to protect your client-server communication in the following circumstances:

• If a MAPI client with encryption enabled connects to the Exchange 2000 server. 

• If an Exchange 5.5 server connects to another server in the same site or over Site Connector. 

• If an Exchange 2000 server connects to an Exchange 5.5 server, whether it is in the same mixed site and routing group, or over Site Connector and Routing Group Connector. 

• You can encrypt the entire client-server communication for secure mailbox access over the Internet. 

Encrypted RPC uses a 40-bit RSA algorithm called RC4 to encrypt data while it is on the network. You can configure Outlook to use encrypted RPC so communication between clients and servers is secure and no users can tamper with messages during transit.

Encrypting RPCs is different from encrypting a message using advanced security encryption; it provides protection for data only while it travels from point to point on the network. A message encrypted using advanced security encryption is protected until the recipient decrypts it using the client, regardless of how many hops are used during delivery. Encrypted RPCs provide increased security for messages sent on internal networks, as well as to outside organizations on the Internet.

To configure encrypted RPCs 

1. In Microsoft Outlook, on the Tools menu, click Services. 

2. In the list of information services, click Microsoft Exchange Server, and then click Properties. 

3. Click the Advanced tab. 

4. Under Encrypt information, select both check boxes to encrypt all client/server communication. 

Securing Your Internet Connection

Internet connections expose your Exchange 2000 servers to traffic on the Internet, and increase the possibility of the security risks listed earlier in this chapter. You should use virus security and physical security to secure your Internet connection.

Virus Protection

Viruses can enter a computer system through the Internet, newsgroups, or e-mail. Once in the system, they can spread when e-mail, files, or documents are shared. There are two ways to protect against viruses. One is to install virus-scanning software, which can detect and remove viruses, on the computers in your organization. However, you must continually update your virus-scanning software to protect your computers as viruses evolve. The other way to protect against viruses is to prevent the virus from entering your system by using firewall software that includes virus detection. You must continually update your firewall software to keep up with changing viruses.

Even if you have virus-detection software in the firewall and on desktop computers, viruses can still enter the system. Messages that are encrypted cannot be scanned for viruses. A virus contained in an encrypted message escapes detection and can be activated when a user in the organization opens the message. For maximum protection, you should ask users to minimize their exposure to viruses by adhering to the following practices:

• Tell users to be cautious with attachments, and never to open attachments from unknown sources. 

• Tell users to log off of their e-mail accounts when not using them. If they log on remotely from a public terminal, tell them to log off when they end their session. 

• Tell users that when they respond to unsolicited e-mail it only confirms that they have an active e-mail address and it can expose your organization to attack. Ask users to forward unsolicited e-mail to you so you can filter it out by blocking mail from those IP addresses. 

• Tell users not to respond to requests for personal information, such as their passwords, even if the request seems to come from someone reputable. 

Physical Security

Aside from using the security features provided in Exchange 2000 and Windows 2000 Server, you can implement a variety of physical security measures to protect your Exchange organization.

Firewalls

Firewalls are one of the best ways to protect your systems from attacks by users on the Internet. You can use a firewall to separate your internal network from the Internet. A firewall restricts inbound and outbound access, and it can analyze all traffic between your network and the Internet. A firewall can range from a simple packet filter to complex bastion hosts that analyze traffic for each application type. A bastion host must be secured because it is accessible from the Internet and exposed to attack. A firewall can be a single router or computer, or it can be a combination of components such as routers, computers, networks, and software such as Microsoft Proxy Server.

A firewall or proxy server fundamentally separates one network from the other, such as the connection of the LAN to the Internet. For a list of ports and protocols used by Exchange and Windows 2000 Server, see Appendix B, "Ports and Protocols." It is important to review these ports and protocols to prevent interruption of service when implementing a firewall.

Dual-Homed System

One way to set up a bastion host is to use a dual-homed computer, which has a connection to two networks but does not route packets between them. One of the connections is to your internal network and allows communication with other servers and clients in your organization. The other connection is to the Internet. You can run Exchange on a dual-homed computer to provide safe e-mail connectivity to the Internet.

Proxy Servers

Some services, such as Web and File Transfer Protocol (FTP), are point-to-point, so a client can make a connection directly to a server. Allowing clients inside your network to connect directly to hosts on the Internet is generally unsafe. One solution to this problem is to use a proxy server to interact with external servers on the client's behalf. The client communicates with the proxy server, which relays approved client requests to servers and relays responses back to the client. External hosts do not connect directly to clients in your network.

Domain Name System

If your system accepts mail directly from other hosts on the Internet, is should be listed in the Domain Name System (DNS). When you register your system with DNS, a DNS Mail Exchanger (MX) record is created that routes all mail to your host that processes incoming mail for the domain. Unless you plan to forward all outbound Internet mail to a relay host (a host outside your organization that has better e-mail connectivity), your server must be able to query DNS to deliver messages. You can configure your Exchange 2000 Server server to use DNS services from your Internet service provider (ISP), or you can use your own DNS servers. If you maintain your own DNS servers, they must be registered with your parent domain.

If you are using DNS and do not want DNS queries from the Internet to return information about computers on your internal network, configure DNS so that external hosts can query information about your internal servers but not about other hosts. To do this, your must set up a pair of DNS servers: an external DNS server for your bastion hosts, and an internal DNS server that clients on your network use. Configure the internal DNS server to forward queries it cannot resolve to the external DNS server so clients in your network can resolve Internet host names. Your bastion host should use the internal server for DNS to resolve both internal and external names. Because the external DNS server does not have complete information for your internal network, and because access to your internal DNS server is not available from the Internet, you can hide most of your computers from external DNS queries by not creating records for them on the external DNS server.

Security Updates

To keep up with updates and security notices released by Microsoft:

• Make sure that you have the latest service packs and hot fixes. You can download the latest updates from http://www.microsoft.com. For more information about Windows updates, see Windows 2000 Server Help. 

• Subscribe to the Microsoft Security Bulletin at http://www.microsoft.com.