Some months ago, a problem was noticed with one of our servers that hosts the Azure AD Connect Sync service. After a reboot, the service did not automatically start back up as expected; and, upon further inspection, the synchronization from Azure > on-prem domain was not functional. In troubleshooting this issue, I took to the Event Logs to try to determine why this might be occurring. I found the following items that piqued my interest:
| Status | ID | Source |
| Warning | 31045 | PasswordResetService |
| Warning | 31031 | PasswordResetService |
| Warning | 32014 | PasswordResetService |
| Error | 31034 | PasswordResetService |
This brought me to the following post: https://learn.microsoft.com/en-us/answers/questions/181966/problem-enabling-sspr-in-ad-connect-server?page=1
Which provided the following answer by user Don Dao:
“We recently had corporate wide disablement of TLS 1.0 and enablement of TLS 1.2, the fix for me was to added the following registry key, and rebooted the server per this article:
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-prerequisites#enable-tls-12-for-azure-ad-connect
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319
“SchUseStrongCrypto”=dword:00000001
No more Event ID: 31044, 31031, 31045, 32014 cannot communication errors in event viewer now.”
I then referenced the Microsoft document on Azure AD Connect prerequisites titled “Enable TLS 1.2 for Azure AD Connect” from the link in the post (https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/how-to-connect-install-prerequisites#enable-tls-12-for-azure-ad-connect). And Microsoft’s guidance on enabling TLS 1.2 (for CM, but still relevant) provides a more clear understanding of the change, and supplementary registry modifications: https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-client.
“The SchUseStrongCryptosetting allows .NET to use TLS 1.1 and TLS 1.2. The SystemDefaultTlsVersionssetting allows .NET to
use the OS configuration. For more information, see TLS best practices with the .NET Framework.”This MS article elaborates more & includes “WOW6432Node” registry keys for x86 apps:
https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls#configuring-schannel-protocols-in-the-windows-registry
[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
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001After making these modifications to the registry, the Azure AD Connect Sync service has started after reboots automatically, and the bidirectional sync function was restored. It has been functional ever since.