Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
LDAP Channel Binding and LDAP Signing Requirements - March 2020 update final release
Published Nov 04 2019 06:26 AM 387K Views
Microsoft

Hi All, Alan here again, this time trying to give some details on these two settings that are creating quite some confusion.

 

ATTENTION: before you continue reading I must emphasize that the MARCH 2020 update and FUTURE UPDATES *****WILL NOT MAKE ANY CHANGE*****. This means that we leave it to Customer to decide when to enforce these settings, now and in the future.

https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirem...

 

Our recommendation is to enforce both of them and not leave your environment at risk

 

NEW AUGUST 8 , 2023 UPDATE (New section in the following link)

2020 and 2023 LDAP channel binding and LDAP signing requirements for Windows (KB4520412) - Microsoft...

 

Another important article that I suggest to read:

LDAP session security settings and requirements after ADV190023 is installed

 https://support.microsoft.com/en-us/help/4563239/ldap-session-security-settings-and-requirements-aft...

 

I have to point out that at first these changes were scheduled to become active with upcoming March 2020 update, but some improvements were made and now March 2020 update will only add some new functionalities and make no changes, giving Customers the opportunity to choose.

 

Let’s start saying that since Windows Server 2008 we have Event IDs related to unsigned LDAP binds like 2886, 2887, 2888 and 2889 if you enable auditing which will detail IP Address and Account that made the request

 

Also the new March 2020 update will add support for new Event IDs related to LDAP Channel Bindings. After you install the update you will have 3040 and 3041 triggered every 24 hours by default and 3039 if you enable auditing which will detail IP Address and Account that made the request  (CBT is used only in rare cases: LDAP session security settings and requirements after ADV190023 - Windows Server | Microsoft Docs)

 

 

This information is preliminary and is subject to revision.
This article is a living document, written over time and is subject to change. When guidance presented in this article is in direct conflict with official documentation, one must defer to official documentation.

 

This is the link to the public Security Advisory

ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

 

This is the link to the public KB:

https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirem...

 

March 2020 update links:

Windows 10 v1903 and Windows 10 v19094540673 
Windows 10 v1809: 4538461 
Windows 10 v1803: 4540689
Windows 10 v1709: 4540681

Windows Server 2019: 4538461 
Windows Server 2016: 4540670
Windows Server v1903 and Windows Server v1909: 4540673 
Windows Server v1803: 4540689

Windows 8.1 and Windows Server 2012 R2 Monthly Rollup: 4541509 
Windows 8.1 and Windows Server 2012 R2 Security Only: 4541505
Windows Server 2012 Monthly Rollup: 4541510 
Windows Server 2012 Security Only: 4540694

 

Also I would like to point out this great article that details how this other vendor supports these two features (Red Hat source)
Impact of Microsoft Security Advisory ADV190023 | LDAP Channel Binding and LDAP Signing on RHEL and AD integrationhttps://access.redhat.com/articles/4661861

 

NEW AUDITING capabilities coming with March 2020 update

March 2020 update will add new Auditing capabilities into group policies related to LDAP Channel Binding and LDAP Signing (this one has been around for a while) 

 

  • Through new Group Policy setting you can configure LDAP Channel Binding and LDAP Signing "auditing"

NOTE: Auditing can also be enabled via Registry, on each Domain Controller

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2  

 

Once you have configured auditing, the system will start logging the following Event IDs (Directory services log):

 

For LDAP Signing 

Event ID 2889 (needs auditing enabled)

 

Triggered when a client does not use signing after authentication on sessions on the LDAP port. 

 

***Event 2889 will be triggered when there is no encryption and the client making the bind request does not support LDAP Channel Binding. In all bind requests using SSL/TLS, the LDAP channel binding token is required; if it is not provided, the request will be rejected. 

 

This is the Event ID you want to check to understand which IP Addresses and Accounts are making these requests.

 

Once you open Event ID 2889 in Details you will have

Client IP address: “Value”
Identity the client attempted to authenticate as: “Value” 

 

2889 The security of these domain controllers can be improved by configuring them to reject simple LDAP bind requests and other bind requests that do not include LDAP signing. Triggered when a client does not use signing for binds on sessions on port 389. Minimum Logging Level: 2 or higher

 

You will also find these other events related to LDAP (by default with no auditing enabled): 

 

2886 (already on by default and logged every 24 hours)

Telling us that our DCs are not requiring LDAP signing 

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd... 

  

2887 (already on by default and logged every 24 hours)

Telling us how many such binds occurred 

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd... 

The suggested path to resolve this error is do modify the registry of the DC to allow it log those failures. 

 

2888 (already on by default and logged every 24 hours)

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 event 2888 one time every 24 hours when such bind attempts occur. 

 

The mapping between LDAP Signing Policy settings and registry settings are included as follows:

  • Policy Setting: "Domain controller: LDAP server signing requirements"
  • Registry Setting: LDAPServerIntegrity
  • DataType: DWORD
  • Registry Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Group Policy Setting Registry Setting
None 1
Require Signing 2

 

For LDAP Channel Binding 

Event ID 3039 (needs Auditing enabled)

 

