Secure Email Communication with Microsoft Exchange Server . Microsoft Exchange Server 2019 supports multiple ways to secure email communication. Most of them are enabled by default and don’t require any configuration from the IT personnel. For example, all the internal communications between email clients and Exchange Servers, between servers and between services within the server are encrypted by default. However, there are still areas of improvements, that require the manual configuration to benefit from. The ones that improve email communications the most significantly are:
- Digital Signatures
- Message Encryption
- Domain Security (Mutual Transport Layer Security)
Let’s review each of them in details.
Using Digital Signatures to Ensure Data Integrity
Digital signatures are used to sign email messages using the digital certificate. They serve for the same purpose as signatures on paper docs. In Exchange Server 2019, digital signatures are utilized by deploying Secure/Multipurpose Internet Mail Extensions (S/MIME), and provide the following security features.
- Authentication. SMTP protocol, used for email communication, lacks many security features, including the authentication. It makes it impossible to determine the true sender of a message, allowing malicious actors to impersonate the senders. Digital signatures address this issue by allowing recipients to verify that a message indeed comes from the claimed sender. Provides a means to establish trust (using the digital certificate) in the authenticity of the communication.
- Non repudiation. Non repudiation ensures that an individual cannot disclaim the performed action (in the email messaging context, the action is the sending of the message). It significantly complicates any attempt to refuse the authenticity of a message. Makes it highly challenging to deny responsibility. As a result, digitally signed messages are considered more trustworthy than non-signed ones.
- Data Integrity. Digital signatures also enhance security by ensuring data integrity. For example, you send a signed message to your colleague. It gets altered during the SMTP flow by a hacker. In this case the message loses the signature. Presence of a digital signature on a message proves that the email message is in the same state as it was intended by the sender.
Digital signature proves the message comes from the specified sender and that it wasn’t altered during the transport. S/MIME uses the asymmetric cryptography (public-private key pair) to sign the messages.
As shown on the above image, digital signature with S/MIME works the following way:
- The private key (only available for the sender) is used to sign the message.
- The signed message is sent to the recipient.
- Recipient uses the public key (available for everyone) to verify the signature.
To use S/MIME in your Exchange Server infrastructure, you need have the necessary public key infrastructure – to issue the necessary key pairs. It is recommended (but not necessary) to use Active Directory Certificate Services. More details are here Server Certificate Deployment Overview.
After issuing the certificate, install the private key to the local device of the user, and make the public key available for the recipients by publishing it to the Exchange Global Address List (GAL). Do it either by filling the UserSMIMECertificate Active Directory attribute in the user account or by manually publishing using Outlook (as described here).
Ensuring Confidentiality Using Message Encryption
Although digital signature gives us some security capabilities, it doesn’t ensure confidentiality. For this purpose, message encryption is usually used. For Exchange Server, there are 2 options – S/MIME and Information Rights Management (IRM).
Encryption using S/MIME
S/MIME Encryption
- Sender uses the recipient’s public key to encrypt the message.
- Encrypted message is sent to the recipient.
- Recipient uses their private key to decrypt the message.
As recipient is the only one who has access to the private key, only they are able to decrypt the message and read it. The implementation of the solution is the same as for digital signature – a key pair must be issued for the user and published to the GAL. In case the user wants to receive an encrypted message from the external sender (which doesn’t have access to GAL), they should manually provide the public key for this sender first. In case the user wants to achieve both message authentication and data confidentiality – both signature and encryption should be used.
- When applying both signature and encryption, the sender’s private key is used to sign the message first.
- The recipient’s public key is used to encrypt the message.
- Signed and encrypted message is sent to the recipient.
- Recipient uses their private key to decrypt the message.
- Recipient uses sender’s public key to verify the signature.
Though S/MIME provides good security features and is considered de-facto standard approach for message encryption, it has some disadvantages. The main disadvantage is that it prevents the inspection of the messages. For example, if you implement some data-loss prevention tool, it won’t be able to check the messages encrypted using S/MIME. Additionally, it is not possible to control message confidentiality after it was decrypt. The recipient forwards (intentionally or by mistake) the message to someone, copies its content or print it. Therefore, in some cases S/MIME is not an acceptable solution. As an alternative encryption solution, IRM is to be considered.
Try our Active Directory & Office 365 Reporting & Auditing Tools
Try us out for Free. 100’s of report templates available. Easily customise your own reports on AD, Azure AD & Office 355.
Utilizing Information Rights Management in Exchange Server
Besides providing the message confidentiality, IRM also brings additional benefits:
- Data leak prevention. IRM prevents the recipient from forwarding the message, modifying it, saving on the local drive, printing and copying the content. Protects not only the body of the message, but also attached files created using Office applications, such as Word, Excel and PowerPoint.
- Temporary access provision. IRM is used to provide someone temporary access to the data. For example, send a message with confidential information to the auditor and set the access expiration so the recipient will not have access to the message after audit is completed.
- Enforced protection policies. Unlike S/MIME, which allows user to decide whether encrypt the message or not, IRM is used to enforce the encryption. Useful for mandatory encryption, for example, if you are working with government agency and the encryption of communication is legally required.
IRM requires deployment of Active Directory Rights Management Services (AD RMS) or Azure RMS. In case of AD RMS, you need to deploy the whole RMS infrastructure on-premises, as it is described here. For Azure RMS, you need an Azure Subscription, Azure Information Protection licenses and the deployment of on-premises RMS Connector, as described here.
RMS Encryption
- When the sender applies the restrictions, RMS client installed on their computer creates a service request to the RMS server.
- The server provides a Client Licensor Certificate which is used to encrypt the email message.
- The encrypted message is sent to the recipient.
- When the recipient opens an email, RMS client installed on the recipient’s computer connects to the RMS server to get a user license.
- RMS server checks the permissions, and if the recipient has the right to view message, it decrypts the message and applies the configured restrictions.
As seen, IRM is more advanced encryption solution than S/MIME. But it requires more investments and more administrative efforts. It needs additional servers (or subscriptions in case of Azure RMS), deployment of clients and network configuration that allows access to RMS server by all communication participants. The full comparison of S/MIME and IRM features is here Email encryption.
Implementation of Domain-level Security in Exchange Server
Digital signature and message encryption help to secure email communication on the message level. In some scenarios, you may need to configure encryption on the cross-domain transport level. For this purpose, Exchange Server has a Domain Security feature, which is based on mutual Transport Layer Security (TLS) authentication. This technology allows to confirm the identity of the servers that participate in the communication and create a trusted channel between two organizations. It only works if Exchange Server is an endpoint of email communication (for example, if you use Edge Transport servers in DMZ), in case you use some third-party email gateways or smart hosts, different approach for mutual authorization should be applied.
TLS Authentication
As shown on the above image, mutual TLS works the following way:
- Servers in both organizations have installed TLS certificates issued by certification authority (CA) trusted by the partner organization. It is either enterprise CA, or a third-party (as shown on the image) CA.
- When there is a need to establish a connection, the sending server initiates the session and sends its certificate.
- The receiving server validates the certificate.
- The receiving server sends its certificate.
- The sending server validates the certificate.
- The secure connection is established.
Both sides validate the partner’s certificate, that’s why the technology is called mutual TLS. The domain security requires configuration from both sides. It is not possible to have mutual TLS connection with everyone, it is usually configured for the partner organizations. The list of the domains you want to have secure connections with is specified in the Exchange Server transport configuration, using the TLSSendDomainSecureList and TLSReceiveDomainSecureList parameters of the Set-TransportConfig PowerShell cmdlet. The full list of configuration steps is here Using Domain Security: Configuring Mutual TLS ( the article was written for Exchange Server 2010, however, the information is applicable for the current edition of Exchange as well).
Did you enjoy this article? We hope how to Secure Email Communication with Microsoft Exchange Server, assisted you in your knowledge hub. Let’s conclude
Secure Email Communication with Microsoft Exchange Server Conclusion
In conclusion, though Microsoft Exchange Server includes some features to secure email communications out of the box, it may require some additional investments and configuration to improve the security level. Deploy S/MIME, IRM and mutual TLS to ensure that no man-in-the-middle attack are performed against your email messaging infrastructure. In this article, only built-in features were described, however, there are a lot of third-party tools are available in the market, which have different sets of features and different costs. If the included features don’t work for your organizations, you have plenty alternative options.
Try InfraSOS for FREE
Try InfraSOS Active Directory, Azure AD & Office 365 Reporting & Auditing Tool
- Free 15-Days Trial
- SaaS AD Reporting & Auditing Solution
