In March 2020, Microsoft is going to release a update which will essentially disable the use of unsigned LDAP which will be the default. This means that you can no longer use bindings or services which binds to domain controllers over unsigned ldap on port 389. You can either use LDAPS over port 636 or using StartTLS on port 389 but it still requires that you addd a certificate to your domain controllers. This hardening can be done manually until the release of the security update that will enable these settings by default.
How to add signed LDAPS to your domain controllers
After the change the following features will be supported against Active Directory.
How will this affect my enviroment?
Clients that rely on unsigned SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP binds or on LDAP simple binds over a non-SSL/TLS connection stop working after you make this configuration change. This also applies for 3.party solutions which rely on LDAP such as Citrix NetScaler/ADC or other Network appliances, Vault and or authentication mechanisms also rely on LDAP. If you haven’t fixed this it will stop working. This update will apply for all versions.
Windows Server 2008 SP2, Windows 7 SP1, Windows Server 2008 R2 SP1, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10 1507, Windows Server 2016, Windows 10 1607, Windows 10 1703, Windows 10 1709, Windows 10 1803, Windows 10 1809, Windows Server 2019, Windows 10 1903, Windows 10 1909
How to check if something is using unsigned LDAP?
If the directory server is configured to reject unsigned SASL LDAP binds or LDAP simple binds over a non-SSL/TLS connection, the directory server will log a summary under eventid 2888 one time every 24 hours when such bind attempts occur. Microsoft advises administrators to enable LDAP channel binding and LDAP signing as soon as possible before March 2020 to find and fix any operating systems, applications or intermediate device compatibility issues in their environment.
The Microsoft Deployment Toolkit (MDT), build 8443, is now available on the Microsoft Download Center. This update requires the Windows Assessment and Deployment Kit (ADK) for Windows 10, version 1607, available on the Microsoft Hardware Dev Center (adksetup.exe file version 10.1.14393.0).
You may notice that we are not tagging this release with a year or update version. To better align with the current branches of Windows 10 and Configuration Manager, and to simplify the branding and release process, we are now just referring to it as the “Microsoft Deployment Toolkit”, using the build number to distinguish each release. This is not necessarily a “current branch” of MDT; we are committed to updating MDT as needed with revisions to Windows, the Windows ADK, and Configuration Manager.
Here is a summary of the significant changes in this build of MDT:
Supported configuration updates
Windows ADK for Windows 10, version 1607
Windows 10, version 1607
Windows Server 2016
Configuration Manager, version 1606
Deployment Wizard scaling on high DPI devices
Johan’s “uber bug” for computer replace scenario
Multiple fixes for the Windows 10 in-place upgrade scenario
Several fixes to Configure ADDS step
Removed imagex/ocsetup dependencies, rely solely on DISM
Includes the latest Configuration Manager task sequence binaries (version 1606)
For those of you who have started deploying Windows 10 1607, you might notice a change in the behavior of the Windows Update agent for PCs that are configured to pull updates from WSUS. Instead of pulling the updates from WSUS, PCs may start grabbing them from peers on your network, leveraging the Delivery Optimization service for referrals to other PCs that have already obtained the content. This change should generally help reduce the amount of network traffic being generated for both quality (monthly) updates and feature updates, offloading that traffic from the WSUS server. It will add some additional traffic between each client PC and the Delivery Optimization service on the internet, as it has to talk to this internet-only service in order to get a list of peers.
If the Windows Update agent can’t talk to the Delivery Optimization service (due to firewall or proxy configurations), or if there are no peers able to provide the content, it will then go ahead and grab the content from the WSUS server.
There is a new Group Policy setting available if you want to disable this behavior, e.g. because you are already using BranchCache for peer-to-peer sharing. To do this, you need to set the “Download Mode” policy under “Computer Configuration –> Administrative Templates –> Windows Components –> Delivery Optimization” to specify “Bypass” mode, which will result in the client always using BITS to transfer the content from WSUS (with BranchCache jumping in to provide the peer-to-peer capabilities through its integration with BITS):