Enable support for TLS 1.2 in your environment for Azure AD TLS 1.1 and 1.0 deprecation

To improve the security posture of your tenant, and to remain in compliance with industry standards, Microsoft Azure Active Directory (Azure AD) will soon stop supporting the following Transport Layer Security (TLS) protocols and ciphers:

  • TLS 1.1
  • TLS 1.0
  • 3DES cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA)

How this change might affect your organization

Do your applications communicate with or authenticate against Azure Active Directory? Then those applications might not work as expected if they can't use TLS 1.2 to communicate. This situation includes:

  • Azure AD Connect
  • Azure AD PowerShell
  • Azure AD Application Proxy connectors
  • PTA agents
  • Legacy browsers
  • Applications that are integrated with Azure AD

Why this change is being made

These protocols and ciphers are being deprecated for the following reasons:

The services are being deprecated on the following dates:

  • TLS 1.0, 1.1 and 3DES Cipher suite in U.S. government instances starting on March 31, 2021.
  • TLS 1.0, 1.1 and 3DES Cipher suite in public instances starting January 31, 2022. (This date has been postponed from June 30th, 2021 to January 31st, 2022, to give administrators more time to remove the dependency on legacy TLS protocols and ciphers (TLS 1.0,1.1 and 3DES).)

Enable support for TLS 1.2 in your environment

How do you maintain a secure connection to Azure Active Directory (Azure AD) and Microsoft 365 services? You enable your client apps and client and server operating system (OS) for TLS 1.2 and modern cipher suites.

Guidelines for enabling TLS 1.2 on clients

  • Update Windows and the default TLS that you use for "WinHTTP".
  • Identify and reduce you dependency on the client apps and operating systems that don't support TLS 1.2.
  • Enable TLS 1.2 for applications and services that communicate with Azure AD.
  • Update and configure your .NET Framework installation to support TLS 1.2.
  • Make sure that applications and PowerShell (that use Microsoft Graph) and Azure AD PowerShell scripts are hosted and run on a platform that supports TLS 1.2.
  • Make sure that your web browser has the latest updates. We recommend that you use the new Microsoft Edge browser (based on Chromium). For more information, see the Microsoft Edge release notes for Stable Channel.
  • Make sure that your web proxy supports TLS 1.2. For more information about how to update a web proxy, check with the vendor of your web proxy solution.

For more information, see the following articles:

Update the Windows OS and the default TLS that you use for WinHTTP

These operating systems natively support TLS 1.2 for client-server communications over WinHTTP:

  • Windows 10
  • Windows 8.1
  • Windows Server 2016
  • Windows Server 2012 R2
  • Later versions of Windows and Windows Server

Verify that you haven't explicitly disabled TLS 1.2 on these platforms.

By default, earlier versions of Windows (such as Windows 8 and Windows Server 2012) don't enable TLS 1.2 or TLS 1.1 for secure communications by using WinHTTP. For these earlier versions of Windows:

  1. Install Update 3140245.
  2. Enable the registry values from the Enable TLS 1.2 on client or server operating systems section.

You can configure those values to add TLS 1.2 and TLS 1.1 to the default secure protocols list for WinHTTP.

For more information, see How to enable TLS 1.2 on clients.

Note

By default, an OS that supports TLS 1.2 (for example, Windows 10) also supports legacy versions of the TLS protocol. When a connection is made by using TLS 1.2 and it doesn’t get a timely response, or when the connection is reset, the OS might try to connect to the target web service by using an older TLS protocol (such as TLS 1.0 or 1.1). This usually occurs if the network is busy, or if a packet drops in the network. After the temporary fallback to the legacy TLS, the OS will try again to make a TLS 1.2 connection.

What will be the status of such fallback traffic after Microsoft stops supporting the legacy TLS? The OS might still try to make a TLS connection by using the legacy TLS protocol. But if the Microsoft service is no longer supporting the older TLS protocol, the legacy TLS-based connection won’t succeed. This will force the OS to try the connection again by using TLS 1.2 instead.

Identify and reduce dependency on clients that don't support TLS 1.2

Update the following clients to provide uninterrupted access:

  • Android version 4.3 and earlier versions
  • Firefox version 5.0 and earlier versions
  • Internet Explorer versions 8-10 on Windows 7 and earlier versions
  • Internet Explorer 10 on Windows Phone 8.0
  • Safari 6.0.4 on OS X 10.8.4 and earlier versions

For more information, see Handshake Simulation for various clients connecting to www.microsoft.com, courtesy SSLLabs.com.

Enable TLS 1.2 on common server roles that communicate with Azure AD

Enable TLS 1.2 on client or server operating systems

Registry strings

To manually configure and enable TLS 1.2 at the operating system level, you can add the following DWORD values.

For Windows 2012 R2, Windows 8.1, and later OS, TLS 1.2 is enabled by default. Thus, the following registry values aren't required unless they were set with different values.

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
    • "DisabledByDefault": 00000000
    • "Enabled": 00000001
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server
    • "DisabledByDefault": 00000000
    • "Enabled": 00000001
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
    • "SchUseStrongCrypto": 00000001

To enable TLS 1.2 by using a PowerShell script, see TLS 1.2 enforcement for Azure AD Connect.

Update and configure .NET Framework to support TLS 1.2

