HOWTO: Enforce Azure AD Connect to use TLS 1.2 only

Hybrid Identity

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

Note:
This blogpost assumes Azure AD Connect runs on a Windows Server 2016 with Desktop Experience (“Full installation”) installation.

 

Why harden

Hardening provides additional layers to defense in depth approaches. It changes the default behavior of products and services to make them more resilient to unauthorized changes and compromise.

Reasons why

Secure connections over the Internet are commonly encrypted. The protocol, cipher suite and hashing algorithm are negotiated to make sure both ends of the communications channel can understand what’s being interchanged encrypted. In most cases, this would result in the strongest protocol, cipher suite and hashing algorithm being used.

However, for communications containing personally identifiable information (PII data) or information on data subjects, more guarantees are needed. A common mitigating measure in terms of a GDPR-enforced data privacy impact analysis (DPIA), would be to force the component responsible for interchanging this data to use the strongest protocol, cipher suite and hashing algorithm.

This is exactly what the topic is for today: Making sure Azure AD Connect interchanges information on the TLS 1.2 protocol only.

Possible negative impact (What could go wrong?)

When an Azure AD Connect installation is hardened improperly, it may stop synchronizing objects from Active Directory to Azure Active Directory. Synchronization cycle occur every 30 minutes, by default. So you may not get events indicating something is wrong in Event Viewer right away.

When synchronization stops or is partial, the most apparent problem is that colleagues will start experiencing lack of functionality; When they get married, their name change is not reflected everywhere. When they get added to a group, they don’t gain access to cloud applications. When they change or reset their password, it’s not reflected, or they receive a “Something went wrong” error, etc.

However, things get tricky when people are laid off on the spot. In these situations, it’s important that the user account is disabled, stripped from permissions and/or removed throughout all systems as soon as possible.

 

Getting Ready

To enforce Azure AD Connect to use TLS 1.2 only, make sure to meet the following requirements:

System requirements

Make sure the Windows Server installations are installed with the latest cumulative Windows Updates. Also make sure you run the latest stable version of Azure AD Connect.

Privilege requirements

Make sure you are signed in with an account that has local administrative privileges on the Windows Server(s) running Azure AD Connect.

Who to communicate to

When intending to make changes to Azure AD Connect installations, make sure to send a heads-up to these people and/or teams in your organization:

  • Load balancers and networking guys and gals
  • The Active Directory team
  • The people responsible for backups, restores and disaster recovery
  • The people going through the logs, using a SIEM and/or a TSCM solution
  • The monitoring team

One of the challenges you can easily avoid through communications is that multiple persons and/or teams make changes to the configuration. When it breaks, you don’t want to roll-back a bunch of changes, just the one that broke it. Make sure you have the proper freeze/unfreeze moments to achieve that.

 

How to enforce Azure AD Connect to use TLS 1.2 only

To enforce Azure AD Connect to use TLS 1.2 only, run the following Windows PowerShell script in an elevated PowerShell window on each of the Windows Server installations running Azure AD Connect:

Note:
RFC 8446 defines the Transport Layer Security (TLS) Protocol Version 1.3. However, TLS 1.3 has not found its way to Windows Server, yet. It is unavailable at the time of writing.

 

$RegPath1 = “HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath1 `
-name
SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath1 `
-name
SchUseStrongCrypto -value 1 -PropertyType DWORD

 

$RegPath2 = “HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath2 `
-name SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath2 `
-name SchUseStrongCrypto -value 1 -PropertyType DWORD

 

Testing proper hardening

After hardening it’s time to test the hardening. Everyone should sign off (not literally, unless that’s procedure) on the correct working of the Windows Servers running Azure AD Connect.

Note:
The registry changes are step 1 of two steps to harden protocols, cipher suites and hashing algorithms of the Hybrid Identity implementation. Make sure to disable weak protocols, cipher suites and hashing algorithms on the Windows Servers running Azure AD Connect, before testing these systems.

Does authentication to cloud applications still work? Does rolling over the certificate still work? Does monitoring still work? Can we still make back-ups? Can we still restore the backups we make?

Typically, hardening is rolled out to one Windows Server running Azure AD Connect. In an environment with a Staging Mode Azure AD Connect installation, the hardening can be performed on this Windows Server installation and tested with the normal Staging Mode (imports only) synchronization cycles. When hardening is approved upon, the actively synchronizing Azure AD Connect installation can be switched, or hardened, too.

Rolling back hardening

To roll back the settings that enforce Azure AD Connect to use TLS 1.2 only, use the following lines of Windows PowerShell:

$RegPath1 = “HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath1 `
-name SystemDefaultTlsVersions -value 0 -PropertyType DWORD

New-ItemProperty -path $RegPath1 `
-name SchUseStrongCrypto -value 0 -PropertyType DWORD

 

$RegPath2 = “HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath2 `
-name SystemDefaultTlsVersions -value 0 -PropertyType DWORD

New-ItemProperty -path $RegPath2 `
-name SchUseStrongCrypto -value 0 -PropertyType DWORD

 

Concluding

Enforcing Azure AD Connect to use TLS v1.2 is a perfect mitigating measure in terms of a GDPR-enforced data privacy impact analysis (DPIA). Be sure to implement it, and enable TLS 1.2 on the Windows Server installations running Azure AD Connect, too.

Further reading

TLS 1.2 enforcement for Azure AD Connect
Azure AD Connect moves to TLS 1.2-only with version 1.2.65.0
What’s New in Azure Active Directory for May 2019

Series Navigation

<< HOWTO: Disable Unnecessary Services and Scheduled Tasks on Windows Servers running Azure AD ConnectHOWTO: Disable weak protocols, cipher suites and hashing algorithms on Web Application Proxies, AD FS Servers and Windows Servers running Azure AD Connect >>

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.