Microsoft is deprecating support for TLS 1.0 and TLS 1.1 and enforcing TLS 1.2 to enhance the security of its products and services including Azure AD Sync service. TLS stands for Transport Layer Security and is a cryptographic protocol used to secure communication over the internet.
Microsoft has announced that it will no longer support TLS 1.0 and TLS 1.1 in its products and services starting from March 2020. This includes all Microsoft products such as Windows, Office 365, Exchange Server, and Azure, Azure AD and Azure AD Connect.
Earlier I wrote an article on using GPO to enforce TLS 1.2 on Windows Servers and what testing should be done to ensure business continuity. Microsoft has made TLS 1.2 the default protocol for secure communication in Azure AD Connect. This means that Azure AD Connect uses TLS 1.2 by default when communicating with Azure AD and on-premises directories. Microsoft has enforced TLS 1.2 as the default protocol for secure communication in Azure AD Connect version 1.1.819.0 and later versions. If you are running an older version of Azure AD Connect, it may not support TLS 1.2 by default.
Azure AD connect version history can be found here: https://learn.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history
I you are enforcing TLS 1.2 on a Windows Server running Azure AD connect of a version later than 1.1.819.0 everything works fine.. until you turn on password write-back or if you already had it turned on, it may be broken and users are getting an error when attempting to change their password:
We could not change your password
We’re sorry, but we cannot change your password at this time. This is due to a temporary connectivity issue, so if you try again later, changing your password may succeed.
In Azure AD Audit logs you will see the following:
Activity
Date
4/22/2023, 9:31 PM
Activity Type
Change password (self-service)
Category
UserManagement
Status
failure
Status reason
OnPremisesConnectivityFailure
Additional Details
ErrorMessage
Failed to connect to onpremises service
The Azure AD Sync server will have the following errors in Application Event Log:
Log Name: Application
Source: PasswordResetService
Event ID: 31031
Task Category: None
Level: Warning
User: N/A
Computer: ADSYNC.domain.com
Description:
TrackingId: 95a0e3ba ServiceHost for Namespace: ssprdedicatedsbprodscu, Endpoint: b8e08bce-is not running, Details: Version: 5.0.922.0
And the following:
Log Name: Application
Source: PasswordResetService
Event ID: 31034
Task Category: None
Level: Error
User: N/A
Computer: ADSYNC.domain.com
Description:
TrackingId: 95a0e3ba- System.ServiceModel.CommunicationException: The client and server cannot communicate, because they do not possess a common algorithm —> System.IO.IOException: The client and server cannot communicate, because they do not possess a common algorithm —>
What will throw you off is that AD Sync will work fine. There will be no errors syncing, but password change will not work.
Why and how to fix this issue?
Azure AD Sync (formerly known as Azure AD Connect Sync) does use a local SQL database to store information about the synchronization process and the objects being synchronized.
The local SQL database is used by Azure AD Sync to store information such as the connector configuration, sync rules, and the state of objects being synchronized. The database is also used to store metadata about the objects, such as their source attribute values and their transformation rules.
When a user changes their password in Azure AD, the new password is synchronized to the on-premises Active Directory domain controller by Azure AD Connect. If Password Writeback is enabled, the new password is also written back to the Azure AD Connect database, which is a local SQL database.
The local SQL database used by Azure AD Connect stores information about the synchronization process and the objects being synchronized, including user objects and their associated password hashes. When a password is written back to the database, the password hash associated with the user object in the database is updated to reflect the new password.
This means that if a user changes their password in Azure AD and Password Writeback is enabled, the local SQL database used by Azure AD Connect will be updated with the new password hash, ensuring that the user’s password is synchronized across all systems and services that use the on-premises Active Directory domain controller for authentication.
When writeback communication is received by Azure AD Sync, it updates the local SQL database with the modified information, and the synchronization process uses this information to update the on-premises Active Directory domain controller.
When communicating with a SQL Server database over a network, the .NET Framework uses the SQL Server Native Client provider, which supports the use of Transport Layer Security (TLS) to encrypt data in transit. The use of TLS helps to ensure that data exchanged between the client and the SQL Server database is protected against eavesdropping and tampering.
Starting with .NET Framework 4.5, TLS 1.2 is supported by default, but in .NET Framework 4.0, support for TLS 1.2 is available through a security update (KB 3154518) released by Microsoft. This update enables support for TLS 1.2 for .NET Framework 4.0 and higher, allowing applications to use TLS 1.2 for secure communication with SQL Server databases.
Therefore, if you are using .NET Framework 4.0, it is important to ensure that the security update (KB 3154518) is installed to enable TLS 1.2 support for secure communication with SQL Server databases.
But why Azure AD Sync still works and password write-back is broken after TLS 1.2 enforcement?
To make a call to Azure AD in the cloud, Azure AD Sync uses the Azure AD Connect service endpoint URL, which is provided during installation. This URL is used by Azure AD Sync to connect to the Azure AD Connect service, authenticate, and exchange data securely.
Once the connection is established, Azure AD Sync retrieves the data from the on-premises Active Directory and sends it to Azure AD through the Azure AD Connect service. Any changes made in Azure AD are also retrieved by Azure AD Sync and synchronized back to the on-premises Active Directory.
Because In the reverse the communication pattern is different.
The Azure AD Connect Health Service endpoints are configured during the installation of the Azure AD Connect server. They provide a secure communication channel between the Azure AD Connect service and Azure AD, allowing password write-back information and other synchronization information to be transmitted securely.
The Azure AD Connect Health Sync Insights service is a component of Azure AD Connect Health, which is a cloud-based service that provides monitoring and reporting capabilities for Azure AD Connect deployments. The Azure AD Connect Health Sync Insights service collects data from the Azure AD Connect service and provides insights into the synchronization process; it acts like a heartbeat for the bi-directional sync service.
When a user changes their password in Azure AD, password write-back request is received by the Azure AD Connect Health Service endpoint, it is forwarded to the on-premises Azure AD Connect server. The Azure AD Connect Health Sync Insights service then records the password write-back event and forwards the information to the local SQL database to cache the new password information. The Azure AD Connect server then writes the password change to the on-premises Active Directory and sends a success or failure message back to the Azure AD Connect Health Sync Insights service through the Azure AD Connect Health Service endpoint.
This is where SQL Server Native Client provider can become the weak link in the chain. If it is not configured to facilitate TLS 1.2 the password write-back will fail because TLS 1.2 is enforced on the Windows Server OS but is not configured for the SQL Native Client provider. If the incoming password change metadata and hash is not written in the local SQL database, success event will not be sent back to Azure AD, the process will break down and users will get a failure when attempting to change password.
Microsoft article on enabling TLS 1.2 for SQL databases and drivers: Click Here
The FIX:
Here are the steps to enable TLS 1.2 for .NET Framework 4.7 using registry settings:
Open the Registry Editor on the machine where .NET Framework 4.7 is installed.
Navigate to the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
Create a new DWORD value named “SchUseStrongCrypto” (without quotes).
Set the value of the “SchUseStrongCrypto” DWORD to 1.
Close the Registry Editor and restart the machine.
After you have made these changes, .NET Framework 4.7 will use the strongest available security protocols, including TLS 1.2, for secure communication with other systems, including SQL Server databases.
User can now change password in Azure AD again. Voila!
