Most Exchange Server installations have a set of mailboxes that aren't tied to a specific individual. Organizations often use these anonymous mailboxes for special purposes such as disseminating information or receiving input from many users about a certain topic. For example, you might have a mailbox called HelpDesk to which users can email requests for help; three or four people might then read and respond to those messages. Or you might use an anonymous mailbox called HR Manager or VP of Operations to disseminate a bulletin telling everyone that they can leave 2 hours early so that they can get home ahead of a coming ice storm.
Anonymous mailboxes are especially useful when more than one person is responsible for a business function. However, any time you have more than one person with access rights to a mailbox, you need some mechanism in place to ensure accountability, audit access, and validate the authenticity of sent messages. For example, what would happen if someone sent the "early dismissal" message without proper authority? Would you be able to tell who sent the message? Would your users have a way to know that the message wasn't authentic? In this article, I explain how to configure your system to help track who's using an anonymous mailbox and to let recipients know that messages they receive from such a mailbox are authentic.
Accessing Anonymous Mailboxes
To set up an anonymous mailbox, you create a mailbox and grant multiple people User Rights on that mailbox. Figure 1 shows such a configuration in an Exchange Server 5.5 organization.
Individuals with User Rights can use the anonymous mailbox in several ways. They can define an Outlook profile and access the entire mailbox, they can use Outlook's ability to open a folder from another user's mailbox, and they can use Exchange's Send As capabilities by simply entering the name of the anonymous mailbox in the message's From field. As Figure 2 shows, Kevin Mason is logged on to his mailbox but has entered VP of Operations in the From field to send a message from the VP of Operations mailbox.
Logging Anonymous Mailbox Information
By default, when someone accesses an anonymous account, the system logs little or no information that identifies specifically who accessed the mailbox and what they did while using it. As Figure 3, page 8, shows, when someone uses the Send As option to send a message, message tracking simply shows the submission as coming from the anonymous mailbox. (Exchange tracking-log information is intended for tracking a message as it moves through the system components, not as a security mechanism.)
Figure 3 shows the message-tracking results for Exchange 5.5, but Exchange 2000 Server also logs the message as submitted by the anonymous mailbox rather than by the domain user account or mailbox of the person who sent the message. When someone other than the mailbox's primary user accesses a mailbox by using an Outlook profile, Exchange 2000 and Exchange 5.5 log event ID 1016 in the Windows Application event log. This event occurs because the system recognizes that the domain account that the person is using to access the mailbox isn't defined as the "Primary Windows account" in Exchange 5.5 or isn't the Active Directory (AD) account linked to the mailbox object. However, when a user accesses an anonymous mailbox by other means (e.g., by using Send As or the Other User's Folder function), nothing is logged by default.
To make using an anonymous mailbox less anonymous from a security and auditing perspective, you can increase two diagnostic logging settings on the Private Information Store. For Exchange 5.5, use the Microsoft Exchange Administrator program to expand the container hierarchy and select the Private Information Store object (ORG\Site\Configuration\Server\<server>Private Information Store containers). From the File menu, select Properties, then select the Diagnostics Logging tab, which Figure 4, page 8, shows. In the Services window, select Private. In the Category window, select Logons and change the Logging level to Minimum. Next, select Send As and again set the Logging level to Minimum, then click OK.
For Exchange 2000, the procedure is nearly identical. Use the Microsoft Management Console (MMC) Exchange System Manager (ESM) snap-in to expand the Administrative Groups container. If you don't see an Administrative Groups container, you need to first access the organizational-level Properties and select the Display Administrative Groups check box. Next, expand the appropriate Administrative Group for the server you're configuring, then expand the Servers container. Right-click the server you're configuring, then select Properties. Select the Diagnostics Logging tab. In the Services section, expand the MSExchangeIS object and select the Mailbox object. Under Category, select Logons and change the Logging level to Minimum. Select Send As and again set the Logging level to Minimum, then click OK. You must perform this procedure on all your Exchange servers because some events are logged on the server that hosts the mailbox of the person with access and others are logged only on the server that hosts the anonymous mailbox. Neither Exchange 2000 nor Exchange 5.5 requires a restart—the diagnostic logging changes take effect immediately.
After you make these changes, the Application log will log two additional informational events. When someone accesses a mailbox (including their own) or uses the File, Open, Other Users Folder function, the Application log will record event ID 1009; event ID 1032, which Figure 5 shows, will show up in the Application event log whenever someone uses the Send As function.
You can now relate the use of the Send As function to the mailbox of the person who clicks Send. (However, if multiple users sent messages at the same time, you might have to perform a little detective work to see which user sent which message.) These diagnostic logging settings will cause an increase in the number of items written to the Application event log, so you might want to increase the log's maximum size. The advantages of this additional layer of accountability and tracking clearly outweigh the additional logging overhead. If your system is busy enough that these log entries threaten to overwhelm your logs such that you risk missing other more crucial log entries, I suggest you look at products such as Hewlett-Packard's (HP's) OpenView or NetIQ's AppManager. These applications can help you manage your event logs.
Verifying Message Authenticity
To ensure the integrity of messages that users send from an anonymous mailbox—or any mailbox, for that matter—you need a way to validate that a message originated from the identified sender and that the message wasn't modified in transit. An unfortunate side effect of SMTP's simple nature is that someone can easily spoof (i.e., impersonate) the sender of a message. This means that anyone can specify any address in the From field of a message header. When an Outlook user receives such a message, he or she might easily believe that a spoofed message is authentic. For example, Figure 6 shows a message sent to the All Staff distribution list (DL), which has the SMTP address [email protected]. To generate this message, I used the Telnet utility to connect to my system's SMTP server and issue the following SMTP commands and data:
HELO mysystem.demo.com
MAIL FROM: [email protected]
RCPT TO: [email protected]
DATA
From: <[email protected]> VP of Operations
To: All Staff
Subject: Early Dismissal
You are authorized to leave early (2 hours) because of the ice storm.
Kevin
Exchange accepted and delivered the message to the All Staff DL. Unless recipients examine the details of the message's SMTP header, they won't know that the message originated outside of the system and is a fake. (A typical user probably won't even know what to look for in a message header.) Depending on which Outlook version users are running, if they did take the time to double-click the Sender and look at the Properties, they might be even more convinced the message is authentic. Exchange and Outlook versions released before the release of Windows XP use the SMTP addresses provided on the To: and From: lines of the SMTP session to find the corresponding AD or Exchange Directory objects. After locating the objects, Outlook reads property information from the Directory and displays additional details such as the Address and Phone Number fields, adding to the illusion of authenticity.
Digital Signing Technology
Because Outlook uses the information on a displayed message's From field to determine the message's sender, you have few options for verifying a sender's identity, short of requiring every inbound connection to authenticate. A more realistic solution is to use digital signatures. Digital signatures use public-key and private-key certificate technology to ensure that the sender is uniquely identified and that the message wasn't altered in transit. Figure 7 shows the process of digitally signing and verifying a message. Digital signatures use an algorithm to create a digest or summary from the content of an email message. At the message's point of origin, the email client uses the sender's private key to encrypt the digest—the encrypted digest becomes the digital signature. The email client appends the digital signature to the message as a MIME-encoded attachment and sends the message to recipients. At each recipient machine, the email client decrypts the digital signature by using the sender's public key to produce a copy of the digest the sender generated. Next, the recipient's email client creates a version of the digest by using the message contents and the same digest algorithm that the sending client used. If the two copies of the digest match, the message wasn't altered in transit; the sender's identity is verified because only the sender's private key will correspond to the public key that the receiving client used to successfully decrypt the first digest.
Putting Digital Signatures in Place
Implementing digital signatures on a mailbox-by-mailbox basis is fairly easy, with only a few requirements. First, both the sender and recipient must have a mail client capable of generating and validating digital signatures. Outlook XP is configured out of the box to use digital signatures. Earlier versions of Outlook need a few configuration changes to properly process and validate digital signatures. The sidebar "Validating Digital Certificates in Outlook," page 10, explains in more detail how Outlook processes digital signatures. If you haven't yet deployed Outlook XP, the minimum version of Outlook I recommend you use is Outlook 2000 Service Release 1a (SR1a). The SR1a version fixes problems related to processing certificate revocation lists (CRLs—lists of certificates that have been canceled because of things such as lost or compromised private keys). Next, you need a digital certificate tied to the sender's email address. The digital certificate has two parts—a public key and a private key, as I described—and is issued by a Certificate Authority (CA). The CA can be the organization that maintains the email system or an outside organization that acts as a trusted and impartial third party. This impartial third party validates the identity of the sender (the first party) and issues a certificate to the sender and confirms to the recipient (the second party) that the sender is who he or she claims to be. The CA performs this function by making available the public-key portion of the certificate that identifies the organization as a CA. This certificate is called the root or intermediate CA certificate, depending on the CA type. When the CA issues a certificate for an individual email address, the CA uses the private-key portion of the CA certificate to sign the certificate. A recipient examines a sender's public-key certificate and uses the CA's signing data and public-key certificate to validate that the CA issued the sender's certificate. If the CA's signature is valid, the sender's certificate is implicitly trusted, forming what's called a trusted certificate chain.
To authenticate a digitally signed email message, you must have access to the sender's public-key certificate and you must have a way to validate its authenticity. Two methods exist for gaining access to the public key. First, the sender can provide a copy of the public key to recipients before sending any digitally signed or encrypted mail. This certificate is installed in the certificate repository on the recipient's PC. When the recipient receives a digitally signed or encrypted message, the email client matches the sender's address to the public key and uses the key to decrypt the message and verify its authenticity. A sender can also attach a copy of the public-key certificate to each message so that the public key is available even if the recipient didn't receive it ahead of time. The latter method is more convenient—but also less secure. When you attach the public key to the email message, anyone who intercepts the message would have a copy of the key. If the sender's certificate were used to encrypt the email message, the person who intercepts the message can use the public key to decrypt and read the message.
After the recipient has a copy of the public-key certificate, the recipient needs to determine whether the certificate is valid and hence the sender can be trusted. If you install a certificate into your PC's certificate repository, you can explicitly trust the certificate—in other words, force your system to assume the certificate is valid. The preferred and more secure method uses a trusted certificate chain and CRLs to determine a certificate's status. As I stated earlier, the certificate contains information about the CA that issued it. For the trusted chain to work as a validation mechanism, you need to store in every PC's certificate store a certificate representing the issuing CA or a root CA. This certificate, rather than the sender's certificate, is explicitly trusted (because typically, it's more well known). Because you explicitly trust the issuing CA or root CA, you implicitly trust the sender as long as all the certificate signatures are valid, all have valid dates, and none are found on a CRL. If the sender uses a well-known CA such as VeriSign, Thawte, or Baltimore Technologies, your PCs should already have the appropriate root certificates installed. If the sender uses a certificate from a less-known CA, you'll need to install that CA's certificate. For information about using digital certificates, see "Secure your Email, Part 1," http://www.winnet mag.com, InstantDoc ID 24226, and "Secure your Email, Part 2," http://www.winnetmag, InstantDoc ID 24887.
The procedure for requesting and obtaining a certificate varies depending on the CA, but the process is generally easy. You provide some identifying information to the CA; the CA verifies the information and sends you instructions for installing the digital certificate. You can view the certificate by using Microsoft Internet Explorer (IE). To review the certificates stored in a PC's certificate repository, open IE; select Tools, Internet Options; then select the Content tab. Click the Certificates button to display the certificate repository. You should see your certificate listed on the Personal tab.
After you install the certificate, you need to configure Outlook to use the certificate to sign email. Open Outlook; click Tools, Options; then select the Security tab. Click Settings to display the Change Security Settings dialog box, which Figure 8 shows. The fields in the Certificates and Algorithms section will be populated with information from the personal certificate you just installed. If you have more than one personal certificate, you might need to click Choose beside Signing Certificate and beside Encryption Certificate and select the appropriate certificates from the lists. Unless you have a reason to change the algorithms, you should use the default values. SHA1 is the Hash Algorithm default, which tells Outlook how to generate the message digest; Triple DES (3DES) is the Encryption Algorithm default. If you don't want Outlook to attach your public certificate, clear the Send these certificates with signed messages check box. If you clear this option, you need to give a copy of your public key to all potential recipients. If you plan to use the personal certificate only for signing, you're relatively safe leaving this option selected, and it will significantly simplify your deployment. Click OK to close the Change Security Settings dialog box. On the Security tab of the Options dialog box, select the Add digital signature to outgoing messages check box if you want to digitally sign all outgoing messages. If you don't select this option, you can choose to digitally sign on a message-by-message basis.
Composing and sending messages works the same as without digital signing, but now Outlook will append a digital signature to each message that a user sends from the anonymous mailbox; the change will be seen on the recipient's end. When a recipient opens a digitally signed message in Outlook, they'll see a ribbon icon on the right side of the message header, as Figure 9 shows. If the digital signature of the message is valid, they'll see a red ribbon and know the message is legitimate. If the digital signature can't be verified or is invalid, Outlook shows a gray ribbon icon with a red exclamation point. Double-click this icon to display the problems with the certificate or the signature.
More Accountable Email
Configuring security features to log additional information can add accountability and tracking to your email system. Adding digital signatures helps recipients know that messages are legitimate and gives you a powerful tool that helps ensure the integrity of your company's business communications. In a future article, I'll discuss how to set up your own CA server and highlight some concerns and challenges associated with running your own CA.
