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%\winnt\securitydatabase 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.