Every user, process, and service is required to enter a unique login name and password to gain access to the system. The operating system's interactive two-step security process of checking the login name with the password is known as authentication.
Microsoft Exchange Server enables the operating system to ascertain the identity and handle the validation of users and processes. The identity is the username and the validation is the user password. The operating system then will establish the security context, which explains and controls what kind of access will be granted to the user or process.
When a user or process logs in to the Windows NT server, there is no need for any other usernames or passwords to achieve access to Microsoft Exchange Server. This feature is unlike other types of message-system security features.
For example, suppose that a LAN Administrator on a Novell NetWare 3.1x is located on Server1 and the Microsoft Mail 3.x post offices and utilities are located on Server2. The administrator is required to enter a username and password for initial access to Server1. An additional username and password is needed for access to the directory structure on Server2. Moreover, a third username and password is needed to finally access the Admin program. Other message systems, such as Lotus cc:Mail, have similar security policies.
Each user or resource within a single location, such as the Microsoft Exchange Server, is a member of a particular domain. A domain is either a single Microsoft Windows NT server or multiple Windows NT servers that use the same security scheme and user-account database. Only one username and password is required to recognize, authenticate, and establish a connection to all the Windows NT servers and their resources in the domain.
Multiple domains or separate domain remote sites can connect by way of a trust relationship. This connection between the domains enables users on one domain to access resources within the other domain. When the domains are in a trusted relationship, one domain (trusting domain) trusts the other (trusted domain). Any user located in the trusted domain can gain access to objects within the other domain.
For example, a user at Software Spectrum located in Garland who logs on to Domain A wants access to a resource on Domain B. Because Domain B, located in Los Angeles, has a trusted relationship with Domain A, the Domain B resources are available to this user. This situation is known as passthrough authentication, which allows having only one user account on one domain and the capability to access resources on the other.
Windows NT accounts are the principal structure upon which authentication is based. Accounts consist of two main elements: the user ID and the associated password. These two fundamental bits of information provide the key to access various services. Two main types of Windows NT accounts exist:
Single and multiple user accounts can be associated with a Microsoft Exchange Server mailbox. The user attempting to establish a connection with a Microsoft Exchange server must be located within the same domain as the Microsoft Exchange server to which the user is trying to connect. If the user and the Microsoft Exchange server are located on different domains, the domains must be in a trusted relationship.
As another example, a user on Domain A at Software Spectrum in Garland wants to acquire access to a Microsoft Exchange server located on Domain B in Los Angeles, but in this case, Domain A and Domain B do not have a trusted relationship. The user on Domain A cannot establish a connection with the Microsoft Exchange server located on Domain B.
On the Microsoft Windows NT server, an assortment of services is initiated when the system goes through its startup process. The Microsoft Exchange Server information store service and MTA established connections are good examples of services that run on a Microsoft Windows NT Server. These services, through a user account known as a service account, log on to the system and start up automatically.
The service account is an important feature to Microsoft Exchange Server. Create this account before beginning the installation of Microsoft Exchange Server. This account affects the installation of and communication establishment between other Microsoft Exchange servers. When you install and join a new Microsoft Exchange server to a site with an existing Microsoft Exchange server, the service account is requested to complete the installation. The service account must be the same on all servers within a site. Without this account, Microsoft Exchange servers in the same site will not be able to communicate with each other. If a site extends over multiple domains, only one service account is needed, provided that a trust relationship exists between domains.
When a user logs on to a Microsoft Windows NT Server, the security features of the operating system look to the security context (covered previously in this chapter) for information determining the permissions to access specific network resources. A permission controls access to individual objects located in the system that use specific authorization information. Each object is different and, consequently, has different levels of permissions.
The following list shows the variety of permissions to control access that Microsoft Exchange Server offers:
Each of the permissions is discussed in detail in following sections of this chapter.
The Administrator program is the application used to grant permissions to log on and gain access to a Microsoft Exchange Server mailbox. One mailbox can have either one or multiple user accounts with the user permission set for it.
Microsoft Exchange Server reviews all user accounts for the user permission when a logon is attempted. After the review completes, it verifies whether or not the user attempting to log on has this permission.
Using the Microsoft Exchange Client, the owner of a public folder can grant permission to the following areas to access it:
As stated previously, different objects have different levels of permissions. The owner of a public folder can grant others the following permissions:
The public folder, similar to other Windows NT resources, reviews the user accounts for permissions for this resource. Then the folder verifies that the object trying to access it has the appropriate permissions.
As an example, Software Spectrum has created two differing distribution lists within a Financial public folder on the Microsoft Exchange Server Accounting and Accounting Managers. The permissions can be modified on the Financial public folder so that members of the Accounting group have Read Access, and the Accounting Managers may have Read and Write permissions.
Applying permissions to directories is different than applying permissions to public folders. With directories, the permissions are granted directly to the user's account database. Within the Administrator application, although all users can see the directory listed, unless the users have the correct permissions, they cannot view the data inside the directory. A good example of a directory permission is Add Child. With this permission on the Recipient Container, a user can create mailboxes.
Roles are another way of making administrative tasks easier. Roles consist of built-in groups of certain kinds of similar permissions. For example, the following list shows the built-in permissions for the Admin role:
Sets of user accounts with similar network resource needs can be placed into a group. This action simplifies the administrative task of adding permissions to individual users. If a group named MIS is created, all members of this group automatically have the permissions that are granted to the group, and these permissions are applied to the individual user. Any user accounts that are created after the group was created, or existing users who become additional members of this group, will have the same group permissions applied. Likewise, if the permissions of the group are modified, all members of the group will have their permissions changed. Microsoft Windows NT Server offers built-in local and global groups with the capability to also create local and global groups. When possible, a good recommendation is to use groups. Using groups diminishes the amount of time spent dealing with administrative tasks.
Local Groups Only the domain where the local group exists will contain the definition of resource permissions for this group. Additionally, no matter which domain the local group is located in, permissions can be granted only to that particular domain's resources. Local groups may contain the following:
NOTE: Local groups cannot contain other local groups from the same domain.
Global Groups Groups that can use resources within other domains are known as global groups. Global groups consist of a group of user accounts that was given access to permissions and rights for the following:
Global groups also can be members of local domain groups.
In essence, the creation of global groups allows sets of users from within a particular domain and the available use of network resources, from both inside and outside the domain.
Microsoft Windows NT has built-in auditing capabilities that allow the operating system to track events that occur within the system to detect security breaches. This tracking is an advantage for the Microsoft Exchange Server system. As discussed previously, the operating system handles the identity and validation of users for Microsoft Exchange Server. Moreover, the Microsoft Windows NT Server operating system can be modified to audit the Microsoft Exchange Server event services and directory objects. These events show up in the Windows NT event log.
NOTE: Microsoft Exchange Server administrators do not require permissions to administer to the Microsoft Windows NT Server.
Microsoft Exchange Server provides confidentiality by encrypting the destined message. When the message is sent, the data-encryption security feature scrambles the message. If you viewed the message in this scrambled state, it would resemble a bunch of random alphanumeric characters. When the message is received at its destination, it is decrypted and put back together in the original format.
Microsoft Exchange Server supports the following two standards to complete this security task:
NOTE: The Data Encryption Standard (DES) is available with Microsoft Windows NT Server software in Canada and the United States.
When a user chooses Secure Message with Encryption from the toolbar, all of the recipients' certificates are retrieved from the directory. Next, a bulk encryption key is created to encrypt the message. Finally, the user's public encryption key is extracted from the certificate and placed in a lockbox. This action prevents the encryption key from being used while the encrypted message is in transit. The lockbox and the encryption key are then sent to the recipient.
When the recipient receives and opens the message, the encryption key is used to decrypt the lockbox, and the bulk encryption key from within the lockbox is used to decrypt the message. See Figure 27.1.
FIG. 27.1 Sending and receiving an encrypted message.
As mentioned previously, Exchange uses several of Windows NT's built-in C2-level security features. To augment this security, Exchange adds digital signatures and message encryption. To enable these advanced security features, you must designate one server within your organization that manages a special security database. This server is known as the Key Management (KM) Server. Before discussing how the KM Server works with digital signatures and message encryption, make sure that you understand keys, tokens, certificates, and Exchange's revocation list.
Each mailbox created within Microsoft Exchange Server is given two pairs of electronic keys. One key pair, used for signing and verifying actions, is created by the Microsoft Exchange Client. The other pair, used for encrypting and decrypting operations, is generated by the KM Server. The private key is known only by the user, and a public key is known by the public (it can be accessed by other mail users). This key type of security features is known as public/private key technology, a data-encryption industry standard.
The Microsoft Exchange Client, located on the user's local hard disk, stores the private keys in an encrypted security file (with the extension .EPF), within the client's local directory structure. The private encryption key is used for decrypting messages destined for the user's mailbox. The private signing key is used for signing messages when they are sent.
For every message recipient, each of their public encryption keys is used when the original message composer sends an encrypted message. The multiple public encryption keys are used to complete the encryption process. When each recipient receives the encrypted message, his or her public signing key is used to verify the identity of the message sender or composer.
Another key used by the Microsoft Exchange Server is the bulk encryption key. This key is used in conjunction with both the public and private encryption keys. The bulk encryption key is used to encrypt the original message. The key then is placed into a lockbox, where it is kept to protect the key during transit. If the message has multiple recipients, a lockbox is attached to the message for each of the recipients. When the message is received at the recipient's location, the bulk encryption key is extracted from the lockbox and used to decrypt the original message.
The Certificate Authority (CA) is the Key Management Server component that generates signing and encrypting certificates. Certificates bind the user's public key to the user's mailbox. The CA certifies the genuineness of those public keys created for users. Users have two kinds of certificates: an encryption certificate and a signing certificate. The encryption certificate is an attribute of the mailbox and contains the user's public encryption key. The signing certificate is contained in the user's security file on the local hard disk drive. It holds the user's public signing key.
Microsoft Exchange supports the industry standard X.509v3 certificate type. Certificates that conform to the X.509v3 standard contain detailed identification information about the certificate-holder, including the type of business the certificate-holder operates and the number of years in business. Such detailed information prevents someone from masquerading as a stock broker, for example.
Because it supports the X.509v3 standard, Exchange Server will accept certificates that have been issued by certificate authorities such as VeriSign or the Certificate Server included with Internet Information Server 4.0. Likewise, by using Certificate Trust Lists, clients can trust X.509 certificates issued by these certificate authorities.
NOTE: Support for X.509v3 certificates will be included in the first service pack.
The certificate also contains the following information:
Exchange also supports the revocation of security certificates. This action permanently deactivates the security certificate for a mailbox. This should be done only when you are absolutely sure that you do not need to recover the security keys in the future. When the security certificate is revoked for a mailbox, anyone attempting to open an encrypted message previously sent from this mailbox is prompted with a warning, informing him or her that the message was secured with a revoked security certificate.
The revocation list contains the serial number and expiration date of all revoked certificates. This ensures that the revoked user's mail account cannot be used by unauthorized personnel. The user then can be reconfigured for advanced security and another certificate issued. Reconfiguration will issue another token and another certificate serial number and expiration date.
You may want to consider revoking advanced security when the following situations exist:
All revoked certificates originate in the KM Server database and are distributed to all the clients. Each client caches the original list and receives a daily update from the KM Server. For performance reasons, revoke users judiciously. When a message reaches its recipient and the signature is verified, it must be checked against the list before the message can be decrypted. The more certificates are contained in the list, the more the advanced security and performance of the client will degrade.
When a mail administrator activates advanced security for a user, a temporary security token is generated. This random eight-digit code not only enables digital signing and data encryption, but also can be recovered if lost. The token should be loaded on the local workstation. Tokens are used only once, to secure a connection with the KM server and complete the advanced security setup for Microsoft Exchange Server advanced security users.
One Microsoft Exchange Server integrated component is the Key Management Server, which is the central point for advanced security within the system. The Key Management Server provides the following services:
All private encryption keys, public signing keys, and the revocation list are stored in the key management database. For additional security, the KM Server database itself is encrypted.
Each user that you want to use advanced security must be configured after the KM Server is configured. The users are given a temporary token to allow access to the KM Server so that the advanced security features setup can be completed.
When the Key Management Server is properly set up and advanced security is activated, users can take advantage of Exchange's digital signatures and message encryption.
Microsoft Exchange Server provides End-to-End Authentication and Data Integrity through the use of Digital Signatures, which are based on a user's signing keys. Two processes, signing and verifying, are involved.
When a message is to be sent, the sender selects Digitally Sign Message. It then will have a "signature" placed on it. The signature, or signing key, claims that the message was derived from the indicated source. The name on the header is matched with the sender's name. This matching prevents forgeries. Before the recipient can receive the message, the destination verifies the signature on the message.
After the message is signed, it is transformed to message hashes, which are a unique representation of a message. Moreover, the hashes are then encrypted. The original message and the encrypted hash message are then sent with the signing certificate to the destination. The signing certificate contains the sender's signing key.
When the message reaches its recipient, the message is verified when user chooses Read Digital Signature from the toolbar. First, the sender's certificate is checked against the revocation list. If it is on the list, the recipient is notified that this user was revoked from the system. Next, the original message is hashed as the encrypted hash message is decrypted. These two messages, both in hashed states, now can be compared to each other. If the hashes don't match, the message has been modified in transit and the user is notified. This feature allows for built-in data integrity verification. See Figure 27.2 for an illustration of how messages are sent and received by using digital signatures.
FIG. 27.2 Sending and receiving a message with a digital signature.
The Key Management Server, which is a component of Microsoft Exchange Server, is the central point for advanced security. The following steps show what is involved to set up and maintain Microsoft Exchange Server advanced security:
Only one Microsoft Windows NT Server in the organization that is running Microsoft Exchange Server can become the Key Management Server (KM Server) and manage the Key Management advanced security database. Having multiple KM Servers can cause authentication and encryption errors. When deciding which Microsoft Exchange Server to use as the KM Server, keep the following important points in mind:
Before installing Microsoft Certificate Server, you must have successfully installed Microsoft Internet Information Server version 4.0 on a computer running Microsoft Windows NT version 4.0. In order to install the Key Management component software, the setup process asks for two passwords. One password is copied to a floppy disk. This option can be deselected on the property page during the beginning of the setup. If the copy is deselected, the setup process displays the password onscreen. It's recommended to write down this password.
The steps to install your Key Management component software are described in Chapter 6, "Installing Exchange Server."
NOTE: At the time of this writing, the author team had the most current release of the Exchange 5.5 Release Candidate 1. Unfortunately, Key Management Server (KM) was not included. In the final release of Exchange 5.5, KM could load as part of the initial installation of Exchange. When the information becomes available, the authors will post it as errata on Que's Web site at www.mcp.com.
The Key Management Server Service must be started to enable and configure advanced security for individual users. Follow these steps:
NOTE: If a KM Server Startup Floppy Disk wasn't created, the password that was displayed on-screen during the setup process must be input within the startup parameters for the KM Server service. To do this, go into Control Panel, Services and highlight the KM Server service. Choose Startup and enter the password in the Log on As section.
Important: Please write this password down somewhere. This password cannot be changed without reinstalling the component. This password is needed by the KM Server Service to start up. This is the password that would otherwise be placed on the floppy disk.
The Key Management Server requires an Advanced Security Administrator's password to modify any security-related items. This password is separate from any other passwords, which were explained in previous chapters. This password is specific for security-related administrative tasks.
If this is a new install or if the advanced security password has never been changed, take the following steps:
NOTE: If the password has never been changed for any reason, the default password is password.
To allow users to digitally sign and encrypt messages, advanced security must be enabled for each recipient. With the KM Server in production, after the advanced security setup process for a user is initiated, an RPC call is made to the KM Server, which generates and returns a token.
Exchange 5.0 clients can individually exchange security keys and certificates, even between different organizations. This allows them to exchange signed and encrypted messages, even over the Internet. In previous versions, this function was limited to other Exchange users inside your organization.
Before you can send someone encrypted keys, or verify their digital signature, you must first obtain a trusted copy of their "public security keys." For users inside your organization, these keys are stored in the Global Address List for easy access. Exchange users outside of your organization must send you their public keys that can then be stored in your Personal Address Book for future use.
To send public security keys to a user in another organization, follow these steps:
On the receiving end:
They can now verify the sender's digital signature and send encrypted mail. In turn, they can also send you their public security keys to enable full two-way secure e-mail.
Both the sender and receiver have a VERIFY SECURITY KEYS button on their e-form. This button provides a way for the receiver to ensure that the public keys the person sent are in fact the same public keys received. If you call the sender on the phone and ask him to click the VERIFY SECURITY KEYS button on the form sent (in the Sent Mail folder), he can read you the numbers from his screen, which form a unique "fingerprint" that identifies his keys. The receiver can do the same on the copy of the keys received. If the numbers match, you can be sure that the keys were not tampered with while traveling over the public Internet.
Users located in remote sites cannot be directly set up for advanced security because the KM Server uses RPC calls, but the users still can be set up for advanced security in an indirect manner. The Key Management Administrator can enter the names of the users located at remote sites from a site that contains the KM Server. The tokens are generated for the individual users in the same manner that users located in the local site are generated. Then, the tokens must be securely transferred to the individual users for final setup of the client. Such transfers of token information are done "out of band" by a phone call, fax, or alternative means of communication.
The Microsoft Windows NT Server logs information about the Key Management Server in the applications Event Viewer, which includes information regarding the KM Server functions and duties. If the option is used when launching the KM Server (this is done under the Control Panel, Services icon, within the Startup Parameters option), the events also will be shown in the KM Server command box.
All log information regarding the Key Management Server that is being recorded in the Event Viewer is identified by an MSexchangeKM entry in the source column.
Events that are generated by the Key Management Server are related to granting and revoking of permissions, security violations, and the internal operation of the KM Server. All events logged can be viewed in the Event Viewer.
All advanced security data is stored in the SECURITY\MGRENT folder. This directory structure should be backed up on a regular basis. Any Microsoft Windows NT-compatible backup application can be used to archive the advanced security directory structure.
The two services that must be running at the start time of the backup are the Information Store service and Directory service.
Microsoft Exchange Server 5.5 supports the S/MIME specification for secure electronic messaging. S/MIME was codeveloped in 1995 by several software vendors and makes it easy to secure messages from prying eyes. Using S/MIME requires an S/MIME-aware client like Outlook Express or Netscape Communicator.
NOTE: Support for S/MIME will be included in the first service pack.