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
Brass Contributor

When you change the registry key for 16 LDAP Interface Events; does the domain controller have to be rebooted for new settings to take effect?

Copper Contributor

@Mirza Dedic 

The DC doesn't have to be rebooted.

Brass Contributor

We are finding out a lot of application must use the STARTTLS protocol - Is there an way to prove this ?

 

We have contacted a few vendor so far and most didn't even know that Microsoft was doing this

 

 

Copper Contributor

@Alan La Pietra 

 

I am still a little confused on what the actual March update will be doing.  

 

Should we set the registry key to off in GPO and then manually change to 0 in the registry prior to the March update?

Copper Contributor

@Alan La Pietra, if I'm understanding correctly, if HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity is set to 0 before the update, it will not force the change. Is that correct? Likewise, setting HKLM\System\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding to 0 before the update will not force the change? If this behavior is true, that would greatly aid us in prioritizing accordingly.

Microsoft

@strongmanjayh GPO not configured, registry = 0 to disable

 

@FMCUjonesc correct

 

By the way march update will not enforce any change

 

 

Alan @ PFE

Brass Contributor

@Alan La Pietra 

 

Playing around with our RHEL fleet that is connected and using AD for auth in preparation for this, and am finding that with LDAPServerIntegrity=2 on the domain, an ldapsearch over 389 with -Y GSSAPI connection option from the client succeeds and is encrypted according to traces, but is unsigned, and the domain logs the 2889 event telling me so. 

 

in the LDAP signing summary table, the last entry there, "SASL + Built-in Encryption" shows a "successful connection green check mark" in the "LDAP signing required" column.  Is it safe to assume that client signing is NOT required if you use SASL and local encryption, even though the domain says signing is required?  That seems to be the case.  if i use ldapsearch over 389 with -Y GSS-SPNEGO connection option, that also succeeds, but i do not get the 2889 event about unsigned SASL.  that's the ideal condition.  i'm working with a developer at redhat in regards to their adcli package, that is used to keep the machine's password up-to-date, among other things, and how that makes its connection to AD (something i can't control), and we're surprised by this behavior, we expected with LDAPServerIntegrity=2, that unsigned SASL would fail, but it doesn't if GSSAPI is used, and logs the unsigned SASL event anyway.

 

Can you shed any light on that?

Brass Contributor

Please can you provide a simple table that says what will and won't work.  There are 157 comments here already, and comments have been revised, etc.  

Here's an example - THIS IS AN EXAMPLE ONLY - I DON'T KNOW [ANYMORE] IF IT'S CORRECT!

 

 [default]March 2020mid 2020
simple bind (username + password) authentication to LDAP (port 389)works?works, but warnsdoesn't work
SASL (Kerberos, etc) authentication to LDAP (port 389)works?works, but warns? doesn't work?
simple bind (username + password) authentication to LDAPS (port 636)works?works?doesn't work?
SASL (Kerberos, etc) authentication to LDAPS (port 636)works?works?works?

 

It may need another table too, showing the combinations of registry key and their effect;

 

 

DEFAULT

LdapEnforceChannelBinding=0 (disabled)

LDAPServerIntegrity=0

      

mid 2020 update

LdapEnforceChannelBinding=3 (required)

LDAPServerIntegrity=3 (required)

simple bind (username + password) authentication to LDAP (port 389)works?      fails?
SASL (Kerberos, etc) authentication to LDAP (port 389)works?      fails?
simple bind (username + password) authentication to LDAPS (port 636)works?      fails?
SASL (Kerberos, etc) authentication to LDAPS (port 636)works?       works?

