TLS 1.1 disablement on domain controllers

Question

Hello Team,

We have a plan to disable TLS 1.1 on the domain controllers and enforce tls 1.2 which is supproted in the current OS. We know there is not way to find the application dependency from domain controllers end. We will send an announcement to all the app owners to review their apps and enforce tls 1.2, Incase if they miss to do that what kind of impact will occurs, I believe RDP related issues, Application ldaps issue etc.

we will do this disablement phase by phase only via gpo with a rollback plan as well. But what is the best practice you suggest?

Answer 1

Hello @SAGA,

Disabling TLS 1.1 and enforcing TLS 1.2 on domain controllers can have significant impacts if applications are not updated accordingly.

Applications that still rely on deprecated TLS versions (1.0 or 1.1) may experience connectivity issues, including problems with Remote Desktop Protocol (RDP) and LDAP services. Specifically, if applications do not support TLS 1.2, they may fail to authenticate or connect to the domain controllers, leading to service outages or degraded performance. Microsoft has communicated that while TLS 1.0 and 1.1 are not known to have vulnerabilities, they are being deprecated to enhance security and compliance with industry standards.

Failure to do so could result in critical applications being unable to function, particularly if they are part of hybrid infrastructures or rely on Active Directory Federation Services (AD FS).

---

If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

Answer 2

Hi SAGA,

While it is true that finding specific application dependencies directly from the Domain Controller (DC) can be challenging, you can actually use Schannel logging to identify which clients are still using weak protocols before you pull the plug.

You can try to do a more targeted approach to transition:

1.Enable auditing

Before you start the disablement phase, turn on Schannel auditing on your DCs. This will generate Event Logs whenever a client connects using TLS 1.0 or 1.1.

Look for Event ID 3061 in the Directory Service log. This specific event identifies clients using insecure LDAP binds, which is often the biggest "breaking point" when disabling old TLS.

Monitor the System log for Schannel events to catch legacy RDP or SQL connections.

2. Identify the high risk candidates

Focus your communication on owners of legacy infrastructure, specifically:

• Applications using .NET 4.5.2 or older: These do not support TLS 1.2 by default and will fail.
• Old SQL Server Drivers: Legacy OLE DB or ODBC drivers often require manual updates to negotiate TLS 1.2.
• Legacy Appliances: Older printers, scanners, or non-Windows network appliances often lack TLS 1.2 support

3.Recommended rollout phase

Audit Phase (2-4 weeks): Enable logging only. Analyze the logs to identify the most frequent legacy callers.

Pilot Phase: Apply your GPO to a single, non-primary DC first and monitor for "handshake failure" errors in the logs.

Enforcement Phase: Expand the GPO to remaining DCs only after the pilot is stable.

If this guidance helps you refine your GPO strategy, please click "Accept Answer" so other admins planning similar TLS deprecations can benefit from these auditing tips.

Best regards,

Tracy Le.

Answer 3

Disabling TLS 1.0/1.1 and enforcing TLS 1.2 on domain controllers is aligned with Microsoft security guidance and current regulatory expectations. Best practice is to treat this as a protocol deprecation project with clear assessment, phased rollout, and rollback.

Key impacts if applications are not updated

If any client, application, or device still depends on TLS 1.0/1.1 to talk to domain controllers or other Windows services, the impact is a hard failure of the TLS handshake. Typical symptoms include:

• LDAP/LDAPS to domain controllers
  • Applications using LDAPS that only support TLS 1.0/1.1 will fail to bind/authenticate.
  • Directory-integrated apps (identity providers, legacy web apps, appliances) may lose authentication/authorization capability.
• Kerberos/NTLM over TLS-dependent channels
  • Any solution that wraps authentication in TLS (for example, some web apps or proxies that talk LDAPS or WinHTTP/WinINet-based components) may fail.
• RDP and management tools
  • Older RDP clients or management tools that cannot negotiate TLS 1.2 will fail to connect when TLS 1.0/1.1 are disabled at the OS level.
• SQL Server and other back-end services
  • If domain-joined SQL Servers or other services are also moved to TLS 1.2 only, legacy clients (older .NET, Java, ODBC/OLE DB drivers) may fail with errors like “the client and server cannot communicate, because they do not possess a common algorithm” or generic SSL handshake failures.
• Browsers and WinHTTP/WinINet-based apps
  • After the default behavior change, applications using WinHTTP/WinINet that still try TLS 1.0/1.1 will see failures; browsers show messages that the site uses an outdated or unsafe TLS protocol and refuse the connection until TLS 1.2+ is used.

In all of these cases, there is no graceful degradation: if the client cannot use TLS 1.2+, the connection simply fails.

Recommended best practices

1. Follow Microsoft’s general TLS deprecation guidance
   • Microsoft recommends removing TLS 1.0/1.1 dependencies and disabling them at the OS level where possible, as part of an ongoing effort to address security weaknesses and meet compliance requirements.
2. Inventory and communication
   • Continue with the planned announcement to all application owners, explicitly stating:
     • TLS 1.0 and 1.1 will be disabled on domain controllers.
     • Any client or application that cannot use TLS 1.2+ will lose connectivity (LDAPS, RDP, web, APIs, etc.).
   • Call out common risk areas: legacy .NET apps (<4.6), old Java runtimes, old SQL client drivers, appliances, and custom LDAP integrations.
3. Require TLS 1.2 readiness validation
   • Ask app owners to validate:
     • Runtime/framework versions (for example, .NET 4.6+ or updated Java) and confirm TLS 1.2 support.
     • Client drivers (ODBC/OLE DB/JDBC, LDAP libraries) are updated to versions that support TLS 1.2.
   • For hybrid or AD FS scenarios, ensure all on-premises infrastructure supports inbound and outbound TLS 1.2.
4. Phased rollout with controlled scope
   • Apply the GPO in phases to a subset of domain controllers or a pilot OU first.
   • Monitor for:
     • Authentication failures.
     • LDAPS bind failures.
     • Application error logs indicating SSL/TLS handshake issues.
   • Only expand to all domain controllers after a stable pilot period.
5. Maintain a rollback plan
   • As planned, keep a tested rollback GPO or configuration ready to re-enable TLS 1.0/1.1 temporarily if a critical dependency is discovered.
   • Treat rollback as an exception with a clear deadline; the long-term goal remains TLS 1.2+ only.
6. Align with other Microsoft services
   • Microsoft 365 and other services have already disabled TLS 1.0/1.1 or are in the process of doing so, and guidance consistently recommends moving all clients and infrastructure to TLS 1.2 or later.
7. Use OS-level guidance
   • For Windows clients and servers, follow guidance that recommends disabling TLS 1.0/1.1 at the OS level and ensuring applications based on WinHTTP/WinINet are ready for TLS 1.2.

By enforcing TLS 1.2 on domain controllers with a staged rollout, strong communication, and a tested rollback, the environment aligns with Microsoft’s security and lifecycle guidance while minimizing unexpected outages.

---

References:

• KB5017811—Manage Transport Layer Security (TLS) 1.0 and 1.1 after default behavior change on September 20, 2022
• UPDATE: Transport Layer Security 1.0 and 1.1 disablement
• Disabling TLS 1.0 and 1.1 for Microsoft 365
• Disabling TLS 1.0 and 1.1 in Microsoft 365 GCC High and DoD
• How to migrate to Transport Layer Security (TLS) 1.2 enforcement for Microsoft Entra Domain Services
• Preparing for the mandatory use of TLS 1.2+