Security

Keep the following considerations in mind when planning to deploy Windows 2000–based computers. You have the option to deploy smart cards for higher security or to map certificates to user accounts in Active Directory. You also have the option to deploy secure mail with Microsoft Outlook Express.

Deploying Smart Cards

You can deploy smart cards and smart card readers to provide stronger user authentication and nonrepudiation for a range of security solutions, including logging on over a network, secure Web communication, and secure e-mail.

Smart Card Configuration Options

You have the following options when deploying smart cards:

Force Users to Use the Smart Card Logon Process    Allowing the CTRL+ALT+DEL secure logon sequence for smart card users defeats the purpose of using smart cards. During the transition to smart cards, you must enable both logon methods until users are trained and the smart card logon process has been tested for your domains. Thereafter, however, you can configure individual user accounts (but not security groups) so that the CTRL+ALT+DEL secure logon process is disabled and users are forced to use their smart cards to log on to their computers. To configure individual user accounts, use the Active Directory Users and Computers console (a snap-in to MMC).

Force Systems to Lock Upon Removal of the Smart Card    When a user walks away from a computer with an active logon session and the user fails to secure the computer by logging off or locking the computer, an intruder might use the computer for malicious purposes. If you are requiring the use of smart cards for logging on to computers, you can force the systems to lock when users remove their smart cards from the readers. Use this option as necessary to meet your security needs, especially when computers are used in an environment with easy access by the public. You can configure security options under Security Settings in Group Policy to force groups of computers to lock upon the removal of smart cards.

Deploying Secure Mail

In Windows 2000, secure mail is based on the Secure/Multipurpose Internet Mail Extensions (S/MIME) protocol, which extends the original Multipurpose Internet Mail Extensions (MIME) standard. The S/MIME standard enables the digital signing and encryption of confidential mail. Secure mail can be exchanged between S/MIME clients that run on any platform or operating system. Secure mail clients can send S/MIME messages over the Internet without regard to the types of mail servers that handle the messages between the origin of the message and the final destination, because all cryptographic functions are performed on the clients, not on the servers. Mail servers treat S/MIME messages as standard MIME. The only function of Internet mail servers is to route MIME messages; they do not alter the contents of messages in transit.

Secure Mail Clients

Microsoft supports S/MIME in the Microsoft Outlook 98 messaging and collaboration client as well as in Microsoft Outlook Express version 4 and Outlook Express version 5.

Secure mail with S/MIME uses the industry-standard X.509 version 3 digital certificates and public key technology. To provide message authentication, data integrity, and nonrepudiation, secure mail clients can sign messages with the senders private key before sending the messages. The recipients then use the senders public key to verify the message by checking the digital signature. Clients require a valid secure mail certificate before they can send signed mail. Recipients must have a copy of the originators secure mail certificate (which contains the public key) before they can verify the originators signature.

In addition, secure mail clients can send and receive confidential mail. Clients generate random secret bulk (symmetric) encryption keys and use the secret key to encrypt messages for confidentiality. Then they protect the secret bulk encryption key by encrypting it with the public key of each recipient and sending the encrypted key along with the encrypted message to each recipient. Message originators must have a copy of the recipients secure mail certificate (which contains the public key) before they can send confidential mail. Recipients use their private keys to decrypt the secret bulk encryption key; then they use the secret key to decrypt the message.

By using secure mail, senders are assured that the integrity of their messages is preserved and that only the intended recipients can read the encrypted mail. Recipients are assured that the message is genuine and originated from the sender.

The strength of the encryption cryptography that is available for secure mail clients depends on the current export or import restrictions for cryptography that are required by many governments. The actual cryptographic strength that is available to your mail clients depends on the cryptography restrictions that apply for the locality where the mail clients are deployed and for the locality where the mail clients are installed. In general, mail clients with exportable technology provide much weaker security than mail clients with nonexportable cryptography.

Trust for Secure Mail

For secure mail to work, each mail client must have a valid certificate for secure mail and each client must trust the root CA in the certification path of the other clients secure mail certificates. Certificates can be published in Lightweight Directory Access Protocol (LDAP) directories, public folders, and Web pages to facilitate the distribution of certificates and public keys. In Windows 2000, secure mail certificates are published to Active Directory for the user account that is issued a certificate. You also have the option of configuring Certificate Services to publish certificates to public folders, Web pages, or other LDAP-compliant directory services. Users with mail clients that support LDAP, such as Outlook 98 or Outlook Express, can browse directory services to locate and obtain the published certificates of others.

Secure mail clients must trust the certificates from other correspondents. You can configure secure mail for your organization to trust secure mail certificates that are issued by CAs in your organization or to trust secure mail certificates that are issued by third-party CAs. If you trust only the secure mail root CAs in your organization, secure mail communications are limited to transactions between employees. However, you can enable secure mail transactions with third parties by trusting their secure mail root CAs.

Certificate Services for Secure Mail

You can deploy Certificate Services so that it issues secure mail certificates that work with S/MIME-compliant secure mail clients such as Outlook 98 or Outlook Express. You can use the Certificate Services Web enrollment pages to enroll users and issue secure mail certificates. For more information about Certificate Services, see Windows 2000 Certificate Services and Public Key Infrastructure in the Microsoft Windows 2000 Server Resource Kit Distributed Systems Guide .

In addition, you can use a mail service, such as the Microsoft Exchange Server version 5.5 client/server messaging and groupware, to provide management services for secure mail. You can deploy Exchange Server and use the Key Management server (KM server) to manage secure mail certificate enrollment for Certificate Services. You can also use KM server to provide key recovery services as described in the following section. For more information about KM Server, see Exchange Server Help and the Microsoft BackOffice Resource Kit .