[the middle columns would show the possible combinations of...

LdapEnforceChannelBinding

LDAPServerIntegrity

...and which authentication method and connection combination works.

It won't be simple, but hopefully should cut through the confusion.

Copper Contributor

1. Is it correct to interpret the table below as:

-Simply Bind and Unsigned SASL Binds WILL FAIL when LDAP Signing is required

-Simple Bind over TLS; SASL over TLS;  SASL + Built-in Encryption WILL NOT fail when LDAP signing is required.

 
 
 

image001.png

 

The product I am using performs SASL with GSS-API Integrity and Privacy. We have found that when modifying the registry to require LDAP Signing, our binds do not fail BUT event 2889 occurs

 

######
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.

Client IP address:
<client IP: port>
Identity the client attempted to authenticate as:
<domain>\<user>
Binding Type:
0
#######

 

2. Can 2889 be ignored in this case because we are using SASL + Built-in Encryption?
3. Is there any MS Article that describes what you've shown in this table? 

Copper Contributor

So I've been subscribed to this thread for a while now and I noticed that STARTTLS has become more of a hot topic.   When I was doing my research into our Mac issues, I was doing a lot of Wireshark captures trying to figure out what was going on.    Macs apparently use STARTTLS for their SSL implementation to AD (via port 389), as indicated in the capture (see below).    I verified that they keep working even with the LDAP Signing set to 'Required', so while I can't say for certain, I'm pretty sure that STARTTLS will keep working fine even after the updates.     My take on this whole thing is that only unsigned/non-encrypted authentication attempts will fail.   Any initial connections prior to authentication will still work (though you won't be able to do much obviously), until it tries to actually do the bind.   If it either doesn't properly sign/encrypt or bring up a TLS channel with STARTTLS prior to authentication, it will fail.    Connections over LDAPS (636) are encrypted from the start similar to HTTPS and are not an issue as well.

 

jdobiash_0-1581646308379.png

 

 

I hope this helps!

 

Copper Contributor

Ug, not sure if my post was nuked or what, but I'll try this again. (hopefully it won't double post)

 

I've seen STARTTLS being asked a few times.  When I was researching our Macs I did some packet capturing and noticed that the Macs actually do STARTTLS when connecting to AD when the 'ssl' flag is set.  It's over Port 389 as well, and it kept working even with LDAP Signing set to 'Required', so hopefully that means it'll keep working fine even after the updates.   Below is a capture of what the client sends to the server when intiating STARTTLS, if you are trying to search for it:

 

jdobiash_0-1581649130415.png

 

Hope this helps!

 

Brass Contributor

What I'm coming to believe, is that the "LDAP Signing Summary" chart seems to show that regardless of how the domain is set, i.e. requiring signing or not, if you’re employing local encryption, via GSSAPI, or SSL, the connection will succeed. And is technically encrypted, so satisfies the security requirements, but Microsoft still logs on the domain that the connection was made without signing.

 

Admittedly, that’s not what, I think, everybody expected to happen when you “Require signing” on the domain and you don’t sign on the client. I think we would have expected connections to fail at that point, which is why there's been such fervor around this. But given that GSS-SPNEGO is only available on RHEL 7.2ish + and not on RHEL 6, and likely similarly aged distros, requiring signing, and not allowing that 5th option would have basically broken an entire operating system, or more.

 

I also suspect that Macs are in a similar state. Using the -ssl switch on the dsconfigad utility sets it to “line 4” in the chart, but requires, just like it would for RHEL, additional certificates be made available to every install, which could be prohibitive to make available at scale.  I also suspect that the domain would log an unsigned bind in that case as well. 

I have seen similar commands for dsconfigad like, dsconfigad -packetsign require, but it’s only available in 10.5 and later, which is probably about the time GSS-SPNEGO was added to RHEL 7, I suspect.

 

So when I look in Splunk and have it count the number of unsigned binds across all my domain controllers in the last 24 hours and see a number like 2,518,239. I can’t assume that all those are insecure. What I can’t tell from that is how many of those are using GSSAPI or SSL, because they are logged as unsigned whether they're actually using it or not.

 

Awesome.

Copper Contributor

So I'll start by saying that I've tried reading all the information available on this update since I found out about via Reddit about 3 weeks ago and even with a load of reading it's still feels as clear as mud what will EXACTLY be changing.

 

My understanding so far is:

 

