Maintaining Secure Exchange Servers

Messaging systems can contain all sorts of information. Exchange Server lets you store nearly any type of file in user mailboxes or public folders. Because you don't want other people browsing through your mailbox or accessing public folders that they shouldn't, maintaining a reasonable level of security is in your best interest. This article examines the essential aspects of security within an Exchange environment and Exchange 5.0's advanced security features.

Mailbox Security
Before an Exchange server accepts any request to connect, the client must provide satisfactory credentials. The client establishes credentials when it attempts to connect to the Information Store service. At that point, it must provide the name of a known Windows NT account and its password. If the user has already logged on to the network and has credentials (the access token an NT domain controller grants), the Exchange server uses those credentials and doesn't display a logon screen. Screen 1, shows a logon in progress.

A user must log on if credentials are not available, if the server has rejected the existing credentials (e.g., the account has been locked out since the last logon), or if the client is set to ignore any existing security data during logon. The last check box on Screen 2, determines whether Exchange will use the existing credentials.

Clients never transmit password information during logons; instead, both client and server do everything on the basis of a shared secret--the account password. At the simplest level, the server encrypts text with the password and sends the encrypted string to the client, which uses its knowledge of the password to decrypt the string. The client then sends the decrypted string back to the server, which checks the return value against its original transmission. If both strings match, the server accepts the credentials and establishes an authenticated connection. Of course, this interchange does not use a simple text string. The interchange incorporates some additional one-time data to stop hackers from decrypting intercepted strings.

Similarly, a shared secret maintains security within a site. In this case, the secret is the name and password for the Exchange service account. Without knowledge of the secret for the service account, you can't install a new server into a site. Exchange checks the name and password when the Exchange services (such as Mail Transfer Agent--MTA, store, and system attendant) start after a system reboot. Without the secret, a rogue server cannot join a site and begin to replicate data you'd rather not share.

NT accounts that hold the appropriate permissions can override basic mailbox security and connect to a mailbox. This feature is beneficial in some cases, such as when people leave the organization and you want to recover messages from their mailboxes. This feature is a problem in other cases, such as when systems administrators gain unauthorized access to mailboxes to read mail they shouldn't. Exchange logs all such accesses in the NT event logs with identifier 1016; a good idea is to regularly check the event logs for such instances.

Administrative Permissions
Sometimes Exchange administrators get confused between NT's admin and permissions admin permissions. The difference is simple: The admin permission lets an NT account perform administrative functions for Exchange, such as starting an Exchange service or maintaining the contents of the directory. The permissions admin permission inherits all the power of the admin permission and lets an NT account grant other permissions to itself and other accounts. Permissions admin can be dangerous; for example, rogue administrators can give themselves Send As permission on a mailbox, which lets them connect to a mailbox and send messages as if they were the mailbox's real owner. Exchange's advanced security features prevent rogue access to messages secured through encryption, but they can't stop an administrator connecting to a mailbox if the administrator has that permission. The lesson here is simple: Don't allocate permissions admin to anyone without good reason.

Sensibly deployed, NT permissions can provide another level of protection. For example, NT administrative permissions are required only to install or upgrade Exchange software. They are not required for day-to-day administration tasks on an Exchange server. Therefore, you can allocate different levels of permissions to different administrators and restrict the most powerful permissions to a select group. If you use this restriction, you prevent rogue Exchange administrators who gain unauthorized access to users' mailboxes from covering their tracks by clearing the NT event logs--assuming, that someone actually checks the event logs to uncover such instances.

Exchange and Outlook clients (Messaging API--MAPI--clients) connect to the Exchange server with remote procedure calls (RPCs). By default, the RPCs transmitted between client and server are not encrypted; however, a setting on the client can cause the RPCs to be encrypted with a 40-bit algorithm when connected either over a LAN-type connection or via dial-up networking. The degree of protection increases to 128-bit encryption for NT clients connected to NT 4.0 servers, but only if both are running the North American edition of NT 4.0 Service Pack (SP) 2 or later. The Advanced tab shown in Screen 2 is set to encrypt information passed over the network. Using encrypted RPCs prevents an eavesdropper from reading an intercepted RPC without a great deal of effort at the cost of additional overhead. The overhead isn't enormous and probably wouldn't be noticed by users connected by a LAN; however, when users are connected over a slow dial-in link, the overhead is more noticeable­and encryption is even more desirable.

Public Folder Security
The permissions for each public folder control that folder's security. You set permissions either through the Exchange administration program or through the client--select the Permissions tab from the folder's Properties dialog box, as shown in Screen 3.

   Previous  [1]  2  3  4  Next