Unreadable

Testing Encryption and Signing

To check whether the encryption certificates were issued correctly and the appropriate Outlook settings are in place per Group Policy, start Microsoft Outlook 2016; in the settings, navigate to Trust Center | Trust Center Settings | Email Security , where you should see a certificate for the logged-on user account, as well as the settings for automatic signing and encryption of email.

Even if you can largely automate the distribution of certificates and the Outlook configuration, end-to end encryption in Outlook has several disadvantages:

• Complex certificate and key management
• No use of central rights management rules (rights management services)
• No central disclaimer configuration
• No central anti-spam and antivirus check

These and other arguments contradict end-to-end email encryption and have meant that most companies that require email encryption on a larger scale opt for centralized encryption gateways to eliminate almost all the disadvantages mentioned.

Using the Encrypting File System

The Encrypting File System (EFS) technology encrypts individual files or entire directories on a volume formatted with NTFS; it is available for almost all Windows operating systems (Figure 2). In contrast to full volume encryption (FVE) with Microsoft BitLocker, you can selectively encrypt data using EFS on the local device, as well as on a file server on the network. However, files encrypted with EFS are not encrypted for transferring across the network. EFS provides a multiuser function that lets users give others the right to access files encrypted with EFS.

Figure 2: Certificates encrypt files with EFS.

Users encrypt files and directories with EFS by selecting the desired data in Windows Explorer and then enabling encryption in the properties. The data is encrypted with the EFS certificate stored in a user's profile. If EFS does not find an enterprise CA in AD, the EFS process creates a self-signed certificate with a longer lifespan. This certificate is now used for encrypting and decrypting data.

Administrators can control the use of EFS in a corporate network with Group Policy. By default, all users can encrypt data using EFS. If no PKI is available and you cannot ensure that encrypted data can be restored with EFS, then when the user no longer has access to the EFS certificate, you should disable the use of EFS globally.

To recover files encrypted with EFS, an EFS recovery certificate is created in an AD environment. The recovery certificate is located by default on the first domain controller in the AD forest and used as the recovery agent for EFS-encrypted files. Only users who possess the EFS recovery agent certificate, can decrypt files. For this reason, you should protect the EFS recovery certificate with your private key, store it in a safe place, and renew it at regular intervals.

Before using EFS, you should plan well, document your steps, and provide functional recovery scenarios. A PKI makes the use of EFS more efficient and more secure, because EFS certificates are centrally issued by the CA, private key certificates can be archived, and administrators have an overview of the EFS certificates issued.

Certificates for Web Servers

IIS is still a commonly installed server role in the current server versions of Windows, because it is often used as an administrative front end by third-party applications or applications that use the IIS web services. Often IT managers then issue self-signed certificates during the installation of these applications to allow IIS to encrypt web server communication. Unfortunately, one still often sees unencrypted access to sensitive data and information or unencrypted system logins, because the manufacturer or administrator is apparently not aware of the extent to which this configuration is exposed to data misuse and hacker attacks.

With a Windows PKI, you can simply replace the self-signed certificates with CA certificates or encrypt the previously non-encrypted web server communication. When using a Windows CA, you can copy the "Web Server" certificate template type, configure your own settings in the template regarding key length and validity, and distribute certificates based on the template automatically using Group Policy. Therefore, you can extend your web server by adding HTTPS bindings or replace existing self-signed certificates with CA certificates.

Using the IIS Management Console, you also can request certificates manually from the certification authority and then bind them to the HTTPS protocol. If you also run IIS functions such as the central SSL certificate store, you can create an efficient solution for encrypting web server communication with HTTPS.