Triggered when a client attempts to bind without valid CBT

 

This is the Event ID you want to check in order to understand which IP Addresses and Accounts are making these requests.

 

***Triggered only on “When Supported” and “Always” when a client fails to bind due to invalid CBT  

 

3039 The following client performed an LDAP bind over SSL/TLS and failed the LDAP channel binding token validation. Triggered when a client attempts to bind without valid CBT. Minimum logging level: 2

 

You will also find these other events related to LDAP (by default with no auditing enabled): 

 

3040 Triggered every 24 hours by default when CBT group policy is set to "Never" and at least one unprotected bind was completed​ 

 

3041 Triggered every 24 hours by default on startup or start of service if the CBT group policy is set to "Never"​

 

The mapping between LDAP Channel Binding Policy settings and registry settings are included as follows:

  • Policy Setting: "Domain controller: LDAP server channel binding token requirements"
  • Registry Setting: LdapEnforceChannelBinding
  • DataType: DWORD
  • Registry Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters  
Group Policy Setting Registry Setting
Never 0
When Supported 1
Always 2

 

 

Recommended ACTIONS 

For IT Adminstrators we recommend to Enable Auditing and fix issues in order to enable both of these enforcements 

 

Support for LDAP Signing is common among non-Windows OS versions

Support for LDAP Channel Binding is rare among non-Windows operating systems. 

 

  1. Find out which Appliances / Services are making these requests and try to find out if they support LDAP Signing and LDAP Channel Binding. Ask each specific "vendor" for detailed information and guidelines
  2. Find out which Non-Windows OSs and which Applications running on them are making these requests. Check if they support and can be configured with LDAP Signing and/or LDAP Channel Binding
  3. Find out which Windows OSs and which Applications running on them are making these requests. 
  4. All versions of Windows after XP support LDAP signing. 

Windows XP does NOT support LDAP channel binding and would fail when LDAP channel binding is configured  with a value of “always” but would remain interoperable with DCs configured with more relaxed LDAP channel binding setting of “when supported”.  

  1. Configure recommended values for Signing and CBT
    • LDAPServerIntegrity = 2
    • LdapEnforceChannelBinding = 1

NOTE: Once you fix all the unsecure connections from Applications/Applicances/Devices/OSs we suggest to enforce these settings to ensure your environment is secured

Enable LDAP Signing and LDAP Channel Binding

LDAPServerIntegrity = 2

LdapEnforceChannelBinding = 2

 

DETAILED Information about these settings

The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher
layer to the channel at the lower layer. https://tools.ietf.org/html/rfc5929 and https://tools.ietf.org/html/rfc5056

 

LDAP Channel Binding

March 2020 update will add the following: 

 

  • Adds support for a new LDAP Channel Binding policy "Domain Controller: LDAP server channel binding token requirements"
  • Adds support for 3039, 3040, 3041 events logged in the Directory Service event log to identify LDAP binds that don't use CBT
  • Allows LDAP Signing and Channel Binding to be independently "relaxed" or "hardened" at any time
  • DOES NOT modify the policy setting or the registry equivalent for “Domain controller: LDAP server channel binding token requirements” in any way

 

Very important NOTE: You need to have this CVE-2017-8563 installed on your clients as a prerequisite before enabling LDAP Channel Binding and LDAP Integrity on DCs  

ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

 

CVE-2017-8563 | Windows Elevation of Privilege Vulnerability (REQUIRED) 

An elevation of privilege vulnerability exists in Microsoft Windows when a man-in-the-middle attacker is able to successfully forward an authentication request to a Windows LDAP server, such as a system running Active Directory Domain Services (AD DS) or Active Directory Lightweight Directory Services (AD LDS), which has been configured to require signing or sealing on incoming connections. 

The update addresses this vulnerability by incorporating support for Extended Protection for Authentication security feature, which allows the LDAP server to detect and block such forwarded authentication requests once enabled.  

Main thing to point out is that March 2020 update WILL NOT make any change nor any future update. 

For LDAP Channel Binding we recommend configure the most compatible setting which equals to the following: 

  • LDAP Channel Binding = 1 

AD - HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters 

ADLDS - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<LDS instance name>\Parameters 

 

value:1  = indicates "enabled, when supported". All clients that are running on a version of Windows that has been updated to support channel binding tokens (CBT) must provide channel binding information to the server. Clients that are running a version of Windows that has not been updated to support CBT do not have to do so. This is an intermediate option that allows for application compatibility. 

 

Possible CBT values:

  • DWORD value: 0 indicates disabled. No channel binding validation is performed. This is the behavior of all servers that have not been updated.
  • DWORD value: 1 indicates enabled, when supported. All clients that are running on a version of Windows that has been updated to support channel binding tokens (CBT) must provide channel binding information to the server. Clients that are running a version of Windows that has not been updated to support CBT do not have to do so. This is an intermediate option that allows for application compatibility.
  • DWORD value: 2 indicates enabled, always. All clients must provide channel binding information. The server rejects authentication requests from clients that do not do so.

 

Important Notes  

