Maintaining Secure Exchange Servers

Fortify your messaging security with Exchange'sadvanced security features

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

Mailbox Security
Before an Exchange server accepts any request to connect, the client mustprovide satisfactory credentials. The client establishes credentials when itattempts to connect to the Information Store service. At that point, it mustprovide the name of a known Windows NT account and its password. If the user hasalready logged on to the network and has credentials (the access token an NTdomain controller grants), the Exchange server uses those credentials anddoesn'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 hasrejected the existing credentials (e.g., the account has been locked out sincethe last logon), or if the client is set to ignore any existing security dataduring logon. The last check box on Screen 2, determines whetherExchange will use the existing credentials.

Clients never transmit password information during logons; instead, bothclient and server do everything on the basis of a shared secret--the accountpassword. At the simplest level, the server encrypts text with the password andsends the encrypted string to the client, which uses its knowledge of thepassword to decrypt the string. The client then sends the decrypted string backto the server, which checks the return value against its original transmission.If both strings match, the server accepts the credentials and establishes anauthenticated connection. Of course, this interchange does not use a simple textstring. The interchange incorporates some additional one-time data to stophackers 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. Withoutknowledge of the secret for the service account, you can't install a new serverinto a site. Exchange checks the name and password when the Exchange services(such as Mail Transfer Agent--MTA, store, and system attendant) start after asystem reboot. Without the secret, a rogue server cannot join a site and beginto replicate data you'd rather not share.

NT accounts that hold the appropriate permissions can override basicmailbox security and connect to a mailbox. This feature is beneficial in somecases, such as when people leave the organization and you want to recovermessages from their mailboxes. This feature is a problem in other cases, such aswhen systems administrators gain unauthorized access to mailboxes to read mailthey shouldn't. Exchange logs all such accesses in the NT event logs withidentifier 1016; a good idea is to regularly check the event logs for suchinstances.

Administrative Permissions
Sometimes Exchange administrators get confused between NT's adminand permissions admin permissions. The difference is simple: Theadmin permission lets an NT account perform administrative functions forExchange, such as starting an Exchange service or maintaining the contents ofthe directory. The permissions admin permission inherits all the power of theadmin permission and lets an NT account grant other permissions to itself andother accounts. Permissions admin can be dangerous; for example, rogueadministrators can give themselves Send As permission on a mailbox, which letsthem connect to a mailbox and send messages as if they were the mailbox's realowner. Exchange's advanced security features prevent rogue access to messagessecured through encryption, but they can't stop an administrator connecting to amailbox 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 orupgrade Exchange software. They are not required for day-to-day administrationtasks on an Exchange server. Therefore, you can allocate different levels ofpermissions to different administrators and restrict the most powerfulpermissions to a select group. If you use this restriction, you prevent rogueExchange administrators who gain unauthorized access to users' mailboxes fromcovering their tracks by clearing the NT event logs--assuming, that someoneactually checks the event logs to uncover such instances.

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

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

Clients connect to one or more mailboxes. Exchange always knows a primarymailbox and uses the full directory name (an X.500-like name) for theprimary mailbox to gain access to public folders. A full directory name, alsoknown as a distinguished name (DN), looks like this example:

Once you know a little about Exchange organizational design, interpretingthe DN is easy. The example mailbox belongs to an organization named DigitalEquipment Corporation; it's held in the Recipients container of the Dublin site,and the mailbox belongs to a user whose alias name is TonyR.

When a client attempts to access a public folder, Exchange checks the DNagainst the folder's access control list (ACL). The ACL lists DNs and thepermissions they hold, so Exchange can easily validate whether a user can accessa folder, and identify the user's level of access. Exchange 5.0 simplifies lifebecause it lets you replicate a whole set of permissions through the tree of afolder and its subfolders.

