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 architecture, see the Additional Reading section at the end of the chapter for pointers to some useful references.

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

Note  

Exchange Server 2003 runs on either Microsoft Windows 2000 or Windows Server 2003. For the most part, these two operating systems have a very similar architecture, although Windows Server 2003 includes some compelling security features that I ll mention at the appropriate places.

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

• Operating system security features

  • Some Windows 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 the Windows 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. When you upgrade to Exchange Server 2003 from Exchange 2000 Server, a smaller set of schema changes are made, some of which add or change security- related properties on objects.

  • In Windows Server 2003, Microsoft added the ability to tunnel remote procedure call (RPC) data through standard Hypertext Transfer Protocol (HTTP) packets. This is great for Exchange, because the Messaging Application Programming Interface (MAPI) depends on RPC connectivity. By using RPC over HTTP, it s possible to provide full Microsoft Outlook capability to remote users without using a virtual private network (VPN) or opening tons of ports on your firewall or into your perimeter network (also known as the demilitarized zone or DMZ). However, this functionality is available to any application that uses RPCs, not just Outlook.

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

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