- Before you enable this setting on a Domain Controller, clients must install the security update that is described in CVE-2017-8563. Otherwise, compatibility issues may arise, and LDAP authentication requests over SSL/TLS that previously worked may no longer work. By default, this setting is disabled. 

- The LdapEnforceChannelBindings registry entry must be explicitly created.  

- LDAP server responds dynamically to changes to this registry entry. Therefore, you do not have to restart the computer after you apply the registry change. 

 
LDAP Channel Binding: To maximize compatibility with older operating system versions (Windows Server 2008 and earlier versions), we recommend that you enable this setting with a value of 1. 
 
To explicitly disable the setting, set the LdapEnforceChannelBinding entry to 0 (zero). 

Windows Server 2008 and older systems require that Microsoft Security Advisory 973811, available in “KB 968389 Extended Protection for Authentication”, be installed before installing CVE-2017-8563. 

If you install CVE-2017-8563 without KB 968389 on a Domain controller or AD LDS instance, all LDAPS connections will fail with LDAP error 81 - LDAP_SERVER_DOWN. In addition, we strongly recommended that you also review and install the fixes documented in the Known Issues section of KB 968389.  

 

LDAP Signing

  • LDAP Server Integrity (signing) = (March 2020 update will NOT change this setting)

https://support.microsoft.com/en-us/help/935834/how-to-enable-ldap-signing-in-windows-server-2008 

I want to note that this article shows two sections related to server and client, which need to be configured: 

- How to set the server LDAP signing requirement 

- How to set the client LDAP signing requirement through a domain Group Policy Object  

 

If we want to force these settings you should configure these settings :

  1. Enable LdapEnforceChannelBinding = 1  (must have CVE-2017-8563)
  2. Enable LDAP Server Signing  
    • DCs = policy "Domain controller: LDAP server signing requirements" = Require Signing 
    • Servers/Clients = policy "Network security: LDAP client signing requirements = Require Signing 

 

Summarizing 

Summarizing this long article we can state the following: 

  1. AUDIT - Directory Services Log is our friend, find out which machine/account is making these unsecure connections:
    • Event IDs 2889 for LDAP Signing
    • Event IDs 3039 for LDAP Channel Binging
  2. AUDIT - Appliances/Devices/Applications: find out if they support Signing and Channel Binding 
  3. Fix issues and Enforce these settings through GPO "manually"
  4. On Clients/Servers we need to have as a prerequisite CVE-2017-8563 “Extended Protection for Authentication” before we enable LDAP CBT and LDAP Signing
  5. March update will not make any change to signing or channel binding

 

Hope this helps a little more understanding what these settings are all about. Remember that the main thing is to Audit and make a list of Systems/Accounts/Devices/Appliances/Applications, that are making these unsecure binds.

Fix issues and make your environment safer. The decision is up to you!!

 

 

Regards to All 

 

Alan @ PFE

229 Comments
Copper Contributor

@ChadWst 

 

The change in behavior that I see is in regards to Not Defined and None changing from the current Off to Required once the patch is released. (I believe this applies to both Server and Client side.) That is definitely important information to have, but it seems as though I'm simulating the changes that you asked about. If fact, I'm going beyond that by setting the clients to 2 and leaving the DCs at 1. After the patch, this apparently will need to be changed to 0 on the DCs. That seems to be the only thing I would have to do in order to be in the same state as my current test scenario.

 

Let me know if I'm missing something, as I'm simply trying to understand this myself.

Brass Contributor
@CFS3RD -- I think we all are :) Basically you're saying as long as its off on the DC side, it doesn't matter what the client side is right?
Copper Contributor

That's my take. For the time being, if your DCs are set to "None" in their GPO and if you set a test workstation GPO to Required, that will be a legitimate test, as far as I can tell.

 

Of course, this brings up at least one more question.....Will there be additional settings in the GP Editor after the patch? Or will it require a Registry setting in Group Policy Preferences, as @RossUA mentioned?

Brass Contributor

@Alan La Pietra, @CFS3RD , @ChadWst 

 

Update: I'm terribly sorry, but my test was wrong, as it was something wrong with the test server, before I started. Another server doesn't exhibit same issues.


I just made a test, setting LdapServerIntegrity on Domain Controllers to 0 and setting one of the client to "Require Integrity". As a result, I get Event ID 1216 on DC:

 

Internal event: An LDAP client connection was closed because of an error.

Client IP:
xxx.xxx.xxx.xxx:55041

Additional Data
Error value:
1236 The network connection was aborted by the local system.
Internal ID:
c060420

After restart on the client:

Netlogon EVENT ID 3210

 

This computer could not authenticate with \\<DC FQDN>, a Windows domain controller for domain <Domain Name>, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.

 

So that means, if Microsoft doesn't change behaviour of the "OFF" setting, we will have to turn off LDAP Signing for the whole domain, if we have even a single client, not supporting it. We will have to make sure all clients are configured to Negotiate signing also. Furthermore, we will have to do it before the update, otherwise systems will stop working, like VPN, Proxy, NAS, Linux systems, Network appliances and other stuff, like Java plug-ins connecting to AD.

 

Awesome Christmas present, thank you, Microsoft!

Brass Contributor
It looks like the official advisory has been updated to March 2020 now. -- https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023
Microsoft

