Microsoft recently released a script (edslock.vbs) to help administrators close a potential access hole to Microsoft Exchange 2000 servers and mailbox stores (see Knowledge Base article Q313807 for details, including how to download and use the script). An administrator can exploit the vulnerability, which arises through permissions that the Exchange Domain Servers security group holds, to gain unauthorized access to mailbox data. However, I want to emphasize that only administrators can exploit the vulnerability and only if they use a specific technique that I don't discuss here.
Administrators have always been able to read other peoples' mail—and not just on Exchange. The first corporate email system I worked with (in 1982) let administrators raise their privileges and access anyone's mailbox to read and process email as if the administrator was the selected user. Most email systems I've worked with since that time have offered similar facilities to some degree. For example, on Exchange 5.5 servers, you can reset the primary Windows NT account for a mailbox and leave it blank or set it to be the administrator account, and then use a mail client to read and send email. The integration between directory and system information in Exchange 2000 makes gaining access a little more difficult, but access is still available.
You can argue that much the same information control is available to Windows administrators, who can typically get to any data on file shares on a server that they manage, and the same scenario exists for database or other administrators who exert control over the data they manage.
There are good reasons why you want administrators to have access to mailboxes. We're all familiar with legal requests for information pertinent to a lawsuit. Given the electronic nature of communications today, it's not surprising that much of the data lawyers want resides in email systems, and some high-profile actions, such as the US Department of Justice (DOJ) case against Microsoft, have demonstrated how powerful and damaging email data can be in the hands of a lawyer. Discovery actions that focus on email aren't new—the first one I was involved with occurred in 1991—and administrators are usually compelled by law to recover messages and provide them to the requesting lawyers. Other reasons for administrative access to user mailboxes include internal investigations of sexual or other harassment, suspicion of industrial espionage, and inappropriate use of company email (such as running a separate business). And you also have situations where companies monitor email usage and examine messages to meet company, government, or other regulations, such as the Securities and Exchange commission (SEC) 17-4A guidelines about the use of electronic communications for trading activities.
Your company must lay down clear guidelines about when to let administrators have controlled access to someone's mailbox. The company needs to communicate these guidelines to users as part of the company's data protection and privacy policy and revise the guidelines regularly to take account of new system or application software.
Microsoft examined the vulnerability that exposed mailbox access and how best to secure servers and mailbox stores. The Exchange Domain Servers security group contains the computer accounts for every Exchange 2000 server in a domain. The security group is created when the /DomainPrep part of the Exchange installation program (setup) runs and is populated as servers are added to the domain. The lockdown script tightens security by allowing access to the mailbox and public stores on only the local server. You can use a Deny access control entry (ACE) to stop other servers in the Exchange Domain Servers security group from accessing local stores. The tightened security doesn't stop a local administrator from accessing mailbox data, but it does close the reported vulnerability.
Microsoft's script isn't integrated with the Exchange 2000 installation program nor with the code that creates new mailbox or public stores. Thus, if you install a new server into a domain or create a new store, you have to run the lockdown script to secure the new server or store. Microsoft will incorporate the code into the next functional release of Exchange, which the company couldn't do in a service pack because update.exe, the executable that applies service pack updates, doesn't have the necessary permissions to update the server and store objects held in the configuration naming context in the Active Directory (AD). Microsoft could have changed update.exe by increasing its privileges, but it's best not to meddle with permissions for a one-time operation. Instead, you can expect to see future changes to the /ForestPrep part of the installation program to secure existing servers and to the server installation portion of the program to lock down new servers.
You don't need to rush out and apply the script immediately. You need to get a copy of the script, test it, and then integrate it into the normal operational and security procedures for your Exchange 2000 deployment. Simply put, run the script as part of regular operations (perhaps by including it into the checklist used to install new servers or create new stores) and make arrangements to check that the required Deny ACE is in place on all servers.
Any discussion about security comes back to the fact that you have to trust the people that hold elevated permissions for computer systems. If you don't trust individuals, then they shouldn't enjoy privileged access, and as a general rule, you need to reduce privileged access as much as possible. The best advice I can give is to keep up to date with all security matters relating to Windows, Microsoft IIS, and Exchange and know what your administrators are doing.