Managed Azure AD-integrated applications and Windows PowerShell scripts (using Azure AD PowerShell V1 (Microsoft MSOnline), V2 (AzureAD), Microsoft Graph) may use .NET Framework.

Install .NET updates to enable strong cryptography

Determine the .NET version

First, determine the installed .NET versions.

Install .NET updates

Install the .NET updates so that you can enable strong cryptography. Some versions of .NET Framework might have to be updated to enable strong cryptography.

Use these guidelines:

For any computer that communicates across the network and runs a TLS 1.2-enabled system, set the following registry DWORD values.

  • For 32-bit applications that are running on a 32-bit OS and 64-bit applications that are running on a 64-bit OS, update the following subkey values:

    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727

      • "SystemDefaultTlsVersions": 00000001
      • "SchUseStrongCrypto": 00000001
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319

      • "SystemDefaultTlsVersions": 00000001
      • "SchUseStrongCrypto": 00000001
  • For 32-bit applications that are running on 64-bit OSs, update the following subkey values:

    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727
      • "SystemDefaultTlsVersions": dword:00000001
      • "SchUseStrongCrypto": dword:00000001
    • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319
      • "SystemDefaultTlsVersions": dword:00000001
      • "SchUseStrongCrypto": dword:00000001

For example, set these values on:

  • Configuration Manager clients
  • Remote site system roles that aren't installed on the site server
  • The site server itself

For more information, see the following articles:

Overview of new telemetry in the sign-in logs

To help you identify any clients or apps that still use legacy TLS in your environment, view the Azure AD sign-in logs. For clients or apps that sign in over legacy TLS, Azure AD marks the Legacy TLS field in Additional Details with True. The Legacy TLS field only appears if the sign-in occurred over legacy TLS. If you don’t see any legacy TLS in your logs, you're ready to switch to TLS 1.2.

To find the sign-in attempts that used legacy TLS protocols, an administrator can review the logs by:

  • Exporting and querying the logs in Azure Monitor.
  • Downloading the last seven days of logs in JavaScript Object Notation (JSON) format.
  • Filtering and exporting sign-in logs using PowerShell.

These methods are described below.

You can query the sign-in logs using Azure Monitor. Azure Monitor is a powerful log analysis, monitoring, and alerting tool. Use Azure Monitor for:

  • Azure AD logs
  • Azure resources logs
  • Logs from independent software tools

Note

You need an Azure AD Premium license to export reporting data to Azure Monitor.

To query for legacy TLS entries using Azure Monitor:

  1. In Integrate Azure AD logs with Azure Monitor logs, follow the instructions for how to access the Azure AD sign-in logs in Azure Monitor.

  2. In the query definition area, paste the following Kusto Query Language query:

    // Interactive sign-ins only
    SigninLogs
    | where AuthenticationProcessingDetails has "Legacy TLS"
        and AuthenticationProcessingDetails has "True"
    | extend JsonAuthProcDetails = parse_json(AuthenticationProcessingDetails)
    | mv-apply JsonAuthProcDetails on (
        where JsonAuthProcDetails.key startswith "Legacy TLS"
        | project HasLegacyTls=JsonAuthProcDetails.value
    )
    | where HasLegacyTls == true
    
    // Non-interactive sign-ins
    AADNonInteractiveUserSignInLogs
    | where AuthenticationProcessingDetails has "Legacy TLS"
        and AuthenticationProcessingDetails has "True"
    | extend JsonAuthProcDetails = parse_json(AuthenticationProcessingDetails)
    | mv-apply JsonAuthProcDetails on (
        where JsonAuthProcDetails.key startswith "Legacy TLS"
        | project HasLegacyTls=JsonAuthProcDetails.value
    )
    | where HasLegacyTls == true
    
    // Workload Identity (service principal) sign-ins
    AADServicePrincipalSignInLogs
    | where AuthenticationProcessingDetails has "Legacy TLS"
        and AuthenticationProcessingDetails has "True"
    | extend JsonAuthProcDetails = parse_json(AuthenticationProcessingDetails)
    | mv-apply JsonAuthProcDetails on (
        where JsonAuthProcDetails.key startswith "Legacy TLS"
        | project HasLegacyTls=JsonAuthProcDetails.value
    )
    | where HasLegacyTls == true
    
  3. Select Run to execute the query. The log entries that match the query appear in the Results tab below the query definition.

  4. To learn more about the source of the legacy TLS request, look for the following fields:

    • UserDisplayName
    • AppDisplayName
    • ResourceDisplayName
    • UserAgent

View details about log entries in the Azure AD portal

After you obtain the logs, you can get more details about legacy TLS-based sign-in log entries in the Azure AD portal. Follow these steps:

  1. In the Azure portal, search for and select Azure Active Directory.

  2. In the Overview page menu, select Sign-in logs.

  3. Select a sign-in log entry for a user.

  4. Select the Additional details tab. (If you don't see this tab, first select the ellipsis (...) in the right corner to view the full list of tabs.)

  5. Check for a Legacy TLS (TLS 1.0, 1.1, or 3DES) value that's set to True. If you see that particular field and value, the sign-in attempt was made using legacy TLS. If the sign-in attempt was made using TLS 1.2, that field doesn't appear.

For more information, see Sign-in logs in Azure Active Directory.

Contact us for help

If you have questions or need help, create a support request, or ask Azure community support. You can also submit product feedback to Azure community support.