@RossUA 

The policy "Domain controller: LDAP server signing requirements" contains only settings "None" and "Require Signing"

If you need to set the policy to OFF you need to modify registry

In registry there are 2 settings for Ldap Signing:

Domain Controller side : HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters  --> LDAPServerIntegrity = 0 --> THIS means OFF, only ZERO

Client/server side : HKLM\SYSTEM\CurrentControlSet\Services\LDAP\Parameters  --> LDAPServerIntegrity= 1 --> DON'T TOUCH

 

Again

ZERO wont be changed

ONE will change to Required

 

Don't go through the description in the policy, very confusing.

 

Regards

 

Alan @ PFE

 

 

Brass Contributor

@Alan La Pietra 

If it is possible at all, I would really ask you to reconsider changing behaviour of ONE. Because this behaviour change will be disruptive for 95% of companies using AD, which is bigger than 300 people. Corporate IT people usually don't have competence to look that deep into AD, while bigger companies will have no option, rather than to turn off LDAP Signing completely, as the risk is too high (edit: because of the large amount of 3rd party applications).

 

Preparing for this change properly (Setting Domain Controller to Require Signing in advance with a controlled change), monitoring unsigned LDAP, reconfiguring applications to use LDAP SSL for all our clients would probably take 5 months, if we have good manning. It's going to cost millions of USD for large or medium service providers.

Copper Contributor

If all of our LDAP clients are already using LDAPS (port 636), does this still apply??

Or is all of this only necessary if you have basic LDAP clients (port 389)?

Copper Contributor

Sorry, but I don't understand that chart.  There are check marks under both columns which seems contradictory.  Can you just respond to my questions with specific answers?

Brass Contributor

@CFS3RD, @ChadWst , @Alan La Pietra 

 

My previous post with test results was wrong, I selected a test server which had some issues. Sorry for misleading.

 

I have repeat the test with another server and it looks like, the behaviour of LDAPServerIntegrity = 0 is actually "Negotiate" and not "Disable". So if we set it to 0 before the update arrives, there should be no consequence for the environment, after update. @Alan La Pietra , could you please confirm that this is correct?

Copper Contributor

!!! Updated !!! 

Thanks to @RossUA 

 

In a certain way i agree with @BBCMicro. It takes a while to understand what an admin have to do to prepare for the update. I'm wondering that MS will enforce LDAP signing which could cause applications stop working. But it's true, LDAP without signing should be switched off long ago.

 

My suggestion for this issue (check it yourself !):

 

  • Ignore LDAP channel binding token (LDAP CBT) stuff: The setting in March 2020 update will be "compatibility mode".
  • With March 2020 update, the operating system itself will change the interpretation of the "ldapserverintegrity" registry key value.
    • Without the March 2020 update, "not defined", "0" and "1" means "Negotiate"; "2" means "Require Signing"
    • With the March 2020 update, "0" means "Negotiate"; "not defined", "1" and "2" means "Require Signing"
    • "0" can not be set via GPO security setting "LDAP server signing requirements" ("None" = "1", "Require signing" = 2)
    • If LDAP server is set to require signing, the LDAP client setting of all clients and the DCs itself must be set to require signing.
  • With rsop.msc or gpresult, check the DC effective settings for "Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/Domain Controller: LDAP server signing requirements"
    • If "Require signature" => all done
    • If "None"
      •  Start analyzing LDAP clients NOW
        • Check DC Eventlogs for Event ID 2887 (once per 24 hours); it indicates that there are unsigned requests
        • Start with temporary enabling NTDS/Diagnostics: LDAP Interface Events:DWORD:2 on a few DCs
        • Use Powershell to analyze the DC events 2889 (see Alans post ‎12-16-2019 05:59 AM as template)
      • Create a new GPO "DC Pref LDAP Signing None" with Preference/Registry "ldapserverintegrity" set to "0"
      • Link the new GPO to the OU "Domain Controllers" (or the OU where the DC computer objects reside) with Link Order "1"
      • Do "gpupdate /force" two times on a DC and check that the new GPO is applied
      • Check that all DCs has "ldapserverintegrity" set to "0"
      • ==> prepared for the March 2020 update, Negotiate enabled
      • If ready to enable LDAP signing
        • Check that the original DDCP (or your own DDCP) has "LDAP server signing requirements" set to  "Require signing"
        • Check that the original DDCP (or your own DDCP) has "Network security: LDAP client signing requirements" set to  "Require signing"
        • Configure GPOs for Domain members to "Require signing" (Network security: LDAP client signing requirements)
        • Check that all clients works wih LDAP signing (Event 2887)
        • Disable the link for GPO "DC Pref LDAP Signing None"
        • Do a "gpupdate /force" on an DC and check that the LDAP server signing has changed to  "Require signing"
        • Check that all DCs has "ldapserverintegrity" set to "2"
        • Check for problems; rollback with linking the GPO "DC Pref LDAP Signing None" with Link Order "1"
        • After a couple of weeks, if all works fine, delete the GPO  "DC Pref LDAP Signing None"
  • After March 2020 update
    • Check to update the Central Store; LDAP CBT settings may become available for configuring in GPMC
    • decide whether LDAP CBT compatibility is secure enough; otherwise use LDAP Interface Events to analyze DS events 3039,3040 and take further action