Because distribution lists reside in the directory, they have DNs, too.Users inherit access permissions for a folder by their membership in adistribution list. Using distribution lists to control access to public foldersis very effective, because you avoid amending individual memberships as peoplejoin or leave an organization or as responsibilities change. Exchange uses asystem of backward pointers to link individual membership to a distributionlist, so any permission change is active for all users as soon as you make thechange. Also, you can offload distribution list maintenance to users and free asystems administrator's time.

Screen 3, shows the ACL for the Exchange Server Informationpublic folder. Many of the entries in the ACL are for individual mailboxes, butthe entry whose display name is Technical Direct is a distribution list that myconsulting group uses to grant read-only access to the folder.

Exchange's AdvancedSecurity Features
Exchange has two major advanced security features: message encryption anddecryption, and digital signatures. Exchange's advanced security features arebased on software that Microsoft has licensed from both Entrust Technologies andRSA Data Security, augmented with new or modified code developed withinMicrosoft. Exchange divides the security workload between clients and server.Clients perform all encryption and decryption and apply digital signatures. Theserver keeps track of the users who are entitled to use advanced security andmanagement operations, such as the allocation and revocation of securitycertificates. I'll describe these certificates and the part they play inadvanced security later in this article.

Mail applications usually secure email through asymmetric encryption, whichuses a pair of keys--one private and one public. The keys share a mathematicalrelationship, but deriving one key from the other is extremely difficult.Therefore, distributing a user's public key to anyone who wants to send thatuser encrypted messages is safe and doesn't compromise the private key. The userviews the encrypted information with the private key.

With a single-use bulk key generated on demand, Exchange encrypts messagecontents in a symmetric encryption, which means that Exchange uses the same keyfor encryption and decryption. The bulk key uses a 40-bit, 56-bit, or 64-bitalgorithm, depending on the country in which the software is licensed. The56-bit and 64-bit algorithms are only available in the US and Canada; Francepermits no encryption software.

Historically, the US banned the export of strong encryption algorithms onthe basis that foreign parties could use encrypted data against US interests.Exchange 5.0 complied with the US restrictions in place at the time the softwareshipped. In June 1997, Microsoft obtained a license to export 128-bit encryptiontechnology, and the company will use the stronger algorithms in Web-basedcommerce, specifically in extensions to the SSL (Secure Sockets Layer) andtransport-layer security (TLS) protocols. Microsoft will incorporate the newalgorithms into Internet Explorer (IE) and Internet Information Server (IIS),but the company has not made an announcement in relation to Exchange.

Additionally, each recipient's public key encrypts the encryption key forthe message. In effect, this layer of encryption creates a lockbox or outerwrapper for the message. The algorithm that builds the lockbox is based on 512bits and is much stronger than the base encryption.

Because of the computational power required, using such strong encryptionis realistic only when encrypting a small amount of data. The message recipientuses the private key to open the lockbox, retrieve the bulk key, and decrypt themessage. In effect, a hybrid combination of symmetric and asymmetric encryptionprotects messages. The bulk encryption algorithm is either CAST (from Entrust)or DES, while the public-key algorithm is RSA.

Digital signatures are like an electronic stamp or seal placed on adocument. The seal affirms that a particular person, or someone with access tothat person's private signing key, has sent the message. You can create achecksum for the message by feeding the message contents through an algorithmand encrypting the result with a private key to create a digest of the message.You can verify the checksum at any time by decrypting the digest with a user'spublic key. If anyone has changed the message content since it was sent, thechecksum fails. Thus, digital signatures allow non-repudiation of messages,provide a level of confidence that a known individual sent the message, andguarantee that messages have arrived in the same form the originator sent.Exchange uses the MD5 algorithm (from RSA Data Security) for digital signatures.

The Exchange Certification Authority
I've mentioned private and public keys often. Because of the way Exchangemanages keys, you must think through how you'll deploy Exchange's advancedsecurity features.

Exchange uses two pairs of keys--one pair for digital signatures and theother pair for message encryption. To hold the public and private keys, Exchangeuses a system of X.509 certificates, which a Certification Authority (CA) issuesand controls. In an Exchange organization, the Key Management (KM) Server is theCA. Only one KM Server can issue certificates in an organization. The first KMServer you install creates the CA object in its site configuration container asScreen 4 shows. As you replicate configuration data between sites,the other sites in the organization learn of the existence of the CA, therebypreventing another KM Server from creating another CA.

You must be certain that you install the first KM Server in the rightplace. Because the server hosting the KM Server holds the security database foryour organization, you need to physically secure and protect it from unwantedinterventions.

The Exchange directory stores the X.509 certificates. When a user mailboxis enabled for advanced security, Exchange stores the X.509 certificateinformation as attributes of the mailbox. Each certificate requires about 700bytes of memory. Before an Exchange or Outlook client tries to send an encryptedmessage to a recipient, it checks to see whether an X.509 certificate exists. Ifthe certificate is unavailable, the client refuses to send the message. X.509certificates hold the public key for a recipient, so if the public key isunavailable, a message cannot be encrypted.

Although logical, this approach is sometimes difficult for users tounderstand, especially if they try to send a message to a distribution list thathas both Exchange and external recipients. In this scenario, Exchange encryptsthe message for the Exchange recipients who have enabled advanced security, butExchange won't send an encrypted message to the external recipients becauseExchange doesn't know their public keys.

Similarly, the check against the directory lets the client determine whatencryption algorithm to use for a message. If a North American client sends amessage to other people who also use North American clients, the client can use56-bit or 64-bit encryption; however, if an international client is involved,the client automatically downgrades to 40-bit encryption.

Holding Private Keys
Exchange holds users' private keys in an encrypted password file (with .epfextension) on a PC. You must keep this file in a directory that's accessibleregardless of the PC the user logs on from. You may need to update your logonscripts so that password files follow users around. Exchange encrypts thepassword file as shown in Screen 5, using a secret algorithm based on a passwordprovided when a client enables advanced security. The key information ismeaningless to human beings.

The first time a user attempts a secure operation during a client session,the user must complete the dialog box shown in Screen 6. Note the check box tocontrol whether Exchange prompts for a password for each operation or for eachsession. If this file is lost or unavailable, a user cannot encrypt, decrypt, ordigitally sign messages.

Obviously, setting up and administering advanced security requires someeffort. You must authorize users and issue credentials. Individually enablinghundreds of users can be time-consuming; fortunately, the SIMPORT utility canhelp you issue many temporary security credentials at once. However, temporarycredentials don't give users access to Exchange advanced security; they merelymake the beginning of the process easier. Users must complete the process withthe Set up advanced security option on an Exchange or Outlook client.Eventually, the CA issues the necessary certificates, and your users can encryptaway.

After the CA issues security certificates, managing them is largelyautomatic. Each certificate has an expiration date, and when the dateapproaches, the system prompts the user to contact the KM Server for an update,as shown in Screen 7.

Management tasks include ensuring that the KM Server service starts up eachtime the server reboots, revoking certificates from users whose access you wantto deny, and reissuing certificates for people who have lost their certificates.Recovering keys is one of the KM Server's critical functions--without thisfunction, users can lose their .epf files or forget their passwords and beunable to read any encrypted mail. If a user loses or can't remember a password,the KM Server restores the keys, letting the user get back to work.

This workload isn't very time-consuming, and you can perform most of thetasks through the Exchange administration utility. You can appoint someone toact as the security administrator for the organization so that users have onecontact for all security issues.

Working Offline
Working offline is one of the greatest benefits of using Exchange. As afrequent traveler, I create, read, and answer messages on my notebook PC inairport lounges throughout the world. The ease and power of Exchange's offlinecapabilities simplify these tasks. If you've deployed advanced security, you caneven encrypt and decrypt messages offline because you can download the X.509certificate information (and other directory information) into the offlineaddress book (OAB).

The OAB is a set of five files stored in the Windows directory. When youdownload details from the Exchange directory, you can choose to include detailsabout recipients, as Screen 8 shows; the extra details include the X.509certificates. Downloading full details takes a little extra time, but it's theonly way to handle encrypted messages. OAB information is static, and you needto download a new OAB every week or so to update certificate information.

Person-to-Person Key Exchange
Person-to-Person Key Exchange (PPKE) is new in Exchange 5.0. This featurelets people send a certificate containing their public keys to users in anotherExchange organization, as shown in Screen 9. After organizations exchange keys,they can exchange encrypted messages. Users can hold the key information in apersonal address book (PAB), but keeping it there renders it static data. If acertificate is revoked or altered, Exchange does not automatically replicate thechange to PABs; mail encryption stops.

Third-Party Security Products for Exchange
Exchange's advanced security features provide all the protection most usersneed. However, some users require even better security, and that's wherethird-party security extensions can help. People usually use third-partyextensions to get two kinds of security features: algorithms that are harder tobreak and the ability to exchange key information with people who don't useExchange.

As I noted earlier, Exchange supports 40-bit, 56-bit, and 64-bit encryptionalgorithms. However, because of US government restrictions, the 40-bit algorithmis the only one available to someone like me, who doesn't live in the USor Canada. I'd like my mail to be as secure as anyone else's; however, dataencrypted with a 40-bit key can be decrypted with less effort than you mightimagine. The basic rule of encryption is that the longer a key is, the harder itis to break. Until Microsoft opts to exploit its new license to use 128-bitencryption inside Exchange, anyone outside the US or Canada who wants highlysecure mail must look beyond Exchange advanced security.

Third-party security products belong to one of two camps: products thatdepend on a CA similar to the one Exchange uses and products that use public andprivate key pairs and rely on personal administration and distribution of thekeys. The best-known example of the second approach is Pretty Good Privacy(PGP). The CA style provides the basis for almost all SSL and other Web-basedsecurity today, because managing security is easier when you have a centralpoint of reference. Personally distributing keys is difficult to manage in alarge-scale or distributed enterprise, and the system relies heavily on usercooperation and knowledge.

More and more products appear in this space all the time, and notablerecent arrivals include MailSecure for Exchange (Baltimore Technologies) andSecure Messenger for Exchange (Deming Software). Both products are plug-ins tothe Exchange or Outlook MAPI clients and add security options to the clientmenus. Both products use the Secure MIME (S/MIME) protocol to send encryptedmessages between users of any mail system that supports S/MIME. Of course,any public and private key scheme works only when users make their public keysavailable to their intended correspondents, so both MailSecure and SecureMessenger can generate and distribute keys, much like the PPKE feature inExchange. The combination of S/MIME support and the ability to distribute keysmakes these keys well-suited for a heterogeneous messaging environment or forimplementing advanced security between two Exchange organizations.

MailSecure is especially interesting for installations outside the USbecause the encryption algorithms did not originate in the US, and therefore,the US government cannot restrict them. Instead of the 40-bit algorithm Exchangecurrently offers, MailSecure uses a 128-bit algorithm, which provides a hugeincrease in security. A CA is available for MailSecure (UniCERT). The CA is animportant component of a secure mail system, so its availability is an importantplus for MailSecure.

These products aren't the only offerings on the market. EntrustTechnologies' Entrust/Express extension for both Exchange and Outlook clients isin beta testing. A browse through the Exchange mailing list reveals a number ofPGP extensions for Exchange. Most of these extensions are shareware or freeware,but commercial products based on PGP are also appearing.

Third-party security plug-ins cost money. Expect to pay between $50 and$100 per license, depending on the quantity you buy. Inevitably, you will facesome questions about buying third-party software when Exchange provides advancedsecurity in the base product, so be ready to justify your decision. Also, keepin mind that client technology evolves; make sure that your selected vendor isable and willing to keep its software up-to-date. Be sure to factor the cost ofupgrades into your decision.

Plan Before You Deploy
We've covered a lot of ground in this article, and I hope you can use theinformation to fine-tune your organization's security or help you decidehow to best deploy secure mail in your enterprise. The important thing toremember is to plan first before plunging into deployment.