The March 2020 update was GOING to:

  • Enable LDAPChannelBinding by changing the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding to 1
    • Information I found useful about this is here
  • Enable LDAPSigning by changing the
    • DomainControllerPolicy setting 'Domain controller: LDAP server signing requirements' to Require Signing - Registry setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity to 2
    • DefaultDomainPolicy setting 'Network security: LDAP client signing requirements' to Require Signing Registry setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ldap\Parameters\ldapclientintegrity to 2
    • Information I found useful about this is here

Now though that has changed again and nothing will change with existing devices until possibly the 2nd half of the year.

 

To find any devices that are still using an unsupported connection method you can look on the Domain Controllers Event Viewer under 'Directory Service' at event 2887 and this will list the number of connections in the last 24 hours using the unsupported methods. If the event is found you can then can then update HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\16 LDAP Interface Events to a value of 2 and this will log each unsupported connection attempt with more information so it's easier to find the culprits. 

Useful info I found about this is here

Code I found helpful that gets 2887 event info from each DC is here - change the first line to a text file with all your DCs in

$DClist = Get-Content "PATH TO TEXT FILE WITH DC NAMES GOES HERE"
$Hours = 24
$datetime = (Get-Date).tostring('d.M.y-h.m.s')
$creds = Get-Credential


foreach($Computer in $DClist){
    $events = $null
    write-host "Getting events on server $computer"
    $Events = Get-WinEvent -Credential $creds -ComputerName $Computer -FilterHashtable @{Logname='Directory Service';Id=2887; StartTime=(get-date).AddHours("-$Hours")}

    if(!(test-path -Path "C:\Temp\LDAP Bind Info\$datetime")){
        New-Item -Path "C:\Temp\LDAP Bind Info\$datetime" -ItemType Directory
        }
    $events.Message | out-file "C:\Temp\LDAP Bind Info\$datetime\$computer - Event ID 2887.txt"

}

 

 

Is all the above correct? If so then for now there is nothing to worry about but later in the year an update will hit that will change these settings on the DC's and stop the unsupported LDAP connections.

 

I'd like to carry out the hardening work anyway even if the update isn't going to hit but I'm still not sure of the consequences. From what I can understand:

 

  • Enabling LDAPChannelBonding to 'Enabled' (value = 1) will have no impact to clients as it will fall back to supported methods.
    • Enabling LDAPChannelBonding to 'Enabled, always' (value = 2) will break any devices that do not support CBT (Apple MACs seem to be mentioned as not supporting this)
  • Windows Clients default to LDAP Signing 'Negotiate' so as long as a policy isn't setting 'None' anywhere your windows devices will be using signing by default even if the DC is set to none(?)
  • The only setting that could/will break connections seen in the 2887 event is the DC LDAPSigning policy being changed from 'None' to 'Require Signing'

With this, if all LDAP services can be migrated to LDAPS and the 2887 event is no longer listed then enabling the DC LDAP Signing policy to 'Require Signing' will have no effect on current services or devices and will only effect new services brought online that don't use LDAP with signing or LDAPS by default? 

Also we have Apple MACs showing up in the 2887 event but from reading these seem to be set to 'allowed but not required' I've got our MAC specialist to enable signing on the MACs so the 2887 logs are less noisy before I go enabling anything on the DCs. 

Brass Contributor

Can someone please confirm that to implement LDAP Channel Binding changes now (as opposed to waiting for the March and future patch) all we need to do change the following:

 

  • Set BOTH the Network security: LDAP client signing requirements and Domain controller: LDAP server signing requirements settings to Required in the Default Domain Policy and Default Domain Controller Group Policy Objects (GPO).
  • Set LdapEnforceChannelBinding registry key on our domain controllers.


Is this all we need to do and we are good to go? There is nothing else we need to do during March or future patch once this is in place today?

 

In this blog post it states we should enable both settings on both the default domain policy and default domain controller policy, but based on some threads discussion here that is not the case?

Copper Contributor

good introduction at...

 

Understanding LDAP Channel Binding and LDAP Signing Requirements

https://oxfordcomputergroup.com/resources/ldap-channel-binding-signing-requirements/