Don't forget AD LDS: LDAP server signing have to be configured for every instance (https://support.microsoft.com/en-us/help/935834/how-to-enable-ldap-signing-in-windows-server-2008) By default, for Active Directory Lightweight Directory Services (AD LDS), the registry key is not available. Therefore, you must create a LDAPServerIntegrity registry entry of the REG_DWORD type under the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<InstanceName>\Parameters

 

Microsoft

@knppdmnq remember that the only way to disable LDAP Signing "before" installing March or later updates, is to set registry key = 0

LDAPServerIntegrity = 0 (obviously not recommended)

 

 

Regards

 

Alan @PFE

Brass Contributor

@knppdmnq 
Initial article was updated with information that "LDAP server signing requirements" set to "None" will effectively become "Require Signing" after the update. So in order to keep "negotiate" behaviour, you have to set registry key LDAPServerIntegrity to 0, while "none" sets this key to 1.

Sorry, just noticed Alan has already answered it while I was replying.

Microsoft

@RossUA no problem thanks for answering, I'm glad to see how comments are helping others, GREAT!! 

 

Copper Contributor

If all of our LDAP clients are already using LDAPS (port 636), does anything need to be changed??

Or is all of this only necessary if you have basic LDAP clients (port 389)?

The chart in the docs don't really answer this question.

Copper Contributor

@RossUA << So in order to keep "negotiate" behaviour, you have to set registry key LDAPServerIntegrity to 0, while "none" sets this key to 1.>>

Yes, admins have to make sure that the negotiate behavior works until every application and all systems are reconfigured. 

 

With the March 2020 update, the operating system itself will change the interpretation of the "ldapserverintegrity" registry key values, is that correct ?

@Alan La Pietra , you meant that the March update change the DDCP. This will not happen if the registry value for DCs is "0", is that correct ?

 

Via GPO the setting can be configured to "None" (value "1") or "Require signing" (value "2"). To make sure the value is "0", the LDAP server signing in GPO have to be changed to "Not configure" and set the registry manually (!) on all DCs. Is that correct ?

Is there an ADMX update with March update to configure "OFF" via GPO ?

Brass Contributor

@graberj 

Yes, that was my understanding and I have just confirmed it with ldp.exe . If you use LDAPS (TCP/636) then your traffic is considered as already signed and your environment will not be affected. Just remember, that there's also LDAP Global Catalogue 3268 and LDAP GC SSL 3269. If you are using port 3268, it will be affected same as LDAP on port 389. So I would recommend enabling diagnostic logging and make sure you get no events 2889.

 

@knppdmnq 

Yes, that is correct, based on what Alan has written in this article, the operating system will change the interpretation of "ldapserverintegrity"="None" value. Today it is "Negotiate", but will become "Require signing".

DDCP, if you mean Default Domain Controllers policy will not be changed.

This setting is a part of Security Settings, so it cannot come as update in ADMX template. It should be possible to create a custom ADMX template for this setting, but I would rather use GP Preferences and registry key. No need to do it manually.

Copper Contributor

@Alan La Pietra (or anyone) So if we know most of our LDAP traffic is over 389 and unsigned, and we can see the DC event logs showing that most requests in a 24 hour period are unsigned, and it's completely unrealistic to move all these apps over to signed LDAP by March 2020, is our only option to set LDAPServerIntegrity = 0 to continue as normal until we can attempt a more measured approach towards moving 3rd party applications to signed LDAP?

 

Just looking for confirmation that I've read and understood everything correctly-- this is all fairly deep/dense information for someone not intimately familiar with LDAP. 

Brass Contributor

@JMHahn 

What you write is exactly what we are planning to do for our customers. Alternative to this will be to postpone patching, which we might be forced to do if we don't manage to distribute this setting to few hundreds of domains before mid-March.

 

There was a suggestion from a colleague of mine, to set LDAPServerIntegrity=0 on only one or two DCs, leaving the rest with more secure settings. Although, I don't see a big benefit in doing it.

Copper Contributor

Hi,

 

The article states: You need to have this CVE-2017-8563 installed on your clients as a prerequisite before enabling LDAP Channel Binding and LDAP Integrity on DCs.

 

I cant find the patch for Windows 10 1809. Does this version of Windows 10 already have the patch?

 

Thanks

Copper Contributor

@RossUA @Alan La Pietra updated my post from 01-08-20. Thanks for support.

I hope I have described everything correctly and others can use it as a template to deal with this topic. Good luck in march.

Copper Contributor

@RossUA You would definitely want to know which DCs receive normal 389 LDAP authentication request from third-party applications before you decide which DC to include/exclude. This wouldn't be difficult via the event logs, but you would want to quadruple check everything. The benefit is that you'd have a "patched" DC of which to direct third party apps once you enable signed LDAP for testing.  

 

