Win2K Security and Exchange 2000

Microsoft Exchange 2000 Server's tight integration with Windows 2000 Active Directory (AD) lets Exchange 2000 take advantage of Win2K's AD security features. Exchange 2000 also benefits from other Win2K security enhancements, such as improved authentication, access control, and auditing.

Object Unification
Unlike Exchange Server 5.5, Exchange 2000 doesn't have its own directory. Instead, Exchange 2000 uses Win2K's AD to store information about mail entities, such as mailboxes, custom recipients, and distribution lists (DLs). This Exchange 2000 characteristic has important management and security consequences. An administrator of a Windows NT 4.0 system running Exchange Server 5.5 needs to manage two distinct objects (i.e., a user's NT account and an Exchange mailbox); however, an administrator of a Win2K system running Exchange 2000 manages only one object (i.e., the AD user object). Exchange 2000 stores a user's mailbox as a property of the AD user object.

Table 1 shows Exchange Server 5.5 directory objects' functional equivalents in Win2K's AD. Exchange Server 5.5 mailboxes and custom recipients map to AD users and contacts, respectively. AD includes two types of DLs: distribution groups and security groups. A Win2K security group can function as a DL.

Table 1 also shows whether the AD objects are security-, mail-, or mailbox-enabled. Security-enabled means you can use the object for any security-related operation (e.g., access control, administrative delegation). A mail-enabled object doesn't link to a mailbox; instead, it has only an email address. A mailbox-enabled object has an associated Exchange 2000 mailbox.

Authentication
Authentication identifies users, computers, services, or other network devices that want to access system or domain resources. Kerberos, Win2K's default authentication protocol, offers many advantages over the protocol's predecessor, NT LAN Manager (NTLM). For more information about Kerberos, see "Kerberos in Win2K," October 1999. Your system needs to meet two conditions before you can enable Kerberos for authentication between a client and a server. First, the Kerberos Security Support Provider (SSP), which is the code that provides the Kerberos logic, must be available on both the client and the server. Second, the client and server applications must recognize Kerberos credentials (e.g., tickets, authenticators, ticket-granting tickets—TGTs).

Kerberos is available on all Win2K platforms. Every Exchange 2000 service uses Kerberos to authenticate to a Win2K domain. By default, Exchange 2000 services use the Local System Account's credentials (i.e., the machine account, the machine password) to log on to the Win2K domain. This use of the Local System Account provides better password security than earlier Exchange security arrangements because Win2K automatically generates the system account passwords and renews the passwords at regular intervals. This change in Exchange 2000 eliminates many problems related to Exchange Server 5.5's service account. In Exchange Server 5.5, systems administrators sometimes use their user account for the service account, which can prevent Exchange services from starting if an administrator's account is locked out.

Although Exchange 2000 services use Kerberos to authenticate to a Win2K domain, Exchange 2000's Information Store (IS) doesn't recognize Kerberos credentials. Clients authenticating to Exchange 2000 can't use Kerberos features, such as authentication delegation and mutual authentication. A user logging on to an Exchange 2000 mailbox uses NTLM for authentication.

Access Control
An access control service grants or denies access to system or domain resources. In deciding whether to grant access, the access control service considers the authentication process' results, as well as access control settings that apply to system or domain resources. Although the Win2K access control model is similar to NT 4.0's access control model, the Win2K version includes crucial new ACL extensions: property-based access control entries (ACEs); object-type ACEs; better control over ACL inheritance; and support for property sets and extended rights. You can use these extensions to delegate AD object administration.

Exchange 2000 uses the Win2K access control model. A crucial component of Win2K's access control model is the Security Descriptor (SD), which attaches to every securable object and contains ACLs. ACLs contain ACEs that link SIDs to access rights. Every object that has a SID is a security principal.

Each IS object has a Win2K SD. As a result of Exchange 2000's integration with AD, you can use a Win2K SD to set access control on Exchange-related AD objects. Each IS and AD object has an NTSecurityDescriptor property that contains a Win2K SD. To examine a mail-enabled AD object's SD, open the object's properties in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, then click the Security tab. To examine an IS object's SD, open the object's properties, click the Exchange Advanced tab, and click Mailbox rights. Table 2 compares the access control models that Exchange 2000 and Exchange Server 5.5 use.

Exchange 2000 offers more control over the inheritance of access control settings between parent and child objects than Exchange Server 5.5 does. Exchange Server 5.5's inheritance is fixed; if you set an ACL on the organization level, all sites in the organization inherit the ACL. In Exchange 2000, an administrator can enforce and block inheritance. Enforcement always has precedence over blocking. Without this rule, the administrator of an object low in the administration hierarchy could exclude the object from the control of an administrator responsible for objects higher in the hierarchy. For example, the administrator of a public IS on a particular server could exclude the IS from any control by the administrator of the parent object, the server.

Access Control Administration
The Win2K access control model affects several of Exchange 2000's administrative procedures and interfaces, such as how you set access control on public folders. Public-folder access control involves three SDs: two SDs on the public-folder IS object (one SD for the administrator and one SD for client permissions) and one on the public-folder AD object. As Figure 1 shows, Exchange 2000 groups all settings that relate to public-folder access control in the Permissions tab of a public folder's Management Properties. Clicking Client permissions lets an administrator use predefined client roles (e.g., author, contributor) to set client permissions. The roles mimic a set of object permissions. Table 3 gives an overview of Exchange 2000 client roles and their object permissions.

You can use the Permission tab's Directory rights button to set ACLs on a public folder. The ability to set ACLs on the public-folder AD object is a consequence of Exchange 2000's integration with AD. The Administrative rights button lets you set public-folder administrative permissions. Exchange 2000's public-folder administrative permissions offer much more granularity than they did in Exchange Server 5.5. Exchange 2000 includes new permissions such as the ability to modify a public folder's deleted-item retention period and to modify the public-folder quotas. Microsoft calls the new permissions extended rights.

A list of an Exchange object's extended rights follows the Win2K permissions in the object's ACL editor. To see all Win2K extended rights, use the Microsoft Active Directory Service Interfaces (ADSI) Edit tool in the AD configuration naming context. (You can find the ADSI Edit tool in Windows 2000 Support Tools on the Win2K CD-ROM.) Open the CN=Configuration,DC=<Domain Name> folder, then open CN=Extended-Rights, which contains many Exchange-specific extended rights whose names begin with CN=ms-Exch, as Figure 2 shows.