What is LDAP Channel Binding?
Channel binding is the act of binding the transport layer and application layer together. In the case of LDAP channel binding, the TLS tunnel and the LDAP application layer are being tied together. When these two layers are tied together it creates a unique fingerprint for the LDAP communication. Any interception of the LDAP communications cannot be re-used as this would require establishing a new TLS tunnel which would invalidate the LDAP communication’s unique fingerprint. The LDAP channel binding registry “LdapEnforceChannelBinding” has the following available settings:
(Default) 0 – disabled, no channel binding validation is performed on the domain controllers.
1 – enabled when supported, channel binding is required for windows versions that have been updated to support channel binding tokens (CBT). This allows for compatibility for clients not running a windows version that has been updated to support CBT.
2 – enabled always, channel binding information is required by all client communication with the domain controllers. Clients that do not provide channel binding information will be rejected.
What is LDAP Signing?
LDAP signing is the digital signing of LDAP traffic by the source. The digital signing of LDAP traffic guarantees the authenticity and integrity of the contents of the LDAP traffic has not been altered in transit and allows the receiving party to verify the origin of the LDAP traffic. 

 

Copper Contributor

@amyknight  @jdobiash 

Event 2889 occurs with Unsigned and Signed SASL Bindings over port 389 /3268 (GSSAPI / TLS).  As I understand, there is always one unsigned LDAP SASL Bind (to get the KerbTicket or the certificate), and the DC accepts this. After that, the LDAP SASL Bind can be processed. So even in an environment with Signing set to "required" and all LDAP clients works fine, you will get 2889 events.

From my perspective, this event can only be used to fix clients which make a Unsigned Simple Binds, Binding type in the event is "1". Start to move this clients to SSL over port 636 / 3269.

We have to wait for the March update; the new events may help to analyze the SASL Binds.

Copper Contributor

Hi @Alan La Pietra 

 

Thank you for information.

 

The article says "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."

 

In all Microsoft KBs i still see that March 2020 updates will enable LDAP signing and channel binding.
Do we have an official KB that we can share with the customers, saying there are no changes in March but in the second half of the year"?

 

Thank you

 

Evgeny

Copper Contributor

@Evgeny -- The official advisory ADV190023 was updated about 2 weeks ago. Please refer here --

 

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

Copper Contributor

Hello,

 

The ADV190023 was updated, but below article still states that the hardening will be enforced in March 2020:

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

 

"Microsoft intends to release a security update on Windows Update to enable LDAP channel binding and LDAP signing hardening changes and anticipate this update will be available in March 2020."

 

MSFT should update it as well !.

Brass Contributor

I told a PFE about this early last week.  They don't seem to care that they are continuing to misinform customers.

Microsoft

@Thomas Garrity sorry but this is not quite true. As PFEs we cannot provide information that is not published to the public.

Articles will be update as soon as possible. March update will NOT make any changes so there is no super urgency on this, probably by the end of the month they will be updated.

Copper Contributor

I have a perhaps simplistic question. What I'm curious about are networks which have unsupported OS DCs - 2008/2008 R2 - and client workstations that are either Windows 7 with Extended Support agreements, or newer supported OSs - primarily of course builds of Windows 10.  I'm unclear on how this will affect that type of network, any actual LDAP specific application or other device aside, so solely the Active Directory server and workstation relationships with typical file sharing, DNS, DHCP and so forth as part of a Windows network environment. So later in the year when the update is ultimately released which enforces the LDAP channel binding and signing, and workstations on the network receive this update by being supported and then having it enforced on them, will they be negatively impacted in their ability to communicate to the older DCs which will not be eligible to receive the same update? Will those older DCs have to essentially have the GPO/registry change manually set for them so they can continue to communicate?  This entire conversation is targeted towards prepping ahead for this change and trying to understand its impact, so in a perfect world there wouldn't be a mismatch scenario like this, but I'd still be interested to see whether this scenario would result in issues to be expected or not?  Realistically unsupported OSs or not, this scenario would also be what could happen in an environment when patching occurs effectively nightly on workstations, but on a slower weekly/monthly/etc cadence on servers (again where no preparation ahead was made as suggested to mitigate for this). 

Microsoft