I feel like this is a good answer to client-to-DC LDAP authentication requests, and it's Microsoft's intention to keep this traffic secure-- but I every time I think about this patch/change I feel it's going to be an unmitigated disaster for companies, schools and organizations which don't have the expertise or haven't read the advisory. I have a good working knowledge of several small-to-large companies who have countless third party applications and homegrown apps that utilize vanilla LDAP authentication which would break overnight after this March patch. 

 

I step pretty lightly where DCs are concerned. It would be nice to have comprehensive explanations and documentation as to these settings before Microsoft simply releases it to the wild. In 2 months we're going to be installing these patches to maintain compliance and for a lot of people that's only 1-2 maintenance windows of availability of which to implement change. 

 

I've had an advisory ticket open with the Directory Services support and for 2-3 days I've only gotten the response, "We have very little information on this internally, I'm researching this for you." This seems like the sort of thing you'd be training and prepared for well in advance. 

Copper Contributor

@JMHahnvery good words ! It is very confusing changing the interpretation of a registry key with an update, which will result in a wrong description in the Group Policy explanation. 

Brass Contributor

@JMHahnWe have several hundreds of domains, with some customers having hundreds of third-party applications, many of which are using LDAP. I did monitoring for one of the customer and have got the following list of applications:

 

Airwatch
Jira

Webproxy

App for 2-factor authentication

VPN

Identity synchronization software

Software used by Sales

Calendar synchronization

Java application, which is using custom AD plugin

Linux servers, integrated with AD

 

And of course, there were some traffic that wasn't immediately possible to connect with application, for which further analysis is necessary.

 

So I agree, this is going to be a disaster. I really hope Microsoft has a really strong reason for doing such change, which they will reveal later.

Copper Contributor

Don't know why, but the post from 01-08-2020 is gone.

My summary and suggestion for this issue (check it yourself !); I hope I have described everything correctly and others can use it as a template to deal with this topic. Good luck in march.

 

  • Ignore LDAP channel binding token (LDAP CBT) stuff: The setting in March 2020 update will be "compatibility mode".
  • With March 2020 update, the operating system itself will change the interpretation of the "ldapserverintegrity" registry key value.
    • Without the March 2020 update, "not defined", "0" and "1" means "Negotiate"; "2" means "Require Signing"
    • With the March 2020 update, "0" means "Negotiate"; "not defined", "1" and "2" means "Require Signing"
    • "0" can not be set via GPO security setting "LDAP server signing requirements" ("None" = "1", "Require signing" = 2)
    • If LDAP server is set to require signing, the LDAP client setting of all clients and the DCs itself must be set to require signing.
  • With rsop.msc or gpresult, check the DC effective settings for "Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/Domain Controller: LDAP server signing requirements"
    • If "Require signature" => all done
    • If "None"
      •  Start analyzing LDAP clients NOW
        • Check DC Eventlogs for Event ID 2887 (once per 24 hours); it indicates that there are unsigned requests
        • Start with temporary enabling NTDS/Diagnostics: LDAP Interface Events:DWORD:2 on a few DCs
        • Use Powershell to analyze the DC events 2889 (see Alans post ‎12-16-2019 05:59 AM as template)
      • Create a new GPO "DC Pref LDAP Signing None" with Preference/Registry "ldapserverintegrity" set to "0"
      • Link the new GPO to the OU "Domain Controllers" (or the OU where the DC computer objects reside) with Link Order "1"
      • Do "gpupdate /force" two times on a DC and check that the new GPO is applied
      • Check that all DCs has "ldapserverintegrity" set to "0"
      • ==> prepared for the March 2020 update, Negotiate enabled
  • After March 2020 update
    • Check to update the Central Store; LDAP CBT settings may become available for configuring in GPMC
    • decide whether LDAP CBT compatibility is secure enough; otherwise use LDAP Interface Events to analyze DS events 3039,3040 and take further action
  • If ready to enable LDAP signing
    • Check that the original DDCP (or your own DDCP) has "LDAP server signing requirements" set to  "Require signing"
    • Check that the original DDCP (or your own DDCP) has "Network security: LDAP client signing requirements" set to  "Require signing"
    • Configure GPOs for Domain members to "Require signing" (Network security: LDAP client signing requirements)
    • Check that all clients works wih LDAP signing (Event 2887)
    • Disable the link for GPO "DC Pref LDAP Signing None"
    • Do a "gpupdate /force" on an DC and check that the LDAP server signing has changed to  "Require signing"
    • Check that all DCs has "ldapserverintegrity" set to "2"
    • Check for problems; rollback with linking the GPO "DC Pref LDAP Signing None" with Link Order "1"
    • After a couple of weeks, if all works fine, delete the GPO  "DC Pref LDAP Signing None"

 

 

Don't forget AD LDS: LDAP server signing have to be configured for every instance (https://support.microsoft.com/en-us/help/935834/how-to-enable-ldap-signing-in-windows-server-2008) By default, for Active Directory Lightweight Directory Services (AD LDS), the registry key is not available. Therefore, you must create a LDAPServerIntegrity registry entry of the REG_DWORD type under the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<InstanceName>\Parameters

 

Copper Contributor

@Alan La Pietra 

 

