Chapter 3: Windows and Exchange Security Architecture

Overview

Noble life demands a noble architecture for noble uses of noble men.

– Frank Lloyd Wright

Microsoft Exchange and Microsoft Windows are closely interlinked in many ways. Think of a house: it has to be built on some kind of foundation, which provides support and infrastructure (like water and sewer connections, an electrical service entrance, and so on). Exchange is the house; Windows is the foundation.

Understanding how the two products work together is critical to knowing how to properly secure Exchange; many of the security options you’ll want to use are actually set using Windows tools. This chapter presents an overview of the Windows and Exchange architectures, focusing on those components that are interesting from a security standpoint. If you’re not already familiar with the Microsoft Windows 2000 architecture, see the “Additional Reading” section at the end of the chapter for pointers to some useful references.

Microsoft Exchange 2000 relies on Windows 2000 security for its access control and authentication. This is quite different from Microsoft Exchange 5.5, which used Microsoft Windows NT’s authentication mechanisms but maintained its own separate set of security and permission data in the Exchange 5.5 directory.

The security features you can use in Exchange fall into three general categories:

1. Operating system security features

   • These features provide access control and authentication to workstations, servers, and users. Because Exchange mailboxes are actually assigned to and associated with an Active Directory user account, these features also provide access control for mailboxes. Operating system security features depend completely on Windows 2000’s security infrastructure, including user and permission data stored in Active Directory. Unlike earlier versions of Exchange, there is no separate set of permissions for Exchange objects. When you install Exchange into an Active Directory forest, the schema is extended with additional attributes so that you can set Exchange-specific permissions on mail-related objects.

2. Exchange-specific features

   • Even though Exchange’s access controls are based on the standard Windows mechanisms for access control and security, Exchange adds many new permissions. Some of them are fairly generic, whereas others are quite specific (for example, the Delete Mailbox Storage or Administer the Information Store permissions). In addition, Exchange adds other features, like the ability to use Secure Sockets Layer/Transport Layer Security (SSL/TLS) for Simple Mail Transfer Protocol (SMTP) conversations and support for Secure Multipurpose Internet Mail Extensions (S/MIME), that have nothing to do with Windows itself (although these features usually use operating system components).

   • Exchange modifies the standard Windows access control process; it actually performs access control checks in two separate steps. The first step is to make some preliminary checks that determine which specific access controls might apply. For example, when a user requests administrative access to a public folder, Exchange checks to see which set of permissions should apply before checking the permissions themselves. The second step is to perform the actual Windows access control check, possibly using some of the Exchange-specific permissions.

3. Auditing

   • Auditing makes a persistent record of security-related events (and, optionally, Exchange configuration changes) in the system’s event log. Security-related log entries go to the system’s security event log. Exchange maintains its own logs for some functions (for example, message tracking logs, or the logs kept by individual protocol virtual servers), and these logs might occasionally contain security-related information.