Copyright
©1996, Que Corporation. All rights reserved. No part of this book
may be used or reproduced in any form or by any means, or stored in a database
or retrieval system without prior written permission of the publisher except
in the case of brief quotations embodied in critical articles and reviews.
Making copies of any part of this book for any purpose other than your
own personal use is a violation of United States copyright laws. For information,
address Que Corporation, 201 West 103rd Street, Indianapolis,
IN 46290 or at support@mcp .com.
Notice: This material is excerpted from Special Edition Using Microsoft Exchange Server, ISBN: 0-7897-0687-3. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.
Exchange relies on the C2-level security included within Windows NT for a portion of its structure. C2-level security is a U.S Department of Defense rating defined. It provides for discretionary access control (users, groups, etc.), object reuse protection (protecting deleted data), mandatory log on, and auditing of security related events. Windows NT can provides user authentication, resource access, and auditing. Each of these areas is described in this chapter. Exchange increases security with digital signatures and message encryption.
In this chapter, you learn about the following:
Understanding NT Authentication
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 user 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 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 is unlike other types of message-system security features.
For example, a LAN Administrator on a Novell Netware 3.1x located on Server1 and the Microsoft Mail 3.X postoffices 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.
Defining NT's Domain Architecture
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 allows users on one domain the capability 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 Digital Genesis located in Los Angeles who logs on to Domain A wants access to a resource on Domain B. Because Domain B located in Boston 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.
The Types of NT Accounts
Window NT accounts are the principle structure upon which authentication is based. Accounts consist of the two main elements, the user id and the asociated password. These two fundamental bits of information provide the key to access various services. There are two main types of Windows NT accounts:
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 Digital Genesis in Los Angeles wants to acquire access to a Microsoft Exchange Server located on Domain B in Boston, 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 are initiated when the system goes through its startup process. The Microsoft Exchange Server information store service and MTA establish 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 onto the system and startup automatically.
The service account is an important feature to the Microsoft Exchange Server. Create this account previous to beginning the install 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 accont is needed, provided that a trust relationship exists between domains.
Introduction to NT's Access Control
When a user logs on to a Microsoft Windows NT Server, the security features of the operating system looks to the security context (covered previously in this chapter) for information determining the permissions to access specific network resources. A permission controls access to a individual objects located in the system that uses specific authorization information. Each object is different and, subsequently, 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 are 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 log on 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 permissionto the following areas to access it:
As stated above 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, Digital Genesis 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:
Organizing NT Groups and Permissions
Sets of users accounts with similar network resource needs can be placed into a group. This action simplifies the administrative tasks 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 users 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.
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:
Local groups cannot contain other local groups from the same domain.
Groups that can be use resources within other domains are known as Global groups. Global groups consists 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.
Using NT's Auditing Capabilities
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 traking 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.
Microsoft Exchange Server Administrators do not require permissions to administer to the Microsoft Windows NT Server.
Using Exchange's Advanced Security
As mentioned previously, Exchange uses several of 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 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 users 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, their 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 the 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 lock box is attached to the message for each of the recipients. When the message is received at the recipients location, the bulk encryption key is extracted from the lock box and used the decrypt the original message.
The Certificate Authority (CA), is the Key Management Server component that generates signing and encrypting certificates. Certificates bind the users public key to the users 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 users public encryption key. The signing certificate is contained in the users security file on the local hard disk drive. It holds the users public signing key.
The certificate also contain 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 them 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 makes sure 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 also 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 that are contained in the list, the more 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 8-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 setup 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 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 figre 25.1 for an illustration of how messages are sent and received by using digital signatures.
Fig. 25.1
Sending and receiving a message with a digital signature.
Introduction to Data Encryption
Microsoft Exchange Server provides confidentiality by encrypting the destined message. When the message is sent, the data-encryption security feature takes and 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:
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 users public encryption key is extracted from the certificate and placed in a lock box. This action prevents the encryption key from being used while the decrypt the message in transit. The lock box 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 lock box and the bulk encryption key from within the lock box is used to decrypt the message.
Fig. 25.2
Sending and receiving an encrypted message.
Using Key Management Server
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 setup 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:
In order to install the Key Management component software, the setup process asks for two passwords. One passwords 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 on-screen. It's recommended to write down this password.
Do the following steps to install your Key Management component software:
1. Launch SETUP.EXE from the Microsoft Exchange Server CD-ROM for your appropriate CPU (\SETUP\i386\EXCHKM for Intel processors).
2. Choose Continue to bypass the Welcome screen.
3. Enter Full Name and Organization information, and then choose OK to continue.
4. Confirm Full Name and Organization information.
5. Choose OK to bypass the Product ID information.
6. Setup shows a screen with the default directory (C:\SECURITY). If the default directory is OK, press continue and skip to step 10.
7. Click the change folder icon to change the directory to which setup will install the files.
8. Select the directory in which install needs to install the files.
9. If directory doesn't exist, choose OK to confirm its creation.
10.Choose OK to continue.
11. Click the Typical button to execute the install. KM Server then installs with all options.
12. The next screen asks about the Country Code selection and the creation of KM Server Startup floppy disk. Accept defaults, choose OK, and skip to step 15.
13. If you need to change the country code, select the correct country code.
14. If the decision is made to go with a diskless setup, de-select (clear the check box) the box beside the option. Choose OK to continue.
If there is not a KM Server Startup floppy disk created, the password for the Key Management Serverservice is displayed on the screen.
Important: Please write this password down somewhere. This password cannot be changed with reinstalling the component. This password is needed by the KM Server Service to startup. This is the password that would otherwise be placed on the floppy disk.
15. If defaults were accepted from Step 12, a request to insert a blank floppy disk in drive A appears. Insert the blank floppy disk and choose OK.
16. To complete a successful setup, click OK.
The Key Management Server service must be started to enable and configure advanced security for individual users.
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.
1. Log on to Microsoft Windows NT Server as Administrator.
2. Select the Main program group, then Control Panel, and finally Services.
3. Locate the Key Management Server service entry, highlight it and click the Start button. Refer to the preceding Note, regarding diskless KM Server setups.
4. After displaying a message about starting the services, the Key Management Service status changes to Started.
5. Close the Services applet and exit Control Panel.
The Key Management Server requires an Advanced Security Administrators 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:
1. Launch Microsoft Exchange Server Administrator program.
2. Connect to a Microsoft Exchange Server.
3. Click on the Configuration container.
4. Choose the Encryption object and open its property pages.
5. Click the Security tab.
6. Choose Key Management Administrators.
7. Enter the Advanced Security Administrator password.
If the password has never been changed for any reason, the default password is PASSWORD.
8. Click Change Password, then type the old password into the Old Password box, and then type your new password in the New Password box. You then are asked to verify the new password.
9. Choose OK to save the changes.
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.
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 input 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 is done Òout of bandÓ by a phone call, fax, or other alternate means of comunication.
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 [ms]a option is used when launching the KM Server (this is done in Control Panels, Services Icon, within the startup parameters option), the events also will be shown in the KM Server command box.
1. Open the Administrative Tools program group from the Windows NT Server Program Manager.
2. Launch the Event Viewer.
3. From the Log menu, select Applications.
All log information regarding the Key Management Server that is being recorded in the Event Viewer are identified by a 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.
From Here...
This chapter described the rich security features available within NT and Exchange. With the proper use, you can guarantee your users a robust messaging system while maintaining message integrity and system security.
For related information, see the following chapters:
For technical support for our books and software contact support@mcp.com
Copyright ©1996, Que Corporation