@sms5614 Hi, consider that March 2020 update and also future updates will make NO changes. Customer will decide how to configure these settings.

We recommend to Audit all appliances/applications/devices and third-party OS which are making these types of unsecure connections and fix fix fix.

 

Be sure to read the public Security Advisory and KB that will be updated very very very soon, I know was scheduled last week, but we are there.

 

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...

 

 

Regards

 

 Alan @ PFE

Copper Contributor

Hi @Alan La Pietra,

 

Sorry for asking over and over but, please confirm that i understood you right.

The update that will be released in the second half of 2020 will affect only supported environments:Windows 10, Windows Server 2016, Windows Server 2019

 

Customers which are still using Windows 7 for the end users, and/or Windows Server 2008 for AD, will not be affected at all, and will choose by themselves if to configure binding and LDAP signing or not?

 

Thank you

 

Evgeny

Microsoft

@Egrechin hi, no not correct.

March uodate will not change settings

Future updates will not change settings

 

All supported versions of windows have these settings.

Updates for 7 and 2008R2 I imagine will work, they will receive security updates only if the have ESU

 

Regards

 

Alan @ PFE

Copper Contributor

Are there any details regarding the new CBT signing events 3039, 3040, and 3041 with event source Microsoft-Windows-ActiveDirectory_DomainService in the Directory Service event log?

 

Will these events provide us a means to determine if CBT is being properly used or not?  Currently we can only track unsigned/simble LDAP binds to my knowledge.

Microsoft

@mmcdonaldION 

Hi, public security advisory and KB were updated yesterday with new content

Copper Contributor

This guidamcw doesn't map to the new advisory recommendations. The advisory recommends to require LDAP signing (change registry setting from 1 to 2, or equivalent via GPO) and set the new channel binding registry setting to 1 (so, use if client supports). This says to set CB to 2 (aka enforce).  The content here should either map to the advisory, or state that while the long-term objective should be to enforce CB, near term the recommemdation is just to enable.it.

Microsoft

@dmellc 

Hi thanks for you feedback but the article states the following 

 

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

  • LDAP Channel Binding = 1 

 

Probably is not clearly stated? I will change asap.

 

Recommendation as you said is to have signing enabled and Cbt to when supported. 

But the most secure configuration is to have them both enforced.

 

Regards

 

Alan @ PFE

 

 

Copper Contributor

@Alan La Pietra,

 

If possible, please confirm the following

 

1. LDAPS enforcement update will NOT happen in the future until further notice?

2. If the enforcement is not happening, all companies need to evaluate their own infra and enable LDAPS per the corresponding registry

3. March update will enable CBT token policy WHICH is used in relation with LDAP enforcement enable registry?

4. If a company doesnt evaluate or test their own infra, "it will be vulneralble to attacks" but their system wont have problem because they cant auth?

 

kind regards.

Microsoft

@nyxow 

1. LDAPS enforcement update will NOT happen in the future until further notice?

  • yes, no changes will be made by march 2020 update or future updates 

2. If the enforcement is not happening, all companies need to evaluate their own infra and enable LDAPS per the corresponding registry

  • yes, audit and fix.....then enforce

3. March update will enable CBT token policy WHICH is used in relation with LDAP enforcement enable registry?

4. If a company doesn't evaluate or test their own infra, "it will be vulnerable to attacks" but their system wont have problem because they can't auth?

  • yes, it will be vulnerable, systems will authenticate. But communications are not secure and could be attacked. 

 

Regards

 

Alan

Brass Contributor

@Alan La Pietra

 

Would Microsoft ever consider a way to white list either by machine name or user account if the application doesn't support the more secure logon?   Don't know if there a way to do this in the technology - seems like it would be an all or nothing situation

Copper Contributor

Important: The March 10, 2020 updates, and updates in the foreseeable future, will not change LDAP signing or LDAP channel binding default policies or their registry equivalent on new or existing Active Directory domain controllers.

 

Does this mean, that actually nothing is going to happen? Only couple new event id's are deployed? Am I missing something or is this just misunderstanding and language barrier?

 

