Applying the Finishing Touches

Whether or not you’ve got Exchange 2000 in production now, there are some important steps you can take to tidy up its installed security configuration. These measures are all easy, and they can all be performed on existing Exchange servers with no negative effects.

You can begin by strengthening the permissions on some installed objects, starting with the Exchange installation directory. By default, the Exchange installation directory might have an ACE for Everyone:Full Control; this is undesirably loose. To fix it, open the Properties dialog box for the installation directory, then click the Security tab and do the following:

1. Clear the Allow Inheritable Permissions From Parent To Propagate To This Object check box. This is necessary because the Everyone ACE is inherited from the root of the parent NTFS volume, so to get rid of it you have to disable inheritance. When prompted, specify that you want to copy permissions from the parent to its child objects.

2. Select Everyone and click Delete.

3. Add new ACEs that grant Full Control to the SYSTEM and CREATOR OWNER pseudo-accounts, the Domain Admins group, and the Exchange administrators’ groups you previously created.

4. If you want end users to be able to use Microsoft Outlook Web Access on this server, add a new ACE that grants the Authenticated Users object Read and Execute permission. The resulting permissions will resemble those shown in Figure 7-5.

   
   Figure 7-5: Add more restrictive ACEs on your Exchange installation directory.

Next, check the permissions on the message tracking share created on each Exchange server. Depending on which service pack you’ve installed, and whether or not your servers are clustered, the permissions here might vary. In general, you’ll need to set the most restrictive possible ACE that still grants access to legitimate users. Most of the time, that means removing the Everyone and Authenticated Users entries (if present) and granting your Exchange administrators Full Control rights, along with giving Domain Admins Read permission.

Tip

Remember that message tracking can be configured to log the subject lines of messages. If you don’t set permissions on the tracking log shares correctly, an attacker might be able to gather sensitive data just from the message routing and subject information.

Because the Exchange Domain Servers and Exchange Enterprise Servers groups are security-sensitive, it would be a good idea to add an ACE that prevents Authenticated Users from adding themselves as members of these groups; you can do so by opening the groups’ Properties dialog boxes in Active Directory Users and Computers, clicking the Security tab, and making sure that the Deny check box for the Add/Remove Self as Member permission is set.

Exchange 2000 depends on the remote registry service, access to which is controlled by the ACL on the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg registry key. This ACL, by default, grants Read access to the Exchange Domain Servers group; you should also give that group Full Control permissions on the winreg key on your Exchange servers and the domain controllers they use. In addition, take a look at the rest of the ACL for that key and see whether any unnecessary entries are present—Write access to the key should be limited to administrative accounts.

The final finishing touch is probably the most important. In late 2001, some intrepid folks at Compaq discovered a subtle vulnerability inherent in the way the Exchange Domain Servers groups works. By design, the machine account of each Exchange server in a domain is added to the group, and the group is given permissions on all of the mailbox and public folder stores on servers in the domain. The problem is that this permission allows an attacker to use credentials from one machine to read mail stored in another server’s database, even if care has been taken to ensure that no user accounts are in Exchange Domain Servers. To fix this, Microsoft released a script called EDSLock, described in Knowledge Base article Q313807. EDSLock’s mission is simple: it sets a deny ACE for Exchange Domain Servers:Receive-As on the Exchange Server object, and it sets an allow ACE for the local machine account on the local server’s public folder and mailbox stores. The effect of these ACLs is to slam shut this potential vulnerability.

You must run EDSLock against each individual Exchange server, specifying its distinguished name. The easiest way to do this is to download EDSLock to a single machine and run it multiple times. Once you’ve run it against each of your servers, you’ll need to run it again when you add a new Exchange server to an existing domain, when you add a new domain that will host Exchange servers, or when you add a new public folder or mailbox store on an existing server.