Lesson 1: Ensuring Message Integrity Chapter 12 617 S/MIME is a standard for public key encryption and signing of MIME data. S/MIME provides authentication, message integrity and nonrepudiation of origin (using digital signatures), and privacy and data security (using encryption). Before you can use S/MIME for public key cryptography, you need to obtain and install a certicate either from your organization’s internal certicate authority (CA) or from a trusted third-party CA. An internal certicate can be used in-house only, as it is not trusted by external organizations. Typically, S/MIME clients require the installation of a certicate before permitting users to send encrypted messages. OWA and S/MIME A public key infrastructure (PKI) uses digital certicates to verify and authenticate the validity of each participant in an electronic transaction. You need to install Certicate Services on a member server in your organization to deploy a Windows PKI. A PKI enables your organization to publish its own certicates. Clients can request and receive certicates from a PKI on the internal network, and the PKI can renew or revoke certicates. Chapter 5, “ Conguring Client Access”; Chapter 6 “Federated Sharing and Role-Based Access Control”; and Chapter 7, “Routing and Transport Rules” discuss the use of certicates. OWA users can use S/MIME to encrypt outgoing messages and attachments so that only intended recipients who have a digital identication (a certicate) can read them. Users digitally sign a message, which enables its recipients to verify the identity of the sender and that the message has not been tampered with. Users must have a digital ID and must install the S/MIME control for OWA before they can send encrypted and digitally signed messages or read encrypted messages using the OWA client. The S/MIME control is necessary to verify the signature on a digitally signed message. It is installed on a client computer by using the SMIME tab in Options. When they use S/MIME, users have access to features that are not otherwise available in OWA. They can, for example, do the following: n Attach messages to other messages n Paste images into messages n Attach multiple les in a single operation However, if the S/MIME control is installed in OWA, WebReady document viewing works in only clear-signed messages, not in encrypted messages or opaque-signed messages. When certain content types are sent from Outlook as S/MIME messages, they are not displayed in OWA. In such cases, OWA displays a banner in the message header. When a user opens a folder in another mailbox or uses explicit sign-in to open another user’s mailbox, most S/MIME features are not available. In such cases, the only S/MIME feature that is available is verication of digital signatures. MORE INFO WEBREADY DOCUMENT VIEWING For more information about WebReady document viewing, see http://technet.microsoft .com/en-us/library/aa995967.aspx. 618 Chapter 12 Message Integrity, Antivirus, and Anti-Spam Enabling and Disabling S/MIME in OWA You can use the Exchange Management Console (EMC) or the Exchange Management Shell (EMS) to enable or disable S/MIME in OWA. To use the EMC, carry out the following procedure: 1. Open the EMC and expand the tree in the Console pane. 2. In the console tree, click Client Access under Server Conguration. 3. At the top of the Result pane, click the server that hosts the OWA virtual directory. 4. On the Outlook Web App tab under the server name, click Owa (Default Web Site). 5. In the Actions pane under Owa (Default Web Site), click Properties. 6. On the Owa (Default Web Site) Properties dialog box, click the Segmentation tab. 7. In the Segmentation window, click the SMime, as shown in Figure 12-1. FIGURE 12-1 Selecting the SMime feature on the Segmentation tab 8. Click Enable or Disable as appropriate. 9. Click OK to save your changes and close the Properties dialog box. By default, S/MIME is enabled. To use the EMS to disable S/MIME on the OWA virtual directory in the default Internet Information Services (IIS) website on the local server, enter the following command: Set-OWAVirtualDirectory -Identity "owa (Default Web Site)" -SMimeEnabled $false Lesson 1: Ensuring Message Integrity Chapter 12 619 To enable S/MIME when it has previously been disabled, enter the following command: Set-OWAVirtualDirectory -Identity "owa (Default Web Site)" -SMimeEnabled $true Neither of the previously listed EMS commands generates an output. If the command completes without error, the change has been made. MORE INFO SET-OWAVIRTUALDIRECTORY For more information about the Set-OwaVirtualDirectory EMS cmdlet, see http://technet .microsoft.com/en-us/library/bb123515.aspx. Managing S/MIME for OWA You manage S/MIME for OWA by using the Regedit utility to edit the registry on an Exchange Server 2010 Client Access server. Changes are made on a per-server basis, and if you have more than one Client Access server and you need the same S/MIME behavior on all such servers, you need to make the same changes on each server. Changes to the S/MIME settings in the registry take effect immediately. Users do not need to sign out or to restart any services. The registry settings that control S/MIME behavior on a Client Access server can be found by accessing the following registry key: HKLM\System\CurrentControlSet\Services\MSExchange OWA\SMIME As shown in Figure 12-2, the settings that control S/MIME are not in the registry by default, and you need to add them. Table 12-1 shows some of the settings you can use. This list is not exclusive. FIGURE 12-2 The registry key that holds settings that control S/MIME behavior 620 TABLE 12-1 Settings that control S/MIME behavior NAME AND TYPE VALUES EXPLANATION CheckCRLOnSend (DWORD) 1=True, 0=False (default). If a certicate revocation list (CRL) distribution point in a sender’s certicate chain cannot be accessed during revocation verication when sending signed or encrypted email, OWA will indicate a failure and prevent the email message from being sent when CheckCRLonSend is set to true. DLExpansionTimeout (DWORD) A value in milliseconds. The default is 60000 (60 seconds); the range is 0 through 2147483647. This attribute controls how long OWA waits for a distribution list in Active Directory to expand when sending encrypted email before the operation fails. A zero setting disables the ability to send encrypted email to distribution lists. When this parameter is set to its maximum value, OWA waits until the distribution list is expanded regardless of how long expansion takes. UseSecondaryProxiesWhenFindingCerticates (DWORD) 1=True (default), 0=False. OWA matches a certicate in Active Directory for a recipient when sending encrypted email. The certicate subject or subject alternative name can contain a Simple Mail Transfer Protocol (SMTP) address as one of its values. If the value of this parameter is set to true, OWA accepts certicates that do not match the primary SMTP address of the recipient as valid. If the value is set to false, OWA accepts only certicates that match the primary SMTP address of the recipient as valid. CRLConnectionTimeout (DWORD) A value in milliseconds. The default is 60000 (60 seconds); the range is 5000 through 2147483647. This setting species the time that OWA waits while connecting to retrieve a single CRL as part of a certicate validation operation. If the CRL is not retrieved before the time expires, the operation fails. If the setting is less than 5000, the default value (60000) is used. If the maximum value is specied, the connection does not time-out. 621 CRLRetrievalTimeout (DWORD) A value in milliseconds. The default is 10000 (10 seconds); the range is 0 through 2147483647. This setting species the time that OWA waits to retrieve all CRLs when validating a certicate. If all CRLs are not retrieved before the specied time expires, the operation fails. Disable CRL Check (DWORD) 1=True, 0=False (default). If true this setting prevents CRLs from being checked while certicates are being validated. Disabling CRL checking can decrease the time it takes to validate signatures. However, it shows revoked email messages signed with revoked certicates as valid instead of not valid. AlwaysSign (DWORD) 1=True, 0=False (default). If true this setting requires users to digitally sign email messages when they use OWA with the S/MIME control. The OWA Options page and the Message Options dialog box show the “Send signed e-mail” option as selected. AlwaysEncrypt (DWORD) 1=True, 0=False (default). If true this setting requires users to encrypt email when they use OWA with the S/MIME control. The OWA Options page and the Message Options dialog box show the “Send encrypted e-mail” option as selected. ClearSign (DWORD) 1=True (default), 0=False. If true this setting requires any digitally signed email message that is sent from OWA to be clear-signed. If false this setting causes OWA to use an opaque signature. IncludeCerticateChainWithoutRootCerticate (DWORD) 1=True, 0=False (default). If this setting is true, signed or encrypted email will include the full certicate chain, except for the root certicate. By default, OWA includes only the signing and encrypting certicates and not their corresponding certicate chains when sending signed or encrypted email. 622 Chapter 12 Message Integrity, Antivirus, and Anti-Spam MORE INFO MANAGING S/MIME FOR OWA For more information about managing S/MIME for OWA, including additional registry settings you can add to the registry on Client Access servers, see http://technet.microsoft .com/en-us/library/bb738151.aspx. NOTE CLEAR AND OPAQUE-SIGNED EMAIL MESSAGES Clear-signed email messages are larger than opaque-signed (encrypted) messages, but they can be opened and read using most email clients, including clients that do not support S/MIME. CAUTION Edits to the registry take effect immediately without requiring conrmation. Take care when editing the registry. MORE INFO OWA SECURITY For more information about OWA security, including other methods of authentication, see http://technet.microsoft.com/en-us/library/bb124507.aspx. MORE INFO UNDERSTANDING S/MIME For general information about S/MIME, see http://technet.microsoft.com/en-us/library/ aa995740(EXCHG.65).aspx. Using TLS and MTLS The TLS and MTLS protocols, introduced in Chapter 7, provide encrypted communications and end-point authentication over network connections such as Internet connections. Server- to-server connections (for example, connections between SMTP servers on an organizational internetwork or the Internet) rely on MTLS for mutual authentication. On an MTLS connection, the server originating a message and the server receiving it exchange certicates from a mutually trusted CA. The certicates prove the identity of each server to the other. The TLS protocol provides secure web communications on the Internet or intranets. It enables clients to authenticate servers and (optionally) servers to authenticate clients. It provides a secure channel by encrypting communications. However, when TLS is deployed, it typically provides only condentiality in the form of encryption. Sometimes no authentication occurs between the sender and the receiver, and sometimes only the receiving server is authenticated. For example, the Secure Sockets Layer (SSL) protocol, which is the Hypertext Transfer Protocol (HTTP) implementation of TLS, authenticates only the receiving server. Lesson 1: Ensuring Message Integrity Chapter 12 623 When using MTLS authentication, on the other hand, each server veries the identity of the other server by validating a certicate provided by that server. When messages are received from external domains over veried connections in an Exchange Server 2010 environment, Microsoft Outlook displays a Domain Secured icon. MTLS is a manageable technology for implementing the various features required for domain security, such as certicate management, connector functionality, and Outlook client behavior. In Exchange 2010, Setup creates a self-signed certicate, and TLS is enabled by default. This enables any sending system to encrypt the inbound SMTP session. Exchange Server 2010 also attempts to use TLS for all remote connections by default. All trafc between Edge Transport servers and Hub Transport servers is authenticated and encrypted using MTLS. Exchange Server 2010 uses direct trust to authenticate the certicates. Active Directory is considered a trusted storage mechanism, and the certicate is validated because it is present in Active Directory or Active Directory Lightweight Directory Services (AD LDS). When direct trust is used, it does not matter whether the certicate is self-signed or signed by a CA. When you subscribe an Edge Transport server to the Exchange organization, the Edge subscription publishes the Edge Transport server certicate in Active Directory for the Hub Transport servers to validate. The Microsoft Exchange EdgeSync service updates AD LDS with the set of Hub Transport server certicates for the Edge Transport server to validate. MORE INFO EDGE SUBSCRIPTIONS AND THE EDGESYNC SYNCHRONIZATION PROCESS For more information about Edge subscriptions and the EdgeSync synchronization process, see http://technet.microsoft.com/en-us/library/aa997438.aspx. Chapter 5 introduced certicates and the Active Directory Certicate Services role. TLS and MTLS require a certicate for authentication of inbound connections to a front-end server (for example, an Edge Transport server) and for outbound connections from the Front End Server. The certicate is provided by the server in response to authentication challenges from clients or servers that send messages to this server. Each Edge Transport server must have a certicate for MTLS communication with other servers on the network, in particular Hub Transport servers. Inbound Anonymous TLS Certicates Inbound anonymous TLS certicates can authenticate SMTP sessions between Edge Transport servers and Hub Transport servers. They can also be used to encrypt SMTP sessions between Hub Transport servers. In the latter case, where anonymous TLS and the public keys from certicates are used to encrypt the session between Hub Transport servers, the Kerberos protocol is used for authentication. When an SMTP session is established, the receiving server initiates a certicate selection process to determine which certicate to use in the TLS negotiation. The sending server also performs a certicate selection process. 624 Chapter 12 Message Integrity, Antivirus, and Anti-Spam MORE INFO THE SELECTION PROCESS FOR INBOUND ANONYMOUS TLS CERTIFICATES The selection process for inbound anonymous TLS certicates occurs automatically without user intervention, and the details are beyond the scope of this lesson. For detailed information about this process, see http://technet.microsoft.com/en-us/library/bb430790.aspx. Inbound STARTTLS Certicates An inbound STARTTLS certicate is selected whenever SMTP hosts request TLS security when communicating with Edge Transport servers. The requesting host may be any SMTP host other than the Edge Transport server. Note that SMTP hosts other than Edge Transport servers requesting TLS security is a feature of the domain security scenario. Domain security is discussed later in this lesson. An inbound STARTTLS certicate is also used when SMTP clients, such as Microsoft Outlook Express, request TLS security when communicating with Hub Transport servers and when Internet-facing Hub Transport servers request TLS security with Edge Transport servers. When an SMTP session is established, the receiving server initiates a certicate selection process to determine which certicate to use in the TLS negotiation. MORE INFO SELECTING AN INBOUND STARTTLS CERTIFICATE The selection of an inbound STARTTLS certicate occurs without user intervention and is beyond the scope of this lesson. For more information, see http://technet.microsoft.com/ en-us/library/bb430748.aspx. NOTE OUTBOUND CERTIFICATES When the receiving server requests an inbound STARTTLS certicate, the sending server also performs a certicate selection process and selects an outbound anonymous TLS certicate. The selection of outbound anonymous TLS certicates is discussed next. Outbound Anonymous TLS Certicates An outbound anonymous TLS certicate is selected for authentication during an SMTP session between an Edge Transport server and a Hub Transport server. This type of certicate is also used to encrypt SMTP sessions between Hub Transport servers by using public keys. When an SMTP session is established, the receiving server initiates a certicate selection process to determine the outbound anonymous TLS certicate to use in the TLS negotiation. The receiving server also performs a certicate selection process, as described in the previous sections of this lesson. MORE INFO SELECTING AN OUTBOUND ANONYMOUS TLS CERTIFICATE The selection of an outbound anonymous TLS certicate occurs without user intervention and is beyond the scope of this lesson. For more information, see http://technet.microsoft .com/en-us/library/bb430773.aspx. Lesson 1: Ensuring Message Integrity Chapter 12 625 Implementing Domain Security Domain security provides a lower-cost alternative to S/MIME or other message-level security solutions. The domain security feature provides a method of managing secured message paths between business partners over the Internet. After secured message paths are congured, messages that have successfully traveled over these paths from authenticated senders are displayed to users as domain secured in the Outlook and OWA interfaces. Domain security uses MTLS authentication to provide session-based authentication and encryption. MTLS authentication differs from a typical TLS implementation. When TLS is implemented, the client veries that the connection securely connects to the intended server by validating the server’s certicate. The client authenticates the server before transmitting data. However, the server does not authenticate the session with the client. When MTLS authentication is used, each server veries the connection with the other server by validating a certicate provided by that other server—in other words, both the message sender and the message recipient are validated. Exchange Server 2010 provides a set of cmdlets that create, request, and manage TLS certicates. By default, TLS certicates are self-signed. That is, they are signed by their own creator. In Exchange Server 2010, self-signed certicates are created on the Exchange server by using the Microsoft Windows Cryptography Application Programming Interface. Self-signed certicates are considered less trustworthy than certicates generated by PKI or a trusted third-party CA and are typically used for internal mail only. However, you can use self-signed certicates to secure email messages from your organization to another Exchange Server 2010 organization if the receiving organization agrees to install your self-signed certicates in the trusted root certicate store in each of its inbound Edge Transport servers. In this case, the self-signed certicates are trusted explicitly. MORE INFO TRUSTED CERTIFICATES AND DOMAIN SECURITY For more information about trusted certicates and domain security, see http://technet .microsoft.com/en-us/library/bb124817.aspx. Conguring Domain Security To secure email messages that traverse the Internet, you would typically generate TLS certicates with a PKI or obtain them from a third-party CA. Suppose, for example, that you are an Exchange administrator at the Adatum Corporation and you want to congure Adatum’s Exchange Server 2010 organization to exchange domain-secured email with its partner organization, NorthWind Traders. You want to ensure that all email messages sent to and received from NorthWind Traders are protected with MTLS, and you want to congure domain security functionality so that all mail between the Adatum Corporation and NorthWind Traders is rejected if mutual TLS cannot be used. Adatum has an internal PKI that generates certicates. The PKI’s root certicate has been signed by a trusted third-party CA. NorthWind Traders uses the same third-party 626 Chapter 12 Message Integrity, Antivirus, and Anti-Spam CA to generate its certicates. Therefore, both organizations trust the other’s root CA. By default, the public third-party CA is one of the trusted root certicates in the Microsoft Windows certicate store in the adatum.com domain. Therefore, any client that includes the same third-party CA in its trusted root store and that connects to Adatum can authenticate to the certicate presented by Adatum. The Edge Transport server VAN-EX2.adatum.com requires a certicate. You therefore generate a base64-encoded PKCS#10 certicate request on that server by entering the following commands: $Data1 = New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate for VAN-EX2" -SubjectName "DC=com,DC=Adatum,CN=VAN-EX2.adatum.com" -DomainName mail .adatum.com Set-Content -Path "C:\Certificates\VAN-EX2-request.req" -Value $Data1 Figure 12-3 shows these commands. Note that the folder C:\Certicates must exist on VAN-EX2; otherwise, the second command returns an error. FIGURE 12-3 Generating a certificate request MORE INFO NEW-EXCHANGECERTIFICATE For more information about the New-ExchangeCerticate EMS cmdlet, see http://technet .microsoft.com/en-us/library/aa998327.aspx. MORE INFO GENERATING A CERTIFICATE REQUEST For more information about how to create a certicate request, see http://technet .microsoft.com/en-us/library/ee861120.aspx. Your next step is to import the certicate and enable it in the trusted certicate store on the Edge Transport server. Note that you should not use the Certicate Manager snap-in in the Microsoft Management Console (MMC) to import the certicates for TLS on an Exchange server because this does not bind the request created in this procedure to the issued certicate. You can use the Import-ExchangeCerticate EMS cmdlet to import an existing certicate and private key from a Personal Information Exchange Syntax Standard (PKCS) #12 (.pfx or .p12) le to the certicate store on the local Edge Transport server. PKCS #12 is a le format used to store certicates with corresponding private keys protected with a password. The following command imports and enables the certicate by piping the certicate into the Enable- ExchangeCerticate EMS cmdlet and starts the SMTP service on the Edge Transport server: Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\Certificates\ VAN-EX2-certificate.pfx -Encoding Byte -ReadCount 0)) | Enable-ExchangeCertificate -Services SMTP [...]... filter: Remove-ADPermission "MyReceiveConnector" -User "NT AUTHORITY\ANONYMOUS LOGON" -AccessRights ExtendedRight -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any -Recipient,ms-Exch-Bypass-Anti-Spam Figure 1 2 -8 shows the output from this command You need to confirm your action unless you set the Confirm parameter to false in the command by using the syntax –Confirm:$false FIGURE 1 2 -8   Removing... membership? A Add-ADPermission -Identity “Don Hall” -User “Kim Akers” -AccessRights E ­ xtendedRight -ExtendedRights “send as” B Add-ADPermission -Identity “Don Hall” -User “Kim Akers” –Deny -AccessRights ExtendedRight -ExtendedRights “send as” C Remove-ADPermission -Identity “Don Hall” -User “Kim Akers” -AccessRights E ­ xtendedRight -ExtendedRights “send as” D Remove-ADPermission -Identity “Don Hall” -User... ms-Exch-SMTP-Submit, ms-ExchSMTP-Accept-Any-Recipient, and ms-Exch-Bypass-Anti-Spam, by using the ­ xtendedRights E parameter For example, the following command configures the Receive connector MyReceiveConnector to accept anonymous SMTP messages and bypass the spam filter: Add-ADPermission "MyReceiveConnector" -User "NT AUTHORITY\ANONYMOUS LOGON" -AccessRights ExtendedRight -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,... MyReceiveConnector to ­ ccept anonymous SMTP messages and bypass the spam filter? a Quick Check Answer n Add-ADPermission “MyReceiveConnector” -User “NT AUTHORITY\ANONYMOUS LOGON” -AccessRights ExtendedRight -ExtendedRights ms-Exch-SMTP-Submit, ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-Bypass-Anti-Spam Rights Management Services Federation In Chapter 7, you looked at Active Directory Rights Management... the VAN-EX2-certificate.pfx file must exist in the path specified; otherwise, the command returns an error MORE INFO  IMPORT-EXCHANGECERTIFICATE AND ENABLE-EXCHANGECERTIFICATE For more information about the Import-ExchangeCertificate EMS cmdlet, see http:// technet .microsoft. com/en-us/library/bb124424.aspx For more information about the Enable-ExchangeCertificate EMS cmdlet, see http://technet .microsoft. com/en-us/library/... -DomainSecureEnabled:$true on DEN-Edge1 C Run the command Set-TransportConfig -TLSSendDomainSecureList contoso.com on DEN-Hub1 D Run the command Set-TransportConfig -TLSSendDomainSecureList contoso.com on DEN-Edge1 E Run the command Set-SendConnector Internet -ProtocolLoggingLevel Verbose on DEN-Hub1 F Run the command Set-SendConnector Internet -ProtocolLoggingLevel Verbose on DEN-Edge1 2 What protocol mandates the authentication... http://technet .microsoft. com/en-us/library/ bb124531.aspx You can use the following performance counters under the MSExchange Secure Mail Transport object in Exchange Server Performance Monitor to monitor domain security: n Domain-Secured Messages Received n Domain-Secured Messages Sent n Domain-Secured Outbound Session Failures Figure 1 2-6 shows these counters FIGURE 1 2-6   Counters associated with the MSExchange... filter: Add-ADPermission "MyReceiveConnector" -User "NT AUTHORITY\ANONYMOUS LOGON" -AccessRights ExtendedRight -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient, ms-Exch-Bypass-Anti-Spam Note that the Receive connector MyReceiveConnector must exist on the server on which the command runs; otherwise, the command returns an error Note also that you would not configure a Receive connector... SET-SENDCONNECTOR, AND GET-SENDCONNECTOR For more information about the Set-TransportConfig EMS cmdlet, see http://technet microsoft. com/en-us/library/bb124151.aspx For more information about the SetSendConnector EMS cmdlet, see http://technet .microsoft. com/en-us/library/aa9 982 94.aspx For more information about the Get-SendConnector EMS cmdlet, see http://technet microsoft. com/en-us/library/bb124553.aspx... Lesson 1: Ensuring Message Integrity Chapter 12 633 MORE INFO  REMOVE-ADPERMISSION AND GET-ADPERMISSION For more information about the Remove-ADPermission EMS cmdlet, see http://technet microsoft. com/en-us/library/aa9960 48. aspx For more information about the GetADPermission EMS cmdlet, see http://technet .microsoft. com/en-us/library/bb125 183 .aspx Quick Check n Which EMS command configures the Receive connector . Add-ADPermission “MyReceiveConnector” -User “NT AUTHORITYANONYMOUS LOGON” -AccessRights ExtendedRight -ExtendedRights ms-Exch-SMTP-Submit, ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-Bypass-Anti-Spam Rights. lter: Add-ADPermission "MyReceiveConnector" -User "NT AUTHORITYANONYMOUS LOGON" -AccessRights ExtendedRight -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,. Remove-ADPermission "MyReceiveConnector" -User "NT AUTHORITYANONYMOUS LOGON" -AccessRights ExtendedRight -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any -Recipient,ms-Exch-Bypass-Anti-Spam Figure