-Mikko

Microsoft

@_Mikko you are correct 

Copper Contributor

Is this summary correct?

 

if...  [any other combination]
authentication protocol:SASLbasic 
signed:yesno 
encryption:TLSTLS 
channel binding token (CBT):yesno 
then...   
status:SECUREINSECUREINSECURE

 

Copper Contributor

Ok, thanks for answering. Now based on earlier information we have started configuring our customers AD-environments and we will nevertheless continue that project...

Is there any method to dig correct connections from event log? I mean now we have events for failed connections, but can we somehow log Signed and/or Secured connections? That would help application testing.

 

-Mikko

Copper Contributor

Hi @Alan La Pietra 

Just to be clear and hopefully we can clear out the last concerns :)

1. If the "Domain Controller: LDAP Server Signing" setting already is set to NONE by the "Default Domain Controllers Policy", how will the GPO settings be interpreted after the March 10,  2020 update is installed?

    1.1 Off

    1.2 Required

    1.3 Or is it still None?
2. By default the LdapEnforceChannelBinding registry settings does not exists in the Domain Controllers registry, then what happens?
    2.1. Is it created by the update and set to 0, 1 or 2? (My best guess i no, but not sure)
    2.2 Nothing gets changed in registry and clients are refused and we get an LDAP ERROR 81?

    2.3 The update for the Domain Controller has a hardcoded LdapEnforceChannelBinding setting with the value og 0, 1 or 2?

 


These are our major concerns regarding how to interpret the advisory article and other KB articles referred, and my guess is that it also the same concerns if the majority in the Microsoft community.

What is the mitigation plan?
Stand by and be prepared for the worst case (Have procedures on how to change settings), or just preset the registry keys LdapSigningIntegrity = 0 and LdapEnforceChannelBinding = 0 on all our Domain Controllers?

 

Off course in long term, LDAP Signing and LDAP Channel Binding must be changed to "Required".

 

Best regards
Simon

Copper Contributor

Hi.

 

So, if i querying the Active Directory through SQL server like this :

 

EXEC sp_addlinkedserver 'ADSI', 'Active Directory Services 2.5', 'ADSDSOObject', 'adsdatasource'

 

SELECT *
FROM OPENROWSET
('ADSDSOObject', 'adsdatasource'; 'DOMAIN\username'; 'Password****', 'SELECT name,displayName,telephoneNumber,mail, mobile FROM ''LDAP://DOMAIN:636'' WHERE objectCategory = ''Person'' AND objectClass = ''user'' ' )
AS tblADSI

 

Will that connection be secure since is requesting authentication and is forced to use the port 636?

 

Kind Regards. 

 

Brass Contributor

@Cesar_Limon  I believe it CAN be secure IF the computer where this runs uses Channel Binding Tokens (CBT).

 

TLS (alone) isn't enough against attackers.

Copper Contributor

Not sure about the CBT, however, if none of these options are entirely secure i wonder if Microsoft will release a workaround for it. 

Copper Contributor

For those of us who have things (like Macs) that prevent us from fully enabling CBT, it should be said that in order for someone to actually take advantage of this particular issue, they would have to MITM (Man-in-the-middle) your system, meaning place a device between your domain controller and the endpoint doing the authentication or install some sort of software on the endpoint.  Also, if you have certificate validation enabled (which the Macs require), the attacker would not be able to impersonate the DC, so the connection would fail.   If they somehow had access to your DC's certs, you probably have bigger issues than this.

 

I am going to be satisfied (at least for the time being) with getting all of the traffic encrypted (either via SSL or SASL and setting the server to 'Require') and setting the CBT value set to 1 (vs the full '2').  This ensures that all modern Windows OS's will be secure as well.

Copper Contributor

@jdobiash if the Enterprise Connect feature in macOS Catalina offers Kerberos SSO, does that use secure connections?  Working with a macOS guru to try this now...

Microsoft

@jdobiash Kerberos not impacted, should be secure

Copper Contributor

@Alan La Pietra 

 

