Win2K Security and Exchange 2000

Authentication, access control, and auditing benefit from integration

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= folder, then open CN=Extended-Rights, which contains many Exchange-specific extended rights whose names begin with CN=ms-Exch, as Figure 2 shows.

A special type of extended right is a property set, which is a group of object properties. Property sets can speed Exchange object access control administration; property sets let you use one administrative action to set access control on all object properties instead of setting access control on individual object properties. For example, enabling a mail-enabled user object's Read Public Information permission lets the user read the object's E-mail Addresses, Manager, and Common Name attributes. The AD, ADSI, and Directory Services Platform software development kit (SDK) explains how you can create custom extended rights and property sets by modifying the AD schema and configuration-naming context.

Access Control Migration
Organizations migrating to Exchange 2000 from Exchange Server 5.5 want a smooth migration path between the two access control models. To ease the migration, you can use the Active Directory Connector (ADC). The ADC maps Exchange Server 5.5 directory objects to corresponding AD objects and vice versa. If a corresponding object doesn't exist, the ADC will create it. Table 4 shows corresponding Exchange Server 5.5 directory objects and AD objects. The early ADC version ships with Win2K, but I recommend using the enhanced version that ships with Exchange 2000. The later version can replicate the Exchange Server 5.5 site-naming and configuration-naming contexts. (For more information about the ADC, see Tony Redmond, "The Active Directory Connector," January 2000.)

By default, the ADC migrates Exchange Server 5.5 DLs to AD Universal Distribution Groups (UDGs), which you can reference from anywhere in the Win2K forest. However, this migration can create access control problems if, for example, you use Exchange Server 5.5 DLs to set access control on Exchange Server 5.5 public folders. The UDGs that the ADC creates don't have SIDs, and SIDs are crucial for setting access control on Exchange 2000 objects.

Win2K resolves this problem by automatically converting UDGs to Universal Security Groups (USGs). This automatic conversion happens when you upgrade an Exchange Server 5.5 public folder store to Exchange 2000, when you replicate a public folder on an Exchange Server 5.5 server to an Exchange 2000 server, or when a Microsoft Outlook client uses a DL to assign permissions to an Exchange 2000 public folder. The automatic conversion will work only if your Win2K domain is in native mode; USGs aren't available when Win2K operates in mixed mode.

Win2K uses token augmentation to resolve another type of migration problem in which a user's USG memberships aren't available to the user's Kerberos ticket. For example, a user is a member of a USG in a native AD domain, and the user account is in a mixed AD domain or an NT 4.0 domain. The system uses the USG to set access to an Exchange 2000 object (e.g., a public folder). When a user logs on to a Win2K domain, the domain controller queries a Global Catalog (GC) server to discover the user's universal group memberships and store the memberships in the user's Kerberos ticket. However, the GC discloses universal group membership only when the domain is in native mode. Because the user account is in a mixed-mode domain, the user's Kerberos ticket doesn't contain the user's USG memberships; thus, the user can't access any resources that the system uses USGs to secure. Token augmentation lets an application, such as Exchange 2000, find the user's USG memberships and add the memberships to the user's access token. You need to have Win2K Service Pack 1 (SP1) for token augmentation to work.

Administrative Delegation
In an Exchange 2000 environment, you can set up administrative delegation on two levels—the AD level and the Exchange-infrastructure level. You use AD-level delegation to delegate administrative tasks that relate to organizational unit (OU), site, or domain management. AD OUs can contain user-mailbox, contact, and DL objects. You can use the MMC Active Directory Users and Computers snap-in to set AD-level delegation. You can use infrastructure delegation to delegate the administration of Exchange servers, administrative groups, address lists, public folder trees, or a complete Exchange organization. You can use the MMC Exchange 2000 System Manager snap-in to set infrastructure-level delegation. Table 5 compares AD-level delegation with Exchange infrastructure-level delegation.

Wizards on the AD and Exchange-infrastructure levels can help you complete the delegation process. To start the AD-level delegation wizard, select Delegate Control in an OU, site, or domain object's context menu. The MMC Active Directory Users and Computers snap-in displays OU and domain objects, and the MMC Active Directory Sites and Services snap-in displays site objects. On the AD level, you can also change an object's ACL directly through the object's ACL editor to set delegation without using the wizard.

Start Exchange 2000's Exchange Administration Delegation Wizard from the organization and administrative group levels. Right-click the object that you want to delegate, and select Delegate Control. In the Delegate Control dialog box, which Figure 3 shows, you can define a delegation by selecting a security principal (i.e., a user or a group) and associating the principal with an Exchange administrator role. In the Exchange Administration Delegation Wizard dialog box, you can add, edit, or remove delegations. However, you can't use the delegation wizard on the server, public-folder tree, and address-list levels; at those levels, you need to use the ACL editor to set delegation.

To facilitate administrative delegation, Exchange 2000 supports administrative roles. Roles can define a set of Exchange-specific permissions and can link to security principals. Exchange 2000 roles, which Table 6 lists, reside in the IS. Exchange 2000 administrative roles are different from the roles that are visible in the Outlook client. The Outlook roles simplify client access-control administration.

Auditing
The auditing process gathers information, some of which is security-related, about activities and operations that occur on a computer system. Win2K has two auditing tools—the Event Viewer and the Security Configuration and Analysis tool.

The Event Viewer includes a set of folders to gather auditing information that relates to certain OS core services (e.g., the Directory Service, the DNS Server, the File Replication Service). The Event Viewer records Exchange information in the Application log. The Event Viewer doesn't include an alerting system or a centralized domain- or forest-auditing facility, but the Event Viewer is an indispensable tool to detect misuse of your Exchange 2000 infrastructure.

You can use the Security Configuration and Analysis tool to analyze and apply security settings. The tool bases its analysis and application activities on security templates that define values for a set of security-related system parameters. The tool can analyze and configure file-system and Registry access-control settings, system service startup parameters, event-log settings, account policies (e.g., password quality), local policies (e.g., user rights), and restricted group membership. The tool uses its own database, secedit.edb, which resides in the %systemdrive%winntsecuritydatabase folder. You can run secedit.exe at a command prompt to use the tool. The Security Configuration and Analysis tool can help you harden the Win2K platform on which you build your Exchange 2000 infrastructure.

Integration's Importance
The tight integration between Win2K security and Exchange 2000 security makes an Exchange administrator's life easier. The integration creates powerful new administrative tools and features, such as the ability to delegate. However, you need to have a strong theoretical and practical knowledge of Win2K to fully exploit the new Exchange 2000 security model.