Can you please clarify what effect this update will have on Ldap CLIENT signing (LdapClientIntegrity), specifically if it's currently set to negotiate? We are successfully using the following settings without any problems:

  • DCs = policy "Domain controller: LDAP server signing requirements" =Require Signing  (LdapServerIntegrity =2)
  • Servers/Clients = policy "Network security: LDAP client signing requirements = Negotiate Signing  (LdapClientIntegrity = 1)

It seems based on the information provided that the update will only change LdapServerIntegrity and LdapEnforceChannelBinding. But it is still mentioned to change Network security: LDAP client signing requirement to Require Signing. Is this actually necessary since client negotiation (which still provides LDAP signing) is the default anyways on modern Windows versions? Will we see any impact from this update for Windows clients if we keep LDAP server signing to required and LDAP client signing to negotiate?

Brass Contributor

@Alan La Pietra 
Could you please share some more information on the coming update, so that we can prepare in a better way?

  • Will this update apply for 2008 Server family? It is now outside the extended support cycle, so are you planning to skip it or not?
  • How this update will be distributed to different systems? E.g. for Server 2016 and 2019, will it be a part of monthly cumulative patch, or it will be a separate update? Same for 2012 and eventually 2008 - will it be a separate patch, or part of roll-up?
  • How big are chances that Microsoft will reconsider changing default behavior of LDAP Server Signing? We are starting a huge project to make sure our customers don't get in trouble in March, but we all know that there are a lot of poorly maintained environments, which will have issues. For many people, it's hard to believe that MS will really enforce signing, as this could have huge impact on so many systems. And yes, of course, signing had to be enabled long time ago, but in many cases, there are valid reasons why it hasn't been done yet.

 

Copper Contributor

What exactly is LDAP channel binding. I've yet to see an actual technical description of it.

Microsoft

@jpenning good question, first it relates to TLS.

To make it simple, an example could be the following:

Client-A connects to Server-A via TLS "TLS 1 connection". Without CBT there is a chance of man-in-the-middle grabbing this session and using "TLS 1 connection" to Server-A successfully. 

With CBT information sent in the request, Client-A connects to Server-A via TLS "TLS 1 connection", man-in-the-middle grabs the session and makes connection to Server-B but this time it will be a "TLS 2 connection" which will fail as Server-A expects "TLS 1 connection"

 

Alan @ PFE

 

Copper Contributor

@Alan La PietraSo is LDAP channel binding the same thing as connecting via LDAPS and port 636?

Microsoft

@AndersPalsson 

LDAP channel binding the same thing as connecting via LDAPS and port 636?

Copper Contributor

@Alan La Pietra Thanks for the explanation - I appreciate it.

 

 

I have particular clients in my environment that authenticate against AD with NTLM - and these requests are being logged on my DCs as event 2889 (The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection.)

 

 

Theoretically, how could this be addressed on the client side? Is NTLM "signing" even a thing that exists?

Copper Contributor

Is the KB number already known for that March 2020 update ?

Brass Contributor

@jpenning 

Yes, it is possible to use NTLM while authenticating the LDAP Bind and have signing afterwards. You can try it with ldp.exe tool:

clipboard_image_0.png

At the same time, simple ldap bind doesn't work, which proves that server is requiring signing:

clipboard_image_1.png

Both tests done with connection to port 389.

Copper Contributor

@RossUA   Thanks for that.

 

 

Forgive my ignorance, I figured out how to test the simple bind with the LDP tool - but can't figure out how to test with NTLM?

Brass Contributor

@jpenning 

On the Bind dialogue, you choose Advanced, press Advanced button and choose the authentication protocol you want to use:

clipboard_image_0.png

Copper Contributor

@RossUA   Got it - thanks!

 

 

In this test scenario, what exactly made it a 'signed' NTLM request?

 

Is it possible to use LDP to test an NTLM attempt that is not requesting signing?

 

Brass Contributor

@jpenning 

It looks like ldp.exe doesn't have a setting that controls negotiate for LDAP Signing and Channel Token binding. Therefore, you have to use registry to enable or disable Signing and Integrity. To disable LDAP Signing negotiation for the client, configure key ldapclientintegrity=0 under

 

HKLM\System\CurrentControlSet\Services\ldap

 

on the client where ldp.exe runs. LDP.exe needs to be restarted after that and will not request signing for any ldap attempts.

 

You can confirm that signing is not used by capturing network traffic, for example with Wireshark. Here's how it looks like when you expand the LDAP protocol field:

clipboard_image_1.png

When it is set to 0, client is not negotiating signing and you can see the following error in bindResponce packet:

clipboard_image_2.png

This is what you will see in ldp:

clipboard_image_3.png

Copper Contributor

@RossUA Thanks for the great insight.

Copper Contributor

to Alan:

When was this information been inserted to the article?

 

Does it mean that we do NOT have to change to LDAPServerIntegrity=0 if we use third party tools not  supporting LDAP signing ?

 

-----------------------------------------------------------------------------------------------------------

****IMPORTANT NEW UPDATED INFORMATION****

The March 2020 3B updates consist of the following on both new and existing domain controllers:

  • New audit events
  • Additional logging 
  • A remapping of Group Policy values