thanks for the reply. on the ADV it states that the update wont happen for the forseeable future, but on the public KB it doesnt say anything relating to any future events, just that it wont happen in march of 2020

 

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

 

also the ADV and PublicKB updated dates are a day apart so can you confirm that the statement on the ADV is true?

Copper Contributor

Hello to everyone,
Can you give a very brief summary explanation about this update?
I have Windows 7-8-10 Client and 2008R2 servers in my environment.

* Do I have to take the actions in the article below before applying this update?
"https://astrix.co.uk/news/2020/1/31/how-to-set-up-secure-ldap-for-active-directory"

* Do I have problems between DC and Clients if I don't apply the article?

* First, on which system should I apply this update?

* LDAP Channel Binding and LDAP Signing Requirements

* What steps should I do to configure LDAP Channel Binding and LDAP Signing Requirements. Are the procedures in the article sufficient?

* AD domain name: I have to use "Active Directory Certificate Services" because it is domain.local, right?

Copper Contributor

The advisory mentions GPO and registry, but does anyone know if this will impact the IIS 8 Enhanced Security Settings that are part of the Advanced Settings within Integrated Windows Authentication?  Are they the same thing and will those change upon future update?

 

Many thanks!!

Microsoft

@Joyceee IIS with IWA should not be impacted.

March 2020 release has also an update for IE 

Cumulative security update for Internet Explorer: March 10, 2020

https://support.microsoft.com/en-ca/help/4540671/cumulative-security-update-for-internet-explorer

 

 

 

Microsoft

@ERAY17BG 

March update will make NO changes

* Do I have problems between DC and Clients if I don't apply the article? NO, but your are vulnerable

* First, on which system should I apply this update? ALL SYSTEMS should be updated. This is a monthly update. Regarding these specific settings, changes are made only on DC policy. For 2008 and 7 you need ESU license, see ADV190023 below

* LDAP Channel Binding and LDAP Signing Requirements

* What steps should I do to configure LDAP Channel Binding and LDAP Signing Requirements. Are the procedures in the article sufficient? YES

* AD domain name: I have to use "Active Directory Certificate Services" because it is domain.local, right? What do you mean? You need a certificate if you want to configure LDAPS, and this is preferable/easier to be from your Enterprise CA installed in you domain

 

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

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

 

 

Alan @ PFE

Copper Contributor

Thanks so much Alan for being so responsive!!

I noticed the advisory was updated late Feb with an FAQ, which mentions that .Net apps should not need code changes, but other notes recommend making application updates, so it was a little unclear if .Net apps do indeed need changes or if the framework would handle it once the settings are enforced.  We do not have a separate domain that we can use for testing these settings, so we would either need to make the assumption that .Net apps will be fine with the enforced settings or make code changes to ensure we can test and confirm the secure connections.  Is there a specific recommendation for .Net apps?  While monitoring, we can also see that our SQL Servers are making unsecure ldap connections even though we don't query ldap directly from them.

 

How do clients use SSL/TLS CBT, do I have to change the applications?

Windows applications that are built on .NET Framework, Active Directory Service Interfaces (ADSI), or make LDAP calls into WLDAP32 which handles LDAP signing and channel binding for you. Please contact your SDK equivalent for non- windows device O/S, service, and applications.

Does this mean we have to move all LDAP applications to port 636 and switch to SSL/TLS?

No. When SASL with signing is used, LDAP is more secure over port 389.

Microsoft

@Joyceee 

 

How do clients use SSL/TLS CBT, do I have to change the applications?

Windows applications that are built on .NET Framework, Active Directory Service Interfaces (ADSI), or make LDAP calls into WLDAP32 which handles LDAP signing and channel binding for you. Please contact your SDK equivalent for non- windows device O/S, service, and applications.

Windows applications that are built on .NET Framework, Active Directory Service Interfaces (ADSI), or make LDAP calls into WLDAP32 which handles LDAP signing and channel binding for you

 

Does this mean we have to move all LDAP applications to port 636 and switch to SSL/TLS?

No. When SASL with signing is used, LDAP is more secure over port 389.

SASL Signing is OK. Over port 389 I think it's STARTTLS

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