Windows security with public key infrastructures

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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Changes in Exchange Server 2013
    Exchange Server 2013 sees Microsoft complete the latest version of its groupware solution. In this article, we introduce new features in the server and reveal which features have been eliminated.
  • Shell in a Browser

    PHP Shell and Shell In A Box put a shell in your browser, thus facilitating web server management – even from the nearest Internet café and without SSH access.

  • Attacks on HTTPS Connections
    HTTPS protects a connection from both tapping and manipulation, but only if a man in the middle hasn't already infiltrated the Internet connection. We highlight the weaknesses in HTTPS and demonstrate how to protect your client and server.
  • Setting up SSL connections on Apache 2
    To spoil the day for lurking data thieves, Apache administrators only need three additional directives – and a handful of commands.
  • Certificate security
    Use public key pinning to map certificates to specific domains.
comments powered by Disqus