The March 2020 3B updates specifically DO NOT:

Make any changes to the current LDAP signing or channel binding settings, default or otherwise, that apply to new or existing domain controllers.

Copper Contributor

Same question as above, that definitely requires some clarification as I'm pretty sure it wasn't there last time I checked this blog

Brass Contributor

Same question as the others related to the Updated news. This would seem like a significant shift to in our preparation strategies.

 

The March 2020 3B updates specifically DO NOT: Make any changes to the current LDAP signing or channel binding settings, default or otherwise, that apply to new or existing domain controllers.

Microsoft

@AIJohann @CyrAz @ChadWst please refer to our official KB article. Some changes are coming that will help you for sure. I will update this article as soon as I have new official details

 

 

Alan @ PFE  

Copper Contributor

@Alan La Pietra Could you link to the official KB? If you are talking about this, nothing new on the horizon.

 

In my lab, on Windows Server 2019, the following GPO is defined out of the box:

Default Domain Controllers Policy > Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options - Domain controller: LDAP server signing requirements

LDAPServerSingingRequirements.png

 

While I can change the registry key ldapserverintegrity to 0, the GPO automatically changes it back to 1. The obvious solution here is to uncheck the Define this policy setting box in the Default Domain Controllers Policy which effectively change the ldapserverintegrity registry key to 0, so no need to change the registry key manually.

 

Hence, changing the ldapserverintegrity registry key to 0 does not protect you of those upcoming changes on Windows Server 2019 since the Default Domain Controllers Policy will, out of the box, revert the registry key to 1. If you need to delay this change, the only solution seems to set the Domain controller: LDAP server signing requirements GPO status to Not Defined.

 

Can you confirm what will be the exact behaviour of the patch? Will it change the GPO configuration or the registry key value? If it changes the GPO configuration, is there any way to force said GPO to keep its Not Defined status?

Also, can you specify if Windows Server 2012R2 has the Domain controller: LDAP server signing requirements GPO defined, like Windows Server 2019? Only Windows Server 2008 seems to be working with your proposed fix.

 

Thanks,

 

FrenezOrg

Copper Contributor

@Alan La PietraCould you link to the official KB? If you are talking about this (https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023), nothing new on the horizon.

 

In my lab, on Windows Server 2019, the following GPO is defined out of the box:

Default Domain Controllers Policy > Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options - Domain controller: LDAP server signing requirements

LDAPServerSingingRequirements.png

While I can change the registry key ldapserverintegrity to 0, the GPO automatically changes it back to 1. The obvious solution here is to uncheck the Define this policy setting box in the Default Domain Controllers Policy which effectively change the ldapserverintegrity registry key to 0, so no need to change the registry key manually.

 

Hence, changing the ldapserverintegrity registry key to 0 does not protect you of those upcoming changes on Windows Server 2019 since the Default Domain Controllers Policy will, out of the box, revert the registry key to 1. If you need to delay this change, the only solution seems to set the Domain controller: LDAP server signing requirements GPO status to Not Defined.

 

Can you confirm what will be the exact behaviour of the patch? Will it change the GPO configuration or the registry key value? If it changes the GPO configuration, is there any way to force said GPO to keep its Not Defined status?

Also, can you specify if Windows Server 2012R2 has the Domain controller: LDAP server signing requirements GPO defined, like Windows Server 2019? Only Windows Server 2008 seems to be working with your proposed fix.

 

Thanks,

 

FrenezOrg

Copper Contributor

@FrenezOrg 

  • Create a new GPO "DC Pref LDAP Signing None" with Preference/Registry "ldapserverintegrity" set to "0"
  • Link the new GPO to the OU "Domain Controllers" (or the OU where the DC computer objects reside) with Link Order "1"

The update will change the OS behavior of interpreting the registry value of "ldapserverintegrity"

  • before patch: OFF = 0 or anything but 2; ON = 2
  • after patch: OFF = 0; ON = any non-zero value

 

Copper Contributor

Hi.

 

Does this affect somehow if i query Active Directory Data using ADSI/LDAP linked server?

 

Copper Contributor

@Cesar_Limon It may affect it. Make sure by enabling AD advanced logs and look for Event ID 2889.

Here is the PowerShell command to enable AD advanced logs:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' -Name '16 LDAP Interface Events' -Type DWord -Value 2 

It is best practice to disable the logs once you don't need them anymore. To do so, you can use the following PowerShell command:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' -Name '16 LDAP Interface Events' -Type DWord -Value 0 

@knppdmnqDo you know if this also applies to the Channel Binding Token registry key?

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters - LdapEnforceChannelBinding

To my understanding, this key does not exist by default and the value 1 set by the update ensures compatibility with devices not supporting channel binding.

Microsoft

@FrenezOrg Please do not add new GPO. Wait a little as new changes are coming that will help on these settings. As for now setting registry to Zero will disable signing and updates will not touch the value. So you can stay with DDCPolicy

 

@Cesar_Limon yes it will

 

As soon as I have new information I will update article and title so everyone can realize that something has changed

 

Alan @ PFE

Co-Authors
Version history
Last update:
‎Oct 06 2023 06:35 AM
Updated by: