Exchange 2013 / 2016 Enabling TLS 1.2

Exchange

I have recently been working with a customer to upgrade to Exchange Server 2016, one of the requirements is to enable TLS 1.2. The following will guide you through the preparation, implementation and then testing.

For the testing I have used ZenMap/NMAP: –  https://nmap.org/download.html

Preparation

Exchange Server 2016

  • Install Cumulative Update (CU) 8 in production for TLS 1.2 support and be ready to upgrade to CU9 after its release if you need to disable TLS 1.0 and TLS 1.1. –CU 10 is now available.
  • Install the newest version of .NET and associated patches supported by your CU (currently 4.7.2).

Exchange Server 2013

  • Install CU19 in production for TLS 1.2 support and be ready to upgrade to CU20 after its release if you need to disable TLS 1.0 and TLS 1.1.
  • Install the newest version of .NET and associated patches supported by your CU (currently 4.7.2).

Windows Server 2016

  • TLS 1.2 is the default security protocol for Schannel and consumable by WinHTTP.
  • Ensure you have installed the most recent Monthly Quality Update along with any other offered Windows updates.

Windows Server 2012 R2

  • TLS 1.2 is the default security protocol for Schannel and consumable by WinHTTP
  • Ensure your server is current on Windows Updates.
    • This should include security update KB3161949 for the current version of WinHTTP.
  • If you rely on SHA512 certificates; please see KB2973337.

Windows Server 2012

  • TLS 1.2 is the default security protocol for Schannel.
  • Ensure your server is current on Windows Updates.
    • This should include security update KB3161949 for the current version of WinHTTP.
  • If you rely on SHA512 certificates; please see KB2973337.

Implementation

Enable TLS 1.2 for Schannel

To enable TLS 1.2 for both server (inbound) and client (outbound) connections on an Exchange Server please perform the following.

  1. From Notepad.exe, create a text file named TLS12-Enable.reg.
  2. Copy and paste the following text into the file.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\
Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\
Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\
Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
  1. Save TLS12-Enable.reg.
  2. Double-click the TLS12-Enable.reg file.
  3. Click Yes to update your Windows Registry with these changes.
  4. Restart the machine for the changes to take effect.

Enable TLS 1.2 for .NET 4.x

This step is only required for Exchange Server 2013 or later installations where .NET 4.x is relied upon.

The SystemDefaultTlsVersions registry value defines which security protocol version defaults will be used by .NET Framework 4.x. If the value is set to 1, then .NET Framework 4.x will inherit its defaults from the Windows Schannel DisabledByDefault registry values. If the value is undefined, it will behave as if the value is set to 0. By configuring .NET Framework 4.x to inherit its values from Schannel we gain the ability to use the latest versions of TLS supported by the OS, including TLS 1.2.

  1. From Notepad.exe, create a text file named NET4X-UseSchannelDefaults.reg.
  2. Copy, and then paste the following text.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
  1. Save the NET4X-UseSchannelDefaults.reg file.
  2. Double-click the NET4X-UseSchannelDefaults.reg file.
  3. Click Yes to update your Windows Registry with these changes.
  4. Restart your computer for the change to take effect.

Note: When configuring a system for TLS 1.2, you can make the Schannel and .NET registry keys at the same time and reboot the server once.

Testing

Testing before TLS has been enabled (the default state of an Exchange 2016 Deployment) using ZenMap

NO TLS enabled

Testing after TLS has been enabled (after following the above procedures) using ZenMap

TLS Enabled

Message Headers (Exchange Server 2016 Only)

Message header data in Exchange Server 2016 provides the protocol negotiated and used when the sending and receiving host exchanged a piece of mail. While this is a more manual method of checking how mail arrived it can be used for testing between specific systems in a pinch.

Example when viewing message header data via Message Header Analyzer at https://testconnectivity.microsoft.com

TLSP2_1

Mail Flow via SMTP Logging

SMTP Logs in Exchange 2016 will contain the encryption protocol and other encryption related information used during the exchange of email between two systems.

When the server is the SMTP receiving system, the following strings exist in the log depending on the version of TLS used.

  • TLS protocol SP_PROT_TLS1_0_SERVER
  • TLS protocol SP_PROT_TLS1_1_SERVER
  • TLS protocol SP_PROT_TLS1_2_SERVER

When the server is the SMTP sending system, the following strings exist in the log depending on the version of TLS used.

  • TLS protocol SP_PROT-TLS1_0_CLIENT
  • TLS protocol SP_PROT-TLS1_1_CLIENT
  • TLS protocol SP_PROT-TLS1_2_CLIENT

 

Advertisements

Office 365 Hybrid – Federation Configuration Issues

Recently I have been faced with an issue for one of our customers running MS Windows Small Business Server 2011 – Exchange 2010 SP3.

When running the Hybrid Configuration wizard I got an error stating:
Unable to access the Federation Metadata document from the federation partner. Detailed information: “The remote server returned an error: (407) Proxy Authentication Required.”

This happened on the initial phase of the Hybrid config wizard which actually is an attempt to create a federation trust with the MS Federation Gateway.

I checked the IE settings and removed the proxy settings and tried again. Same thing. Not surprising really – Exchange uses the system account which would ignore IE settings. I turned to ‘netsh’ to see what settings the system account would use.

Run from a command prompt: netsh winhttp show proxy

This came back as ‘DIRECT’.
For good measure, I ran ‘netsh winhttp reset proxy
No difference.

The customer did have a proxy – I could have just configured the system to use the proxy with another netsh command (‘netsh winhttp import proxy source=ie’), however Exchange won’t allow this if your proxy requires authentication which was the case. Why was I being forced through the proxy?

I checked one last place using the Exchange Management Shell:

Get-ExchangeServer ‘SERVER’ |ft InternetWebProxy

This came back blank. There was surely no other place where a proxy could be specified?

Not quite – apparently the SYSTEM account will always attempt to use WPAD (Windows Proxy Auto Discovery). Surely nobody uses this anymore? WRONG! This particular customer so happened to have it configured.

Easy way to get rid of it? Simply disable the service (by default it sits in a manual startup mode).

After disabling WPAD, I restarted the IIS service (the w3wp process is responsible for performing the Hybrid Configuration wizard task) but this didn’t quite fix it. It looks like the proxy settings get cached – after a server reboot the problem was resolved.

I did also contact MS support to resolve this, but they drew a dead end.. they asked me to reapply service packs, check to make sure my internet connection was not filtered and there were no firewall rules blocking access.. this will be going down in my notes as one to remember.

Exchange Distribution Group Members

A task that I am often required to do is to provide information about who is a member of what distribution group in Exchange.

Below is a PowerShell snippet that you must run in the Exchange Management Shell to pull out all the required Distributions groups and the members:

foreach ($group in Get-DistributionGroup) { get-distributiongroupmember $group | ft @{expression={$_.displayname};Label=”$group”} | Out-File c:\temp\DistributionListMembers.txt -append}

 

The output looks something like this:
Info
—-
User1
User2
User3

Technicians
———–
Technician1