Exchange Server 5.5 Security
People who send and receive e-mail rely on their messaging systems to provide reliable and secure service. The following types of attacks can compromise the security of e-mail systems:
| • | Theft of or tampering with data. By "sniffing" packets or intercepting messages in transit on the network, an attacker can gain access to data or even modify it. |
| • | An attacker can forge messages to make them appear as if they came from someone else as a means of distributing false information or tricking users into sending them sensitive data. |
E-mail systems are also susceptible to the following kinds of attacks if they are connected to the Internet:
| • | Denial of service. Because processing messages requires disk and CPU resources on your server and bandwidth on your Internet connection, an attacker can tie up your system or network by flooding it with mail. |
| • | Trojan horses and viruses. Unsuspecting users can run programs they receive in messages that can infect the system, delete files, or cause other damage. |
Microsoft Exchange Server provides a variety of features that you can use to ensure the security of your users' mail and your system. You can protect messages using advanced security (encryption and digital signatures). You can protect communication between clients and servers by configuring encrypted remote procedure calls (RPCs). You can also protect your system from intrusion from the Internet by configuring your server's hardware and software.
Tools
The following security tools are provided with the Microsoft BackOffice 4.5 Resource Kit:
| • | Change Password Tool |
| • | Password Expiration Warning Application |
| • | Bulk Advanced Security Tool |
On This Page
Using Advanced Security to Secure Messages
If your organization has installed the Key Management component on a Key Management server (KM server), you can use advanced security. Advanced security allows users who need to send and receive confidential messages to digitally sign and encrypt them. This security measure provides a higher degree of protection than built-in features such as message sensitivity, which marks messages as personal, private, or confidential. Advanced security actually prevents unauthorized persons from tampering with messages.
Advanced security uses the following industry standard cryptography methods to provide security:
| • | Digital signatures, which ensure that messages aren't modified during transit. They also prevent forgeries by allowing users to place the equivalent of their signatures on messages. The recipient can then be certain that the message originated from the sender. |
| • | Data encryption, which provides confidentiality by ensuring that only the intended recipients can read a message. |
Administrators who work in organizations that use advanced security to protect highly sensitive information should understand how advanced security works so they can be confident that Exchange provides the level of protection their systems require.
How Advanced Security Works
Both digital signatures and encryption are based on encryption technology. Encryption scrambles (encrypts) a message so it can't be read until it is unscrambled (decrypted) by the intended recipient. This process of encrypting and decrypting messages is called cryptography.
Microsoft Outlook can scramble a message or convert a scrambled message back to its plaintext format by applying a mathematical formula, called an algorithm, to the message. The algorithm is used with a key, which is a random string of bits used to lock and unlock (encrypt and decrypt) the message. Only the user who has the correct key can encrypt and decrypt the message.
Outlook advanced security is a hybrid encryption system. It takes advantage of two different encryption technologies: public key cryptography and secret key cryptography (sometimes called symmetric key cryptography). Outlook uses complementary elements of these technologies to digitally sign and encrypt messages. For example, Outlook takes advantage of the strengths of public key cryptography to securely distribute keys. However, it relies on secret key cryptography to encrypt the content of messages because this technology is best suited to bulk data encryption.
Public Key Cryptography
Public key cryptography is based on two halves of the same key that are "mirror images" of each other. The two halves of the key are called a key pair. One or the other key in the key pair is required to encrypt and decrypt a message. Microsoft Exchange Server uses two key pairs that can be assigned to a user. One key pair is used to digitally sign messages, and the other is used to encrypt messages.
A key pair consists of a public key and a private key. The public key is publicly known and stored in the directory so everyone has access to it. The private key is known only to the owner of the Key and is stored on the user's hard drive. Outlook stores this information in the user's Registry. The Microsoft Exchange Client stores this information in the user's security (.epf) file. By making one key publicly available and keeping the other key secret, public key cryptography simplifies the distribution of keys without compromising their security. For example, a message encrypted with a recipient's public key can be decrypted only with the recipient's private key.
Public key cryptography is computationally slow. Therefore, it is not as effective as secret key cryptography for encrypting large amounts of data. Because of this, Microsoft Exchange Server uses public key cryptography primarily for digital signatures and for the secure exchange of secret keys between users.
To prevent unauthorized persons from tampering with keys after they have been created, Exchange uses certificates to establish a trust of keys. A certificate is a user's public key that has been digitally signed by a trusted authority called a Certification Authority (CA). The KM server is a type of CA. Because the KM server uses its private key to sign certificates, a certificate's signature can be verified using the copy of the KM server's public signing key that resides in every user's security file.
In Microsoft Exchange Server, encryption and signing operations use different certificates. Signing certificates are sent with every signed message. This ensures that the recipient can verify a sender's digital signature even when the recipient is offline. In contrast, encryption certificates are available in the global address list so everyone has access to them. Users can make encryption certificates available when they are offline by downloading a copy of the offline Address Book with full details.
Exchange uses a certificate format that complies with the public X.509 standards.
Secret Key Cryptography
Unlike public key cryptography, which uses key pairs, secret key cryptography encrypts and decrypts messages using an algorithm with a single key. A secret key is a key known to both the sender and the recipient. It is similar to a password used to log on to a server. Both you and the server must know the same password for you to have access to that server.
Because the secret key must be distributed to both the sender and the recipient in a way that it remains a secret, key distribution is more difficult with secret key cryptography than with public key cryptography. However, secret key cryptography is very fast, making it ideal for encrypting and decrypting large amounts of data. For this reason, Microsoft Exchange Server relies on it to encrypt the contents of messages, including attachments.
Clients use several different types of secret key encryption algorithms to comply with United States export laws, including the Data Encryption Standard (DES) and the Carlisle Adams and Stafford Tavares of Northern Telecom Research (CAST) encryption algorithms. For information about selecting the encryption type best suited for your organization, see "Selecting an Encryption Type" later in this chapter.
DES is a secret-key algorithm based on a fixed-length, 56-bit key. It was first published by the National Bureau of Standards. DES is a United States Federal information processing standard that is available only with the North American version of Microsoft Exchange Server.
CAST is a secret-key encryption based on a variable-length key. The key is a number that specifies a bit length between 40 and 128. This variable length provides for flexible encryption standards. Because longer keys are more secure than shorter ones, Outlook uses CAST 40 (a 40-bit key) and CAST 64 (a 64-bit key). CAST 64 is available only with the North American version of Outlook.
Key Management Server
Key Management server (KM server) is an optional Exchange component that is installed on a designated organization server. It provides centralized administration, archival of private keys, management of public keys and certificates, and it is used to set up an advanced security system.
The KM server performs a variety of important tasks:
| • | Generates public and private encryption keys. |
| • | Acts as your CA by creating public signing and encryption X.509 certificates. After the KM server has generated keys and certificates and the user's security file has been created, the KM server doesn't need to be running for a user to send and receive encrypted and signed messages, because your client actually performs all of the security operations on messages. |
| • | Maintains a secure copy of every user's private encryption key in an encrypted database in case the key needs to be retrieved after it has been issued. For example, if a user is terminated or leaves the company, the KM server enables an authorized administrator to recover the user's encrypted messages by recovering the user's private keys. You can also recover keys for users when they lose their security (.epf) file or their registry setting, or if they forget their security file password. |
| • | Maintains and distributes a Certificate Revocation List, which is a list of certificates that the administrator has recovered because the user's keys have been compromised and are no longer secure. It is stored in the directory on every server. A replica of the list is also kept on the client computer so certificates can be checked when the user is working offline. When you decrypt a message or verify its signature, the list is checked to make sure the certificate has not been revoked. If it has, the user is warned that the sender has been revoked from the organization. For more information about certificate revocation, see Microsoft Exchange Server Concepts and Planning. |
Digital Signatures
A digital signature is similar to a person's handwritten signature; it can be used to authenticate a sender's identity and ensure that a message is not modified during transit. It is a string of bits, called a message hash or checksum, that is calculated and then added to a signed message. Every message has a unique signature or checksum that is generated by applying a 128-bit Rivest-Shamir-Adelman (RSA) algorithm called Message Digest 5 (MD5) to the message.
Exchange relies on public key cryptography to ensure the authenticity of digital signatures. When the user signs a message using the client, the checksum of the message is encrypted using the sender's private signing key. When the recipient verifies the signature of the message using the client, the sender's public signing key is used to decrypt the checksum and verify the sender's identity. The signature on a message is valid only if the public and private keys correspond to each other.
Exchange determines the integrity of a signed message by comparing the checksum on the message with the new checksum of the message that the recipient's client generates. If the two checksums are identical, the message hasn't been modified since it was signed. However, if even one bit in the message has been changed, the messages will have different checksums and the recipient is notified that someone tampered with the message. Encrypting the checksum using the signer's private key also ensures a signed message that no one can tamper with because the checksum on a message cannot be switched without the signer's private key.
Signing a Message
When a user signs a message, the client generates a checksum of the message and adds it to the message. The checksum (digital signature) is then encrypted using the sender's private signing key. Finally, the original plaintext message, the digital signature, and the sender's signing certificate (which contains the sender's public signing key) are sent to the recipient. The following illustration shows the steps in the message signing process.
Verifying a Signature on a Message
When a recipient verifies the signature of a message, the client checks the sender's signing certificate against the Certificate Revocation List. If the certificate is on the list, the recipient is warned that the sender's certificate has been revoked. If the sender's certificate is valid, the encrypted checksum (digital signature) is decrypted using the sender's public signing key, which was sent with the message. Finally, the client generates a checksum on the plaintext message so it can be compared with the checksum that was just decrypted. The two checksums should be the same. If they are not, the recipient is warned that the message has been altered since it was originally signed. The following illustration shows the steps in the verification process.
Message Encryption
When a message is encrypted, the client generates a random secret key called a bulk encryption key, which is used to encrypt the message. The recipient's public encryption key is then used to encrypt the bulk encryption key in a lockbox. The lockbox allows the random bulk encryption key to be transmitted securely to the recipients. If an encrypted message is sent to several people, each recipient's public encryption key is used to generate a different lockbox, but the message contents are encrypted only once.
Encrypting a Message
When a sender encrypts a message, the client retrieves a certificate for each message recipient from the global address list. A bulk encryption key is then randomly generated and used to encrypt the contents of the message. Each recipient's public encryption key is then retrieved from the recipient's certificate and used to encrypt the bulk encryption key in a lockbox. Finally, the lockbox and the encrypted message are sent to the recipient. The following illustration shows the steps in the process.
Decrypting a Message
When a recipient decrypts a message, Exchange retrieves the recipient's private encryption key from the recipient's security (.epf) file. The recipient's private encryption key is then used to decrypt the lockbox. Finally, the bulk encryption key contained in the lockbox is used to decrypt the message. The following illustration shows the steps in the process.
Selecting an Encryption Type
The type of encryption you implement in your organization depends on the level of security your organization requires and whether you are using an international or North American version of Outlook. Organizations that require strong encryption should use either DES or CAST 64.
As you evaluate what type of encryption is appropriate for your organization, keep in mind the following:
| • | The level of security for each of the different types of encryption |
| • | International considerations for using Exchange |
| • | United States legal considerations for using Exchange |
| • | How your messages are moved from one encryption type to another |
Encryption Security
An encrypted message is only as secure as the algorithm that is used to encrypt it. The security of an encryption algorithm is measured by how easy it is to find the weaknesses in the algorithm that can allow someone to decrypt the message without its key. The most secure algorithm is one that can be cracked only by trying every possible key combination, a task that could take many lifetimes depending on the length of the key. The algorithms chosen for Exchange, including DES and CAST, have been studied extensively by cryptography experts and have no known methods of attack other than a brute-force approach of trying every key.
Algorithms that use longer keys are generally more secure than algorithms that use shorter keys because there are more possible key combinations. For example, because 64-bit encryption is approximately 16 million times more secure than 40-bit encryption, it takes 16 million times longer to crack. In Outlook the key for one message doesn't crack the key for another message because every message is encrypted with a unique key.
International Considerations
Because of United States export restrictions that limit the strength of cryptographic systems shipped outside the United States, international versions of Outlook will support only CAST 40 encryption. Currently, DES and CAST 64 are available only in versions of Exchange sold in the United States and Canada. In addition, some countries, such as France, have their own restrictions on the use of cryptography. For example, Outlook cannot use advanced security in France.
International organizations that use Exchange in several countries can mix and match types of encryption. This is possible because Exchange maintains information in the directory about the type of encryption that is supported for every user in the organization. If a message is addressed to multiple recipients using different types of encryption, Outlook automatically attempts to encrypt the message using the type of encryption that all recipients share. For example, if a message is addressed to a recipient using CAST 40 and another recipient using CAST 64, the message is encrypted using CAST 40. If a message is addressed to a recipient who is not using advanced security, Exchange allows the user to either not send the message to that recipient or to send the message in plaintext format.
United States Legal Considerations
Current United States Commerce Department export regulations prohibit the export of software that contains strong encryption outside the United States and Canada. To help administrators in the United States comply with these regulations, the Microsoft BackOffice 4.5 Resource Kit includes a form for temporarily exporting encryption products. You can use this form if you are traveling outside the United States with a laptop that uses advanced security with the client. For more information, see the Tools directory on the Microsoft BackOffice 4.5 Resource Kit compact disc.
Moving Messages to Another Encryption Type
If users move to a location within your organization that uses a different type of encryption, they can transfer their encrypted messages from one type of encryption to another using the Bulk Advanced Security tool (Sectool.exe). For example, a user transferring from an office in the United States to Britain can use Sectool.exe to convert encrypted mail from CAST 64 to CAST 40.
Follow this procedure when using Sectool.exe.
1. | Use Sectool.exe to decrypt your messages. |
2. | Copy the messages to a personal folder (.pst) file. |
3. | From your client computer, copy your .pst file to your local disk and add it to your messaging profile. |
4. | Use Sectool.exe to encrypt the messages again in the .pst file with the new encryption type. |
5. | (Optional) Copy the messages from the .pst file to your mailbox on the server. |
For more information about using the tool, see Help for Microsoft Exchange Server Resource Kit tools, (Exchtool.hlp) which is included on the Microsoft BackOffice 4.5 Resource Kit compact disc.
Increasing Exchange Security
In addition to using advanced security to protect messages, you can also increase the security of your Microsoft Exchange Server system by:
| • | Restricting access to resources by setting permissions for directory objects and public folders. For information about setting permissions, see the "Setting Permissions" section of Part 3, "Deployment." |
| • | Changing permissions for shared directories created during server Setup to minimize the possibility of tampering with Exchange files. |
| • | Configuring your clients to use encrypted RPCs so data sent between clients and servers cannot be altered while it is traveling across the network. |
Changing Permissions on Shared Directories Created During Setup
When Microsoft Exchange Server is installed, Setup creates several shared directories so other Exchange Server computers can have access to the files in the directories. By default, Setup sets permissions for these directories that are usually sufficient for most organizations. However, you can change the permissions if those default permissions do not give the files enough protection against attacks by unauthorized users.
Caution: Change permissions on these directories only if it is necessary because the changes could damage your Exchange system.
Setup creates the shared directories shown in the following table.
| Directory | Description |
Add-ins | Contains files that the Exchange Administrator program uses to display information about connectors. This directory is shared as Add-ins. |
Address | Contains files for creating e-mail addresses. This directory is shared as Address. |
Connect | Contains files for Exchange connectors. This directory is a hidden share that is shared as connect$. |
Connect\Msmcon\Maildata | Contains files used for Microsoft Mail. This is a hidden share that is available only if the Microsoft Mail Connector is installed. It is shared as maildat$. |
Res | Contains files, such as logs for Event Viewer and Microsoft Windows NT Performance Monitor, used by the local computer and remote computers. This directory is shared as resources. |
Tracking.log | Contains files used for message tracking. This directory is shared as tracking.log. |
The permissions granted to these directories are shown in the following table.
| Permission | Type of access |
Everyone | Read (except for Maildata, which has full control) |
Service account | Full control |
Local administrators | Full control |
To restrict access to the shared directories, remove the Everyone permission and grant permissions to specific accounts using File Manager. Use the following guidelines for restricting access on shared directories:
| • | Only administrators responsible for message tracking should have permissions for the Tracking.log directory because it can contain sensitive information about messages. |
| • | You can give other administrators permissions to the Add-ins, Address, Connect, and Res directories. Only administrators that need to administer the Microsoft Mail Connector should have permissions for Maildata. If you are using the Microsoft Mail External program for message transfer, also give the account for this program permissions for the Maildata directory. |
| • | Do not change permissions for the service account and local administrators because this can have unpredictable results. |
Configuring Microsoft Outlook to Use Encrypted RPCs
Microsoft Outlook computers and Microsoft Exchange Server computers communicate using Windows NT Server RPCs. To increase the security of data communication between clients and servers, Exchange enables users to take advantage of the built-in RPC security feature called encrypted RPC. Encrypted RPC uses a 40-bit RSA algorithm called RC4 to encrypt data while it is on the network. If both client and server computers have Service Pack 2 or later of the Windows NT 4.0 North American version installed, the RPC encryption strength is increased to 128-bit. Outlook can be configured to use encrypted RPC so communication between clients and servers is secure and no one can tamper with messages during transit.
Encrypting RPCs is different from encrypting a message using advanced security, it provides protection for data only while it travels from point to point on the network. A message encrypted using advanced security is protected until the recipient decrypts it using the client, regardless of how many hops are used during delivery. Encrypted RPCs provide increased security for messages sent on internal networks, as well as to outside organizations, for example, on the Internet.
To configure encrypted RPCs
1. | On the Tools menu in Microsoft Outlook, click Services. |
2. | In the list of information services, select Microsoft Exchange Server, and then click Properties. |
3. | Click the Advanced tab. |
4. | Under Encrypt information, select both check boxes to encrypt all client/server communication. |
Increasing Security When Connecting to the Internet
Any system that is accessible through the Internet is subject to attempts to infiltrate the operating system's security or to exploit security weaknesses of services running on the system. Administrators should be concerned about not only these kinds of blatant attacks but also inadvertent actions by users. Some of the most serious breaches of security are caused by users whose actions result in the release of sensitive data or cause a flood of mail from the Internet.
If you are using the Internet Mail Service, you should consider how to minimize the security risks when you connect Microsoft Exchange Server to the Internet. You can configure Exchange and Windows NT Server so people in your organization can send and receive Internet mail, but unauthorized users cannot access your system from the Internet. You can also set up other mechanisms such as firewalls that protect against attacks.
Using Firewalls
Firewalls are one of the best ways to protect your system from attack by users on the Internet. You can use a firewall to separate your internal network from the Internet. A firewall restricts inbound and outbound access, and it can analyze all traffic between your network and the Internet. A firewall can range from a simple packet filter to complex bastion hosts that analyze traffic for each application type. A bastion host is any computer that must be secure because it is accessible from the Internet and exposed to attack. A firewall can be a single router or computer, or it can be a combination of components such as routers, computers, networks, and software.
There are several types of firewall software and hardware you can use to protect your organization from outside attacks, including:
| • | Proxy servers |
| • | Dual-homed systems |
| • | Packet filtering |
| • | Firewall software |
| • | Domain Name System (DNS) |
Proxy Servers
Some services, such as Web and File Transfer Protocol (FTP), are point-to-point so a client can make a connection directly to a server. Allowing clients inside your network to connect directly to hosts on the Internet is generally unsafe. One solution is to use a proxy server (also called an application-level gateway) to interact with external servers on the client's behalf. The client communicates with the proxy server, which relays approved client requests to servers and relays responses back to the client. External hosts do not connect directly to clients in your network.
Exchange and many other e-mail systems use a store-and-forward design, which uses a proxy mechanism. Clients connect to servers that reside on the local network. Servers then communicate with each other to transfer e-mail messages. If Exchange is configured correctly, separate proxy services are unnecessary.
Dual-Homed Systems
One way to set up a bastion host is to use a dual-homed computer, which has a connection to two networks but does not route packets between them. One connection is to your internal network and allows communication with other servers and clients in your organization. The other connection is to the Internet. You can run Exchange on a dual-homed computer to provide safe e-mail connectivity to the Internet.
Packet Filtering
Implementing a packet filter between the Internet and your network can add a layer of security. You use a packet filter, such as a screening router, to control the ports and Internet Protocol (IP) addresses to which external systems can connect. However, if an intruder is able to get past the router, your network is open to attack.
To minimize this risk, many organizations implement a perimeter network. This is a network that is connected to the Internet through an external screening router and to the internal network through an interior screening router. Computers that are connected to the perimeter network have limited access to both the Internet and the internal network. This can be a convenient architecture if multiple servers require direct Internet access.
This configuration provides three levels of defense. If the external router and a bastion host on the perimeter network are compromised, the attacker does not gain unlimited access to your internal network because the internal router is controlling access.
Firewall Software
There are many commercial firewall products that provide proxy services. Some of these support Simple Mail Transfer Protocol (SMTP) e-mail. There are also free implementations of SMTP proxies, such as smap, which forward messages between internal and external systems. These products are not likely to have security weaknesses because they are typically designed solely for security purposes. Furthermore, they are usually a simple implementation with restricted functionality. However, a disadvantage of firewall software is that different SMTP servers must be managed. If your internal SMTP server is upgraded with new features, the firewall software must also be upgraded.
Because Exchange provides secure Internet access, additional firewall software is unnecessary. However, you can use the Internet Mail Service with firewall software. To do so, configure your Internet Mail Service to forward all mail to the bastion host running the firewall software.
DNS
DNS is a distributed database that translates between host names and IP addresses. It also carries other information about hosts, such as mail exchanger (MX) records that specify what hosts will accept mail for a domain. When a client needs to find out information about another host, such as the IP address for mail.acme.net, it queries its local DNS server for that information. The local DNS server responds if it has the information. If it does not have the information it queries other DNS servers until it either finds the information or runs out of places to check. This forwarding of the query is transparent to the client, which connects only to the local DNS server.
If your system accepts mail directly from other hosts on the Internet, it should be listed in the DNS. A DNS MX record is created that routes all mail to your host that processes incoming mail for your domain. Unless you plan to forward all outbound Internet mail to a relay host (a host outside your organization that has better e-mail connectivity), your server must be able to query DNS to deliver messages. You can configure your Microsoft Exchange Server computer to use DNS services from your Internet service provider (ISP), or you can use your own DNS servers. If you maintain your own DNS servers, they must be registered with your parent domain.
If you are using DNS and do not want DNS queries from the Internet to return information about computers on your internal network, configure DNS so external hosts can query for information about your Internet servers but not about other hosts. To do this, you must set up a pair of DNS servers— an external DNS server that you register with your parent domain and configure with address and MX records for your bastion hosts, and an internal DNS server that is used by clients on your network. Configure the internal DNS server to forward queries it cannot resolve to the external DNS server so clients in your network can resolve Internet host names. Your bastion host also should use the internal server for DNS to resolve both internal and external names. Because the external DNS server does not have complete information for your internal network, and because access to your internal DNS server is not available from the Internet, you can hide most of your computers from external DNS queries by not creating records for them on the external DNS server.
Securing Your Internet Connection
You can take advantage of a variety of features provided with Windows NT Server and Microsoft Exchange Server to prevent attackers from damaging your system over the Internet.
Configuring the Internet Mail Service
You can enhance security when connecting to the Internet by configuring the following options on the Internet Mail Service. For information about how to set these options, see Microsoft Exchange Server Operations.
Reject messages by IP address - By default, the Internet Mail Service accepts incoming connections from any IP address. If you want the Internet Mail Service to communicate only with specific SMTP hosts, you can configure it to reject connection attempts from other IP addresses. This makes it more difficult for someone to mount an attack from the Internet against your system.
Set message size limits - You can establish message-size limits for the Internet Mail Service. The default limit applies to both incoming and outgoing mail. If an incoming message from another SMTP host exceeds the specified limit, the Internet Mail Service stops writing data to disk and discards any remaining data. This prevents large messages from filling up the disk on your server, which helps reduce the impact of a denial-of-service attack.
Disable auto-replies to the Internet - The Internet Mail Service can prevent the delivery of automatically generated replies, such as out-of-office replies. When users set up out-of-office replies on their clients, they frequently include a number where they can be reached and also other information. In some cases, this information should not be shared outside the organization. You can configure the Internet Mail Service to disable outbound delivery of automated replies globally or by domain.
Set delivery restrictions - You can restrict what users in your organization have permission to send mail through the Internet Mail Service. For example, you can grant Internet mail access to full-time employees. You can grant or deny Internet mail access to users by configuring the Internet Mail Service Delivery Restrictions property page in the Exchange Administrator program.
Protecting User Accounts
To ensure that someone cannot gain access to your system by impersonating a user, use passwords that are difficult to guess for user accounts. This is especially important for accounts with administrator permissions. You should also limit the number of accounts that are granted administrator permissions.
Using Windows NT File System
You can use Windows NT file system (NTFS) to restrict access to your files and directories and to limit the amount of damage intruders can do if they gain access to a user account. You can also enable auditing of NTFS files and directories through the File Manager. This produces audit records you can review periodically to ensure that no one has gained unauthorized access to sensitive files.
Using and Configuring Services
You should run only essential services on the server and disable any unnecessary services. The fewer the services that are running, the less likely it is there will be a mistake in the service's configuration that an attacker can exploit.
You should also unbind unnecessary services from network adapters that are connected to the Internet. To do this, double-click the Network icon in Control Panel, and then click the Bindings tab. For example, you can use the Server service to copy files from computers in your internal network, but you might not want remote users to have direct access to the Server service from the Internet. To use the Server service on your private network, you can prevent it from binding to any network adapter cards. You can use the Windows NT Server service over the Internet; however, you should understand the security implications and licensing issues of using this configuration.
Transmission Control Protocol/Internet Protocol (TCP/IP) is the only protocol you need to bind to the network adapter card that is connected to the Internet. Make sure routing is disabled so your internal network is isolated from the Internet.
If you decide to bind the Server service to the Internet adapter card, double-check the permissions for your network shares and the permissions for the files in the shared directories.
Connecting to SMTP Hosts with the Internet Mail Service
You can set up a Microsoft Exchange Server with the Internet Mail Service on the bastion host that routes mail between your organization and the SMTP hosts on the Internet. To minimize risk, you can make this a dedicated Internet mail server that does not contain user mailboxes. If an intruder gains access to the bastion host, none of the data stored in users' mailboxes or public folders is at risk because only messages in transit are stored at the bastion host.
If you are using a packet filter, you must configure it to allow TCP connections to and from port 25 on the Exchange Server computer.
Connecting to X.400 MTAs with the X.400 Connector
Request for Comments (RFC) 1006 defines a mechanism for applications defined on the International Standards Organization (ISO) protocol suite to run over TCP/IP. X.400 Message Transfer Agent (MTAs) can use this mechanism to communicate over the Internet. If you are using a packet filter, you must configure it to allow TCP connections to port 102 on the Exchange Server computer. Note that with X.400 authentication, passwords are protected.
Connecting Sites Using the Internet
You can use the Internet Mail Service, the X.400 Connector, or the Site Connector to connect Exchange sites through the Internet. If mail must pass through one or more SMTP hosts to reach its destination, the Internet Mail Service must be used. Note that data is not encrypted when it is sent through these connectors unless messages are encrypted using advanced security.
The Site Connector uses RPCs to communicate between servers. Server-to-server RPC sessions are always encrypted. If you use a packet filter, you must configure it the same as you would when enabling client access over the Internet.
Configuring DNS
If you are using DNS with a packet filtering router, you must configure the router to allow user datagram protocol (UDP) and TCP connections to port 53 on the DNS server.
Enabling Clients to Securely Connect over the Internet
Client computers can connect to mailboxes on Exchange Server computers remotely using TCP/IP over the Internet. By connecting over the Internet, users can read and send mail just as if they were on the same local area network (LAN) as the server. For example, if users from CompanyA need access to mail while visiting CompanyB, they can use CompanyB's Internet connection. Microsoft Outlook does not need to use a modem or Remote Access Service (RAS) to establish a remote connection with Microsoft Exchange Server. However, both the client and the server must support TCP/IP.
You can enable communication over the Internet with the least amount of security risk to your organization by performing these tasks:
| • | Configure your client to use encrypted RPCs. This ensures that messages transmitted over the Internet between a client and a server are secure and no one can tamper with them. For more information about configuring encrypted RPCs, see "Configuring Microsoft Outlook to Use Encrypted RPCs" earlier in this chapter. |
| • | Specify the client's home server using the server's fully qualified domain name (FQDN). This enables the client to locate the home server. |
| • | If the home server and the user account that is accessing the mailbox are in different domains, enable the client to be authenticated by the home server's domain. This gives the user access to the domain where the home server is located. |
| • | If your organization uses an Internet firewall, configure the firewall to allow RPC communication. If a firewall is not used, RPC communication to the Internet is enabled by default. |
Specifying the Home Server
To connect to a Microsoft Exchange Server computer remotely over the Internet, a client must use the server's FQDN. This is because the server name must be in a format that can be resolved over the Internet. Instead of connecting to a server using its computer name (also called a NetBIOS name) as the client on a LAN does, you must specify a name such as server1.acme.com. If the server name is not registered in DNS, you can specify the IP address instead.
To specify the home server name
1. | In Control Panel, double-click the Mail icon, and then click the Services tab. |
2. | Click Microsoft Exchange Server, and then click Properties. |
3. | Under Microsoft Exchange server, type the name of the server that contains the mailbox you want to use. |
4. | Click OK. |
Configuring Authentication by the Home Server's Domain
When users connect to a server using the Internet, they are probably in a different organization that uses a domain other than the one in which their home servers are located. To ensure that the client is authenticated by the server's domain during a remote Internet connection, the user must connect to the home server using a user account that is valid in the home server's domain. To make connecting to the home server easier, the client can be configured to prompt the user for the name and password of the user account in the home server's domain.
To enable the client to be authenticated by the home server's domain
1. | In Control Panel, double-click the Mail icon, and then click the Services tab. |
2. | Select Microsoft Exchange Server, and then click Properties. |
3. | Click the Advanced tab. |
4. | From Logon network security, choose None. |
5. | Click OK. |
Configuring a Firewall to Allow RPC Communication
For client computers to gain access to Microsoft Exchange Server computers remotely over the Internet, the clients and servers must be able to communicate using RPCs. If you are not using an Internet firewall, RPC communication is enabled by default. This configuration is risky because an attacker can gain access to the server and possibly compromise the security of Exchange resources such as mailboxes and public folders.
If you are using a firewall to increase your system's security, you might have to configure the firewall to allow RPC communication. Some Internet firewalls do not accept TCP/IP port numbers that Exchange uses for RPC communication. To solve this problem, add port 135 to your firewall and configure Exchange to use the same ports as your firewall.
To configure Exchange, set two unique port numbers, one for the information store and one for the directory. The registry value TCP/IP Port controls this setting. This DWORD value is a 16-bit number. This value is set for the port that the firewall will accept.
For the directory, you can modify the port numbers in the following registry location:
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \MSExchangeDS \Parameters \TCP/IP Port
For the information store, modify the port number in the following registry location:
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \MSExchangeIS \ParametersSystem \TCP/IP Port
If you are using a packet filter, you must configure it to allow TCP connections to the information store and directory ports in addition to port 135 (for the RPC End-Point Mapper service) on the Exchange Server computer.
To add TCP/IP port numbers
1. | In the Windows NT registry, select the following key: |
2. | From the Edit menu, choose New, and then choose DWORD value. |
3. | In the Name box type TCP/IP Port, and then click Enter. |
4. | Double-click TCP/IP Port. In the Value data box, type the number of the port that the firewall will accept. Set the base to a decimal when entering the value. |
Backing Up a Key Management Server
The KM server database contains the private encryption keys for every user in your entire organization. It is recommended that you back up all KM server data files in the Kmsdata subdirectory (for example, Exchsrvr\kmsdata\*.*) separately from other data and that you make sure these backup tapes are stored in a more secure manner than your everyday backups. All keys in these files are 128-bit RC2 encrypted, so this database is extremely secure.