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
Could someone PLEASE help me understand something? If I set the server to require signing, but a client is offline and can't yet get the client gpo to set required signing - how in the world can it talk with a DC to get group policy to get the right setting? Is there some sort of special logic happening on a DC that allows a client to check/update group policy even if it isn't meeting the signing requirements???
Copper Contributor

What happens if the clients receive the January 2020 update before the domain controllers do? In other words, the DCs have a Registry entry of 0 or no entry at all.

Copper Contributor
Thanks for this clarification!
As i understand, this should work for good Compatibility:
Before January 2020 Update:
- Install all required Updates
- All DCs: Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2
- All DCs: Monitor 2887 and 2889 Events
- All DCs: LDAP Channel Binding = 1
- Group Policy (Domain Level): Network security: LDAP client signing requirements: Require
- Group Policy (Domaincontrollers): Domain controller: LDAP server signing requirements: None
About Domain controller signing:
None: Data signing is not required in order to bind with the server. If the client requests data signing, the server supports it.
Require signature: Unless TLS\SSL is being used, the LDAP data signing option must be negotiated.
Caution
If you set the server to Require Signature, you must also set the client. Not setting the client results in loss of connection with the server.
 
After January 2020 Update:
- Domain controller: LDAP server signing requirements: Require (from Update)
- All DCs: LDAP Channel Binding = 1 (from Update)
- All DCs: Monitor 2888 Events
 
If Problems:
- Domain controller: LDAP server signing requirements: None
- All DCs: Monitor 2887 and 2889 Events
 
If all should be good:
- Network security: LDAP client signing requirements: Require
- Domain controller: LDAP server signing requirements: Require
- LDAP Channel Binding = 2

Other suggestions?
Copper Contributor

Does anyone know (for sure) if there will be the option to keep the enforcment disabled after the January patch?

If yes, then please provide source..

Microsoft
@ajm-b  

Domain controller: LDAP server signing requirements

This security setting determines whether the LDAP server requires signing to be negotiated with LDAP clients, as follows:

None: Data signing is not required in order to bind with the server. If the client requests data signing, the server supports it.
Require signature: Unless TLS\SSL is being used, the LDAP data signing option must be negotiated.

Default: This policy is not defined, which has the same effect as None.

Caution

If you set the server to Require Signature, you must also set the client. Not setting the client results in loss of connection with the server.

Notes

This setting does not have any impact on LDAP simple bind or LDAP simple bind through SSL. No Microsoft LDAP clients that are shipped with Windows XP Professional use LDAP simple bind or LDAP simple bind through SSL to talk to a domain controller.
If signing is required, then LDAP simple bind and LDAP simple bind through SSL requests are rejected. No Microsoft LDAP clients running Windows XP Professional or the Windows Server 2003 family use LDAP simple bind or LDAP simple bind through SSL to bind to directory service

 

Network security: LDAP client signing requirements

This security setting determines the level of data signing that is requested on behalf of clients issuing LDAP BIND requests, as follows:

None: The LDAP BIND request is issued with the options that are specified by the caller.
Negotiate signing: If Transport Layer Security/Secure Sockets Layer (TLS\SSL) has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the options specified by the caller. If TLS\SSL has been started, the LDAP BIND request is initiated with the options that are specified by the caller.
Require signature: This is the same as Negotiate signing. However, if the LDAP server's intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is told that the LDAP BIND command request failed.

Caution

If you set the server to Require signature, you must also set the client. Not setting the client results in a loss of connection with the server.

Note: This setting does not have any impact on ldap_simple_bind or ldap_simple_bind_s. No Microsoft LDAP clients that are shipped with Windows XP Professional use ldap_simple_bind or ldap_simple_bind_s to talk to a domain controller.

Default: Negotiate signing.

Microsoft
Microsoft

@GflBE

I would say

Before January 2020 Update:
- Install all required Updates
- All DCs: Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2
- All DCs: Monitor 2887 and 2889 Events
- All DCs: LDAP Channel Binding = 1 (Before Jan 2020 updates this setting is 0)
- Group Policy (Domain Level): Network security: LDAP client signing requirements: None (Before Jan 2020 updates this setting is Negotiate Signing)
- Group Policy (Domaincontrollers): Domain controller: LDAP server signing requirements: None

 

After January 2020 Update:
- Domain controller: LDAP server signing requirements: Require (from Update)
- All DCs: LDAP Channel Binding = 1 (from Update)
- All DCs: Monitor 2888 Events
 
If Problems:
- Domain controller: LDAP server signing requirements: None
- All DCs: Monitor 2887 and 2889 Events
 
If all should be good:
- Network security: LDAP client signing requirements: Require
- Domain controller: LDAP server signing requirements: Require
- LDAP Channel Binding = 2
Copper Contributor

@Alan La Pietra 

Okay i have already seen that article and the registry values to accept non signed ldap requests. But to me it was not definetly clear if this option will still be available after the January update.

 

Can you confirm that it will be possible after the january update?

 

Thanks in advance!

Microsoft

@harle22 changes can be reverted, only changing default values

 

Copper Contributor

This article and the conversation that it has started has been very helpful, so thanks for that.

 

Fortunately I have a copy of our AD in a sandboxed environment for testing. The downside is that I only have Windows Clients and no third party apps to test there.

 

A couple of different points:

 

- In the test environment, I set LDAP Signing to be enforced on the Client side across the domain and set the DC GPO so that LDAP Signing is not required. This apparently did not cause any problems. It seems to contradict this, unless I'm misunderstanding it: "Require signature: This is the same as Negotiate signing. However, if the LDAP server's intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is told that the LDAP BIND command request failed."

 

- This concerns me: "If signing is required, then LDAP simple bind and LDAP simple bind through SSL requests are rejected. " Is this correct? If so, we can forget about 3rd party apps that need to use AD authentication. They all seem to rely on simple bind over SSL for LDAP security.

Copper Contributor

@CFS3RD 

 

SASL Authentication 

 

Active Directory supports the optional use of integrity verification or encryption that is negotiated as part of the SASL authentication.
While Active Directory permits SASL binds to be performed on an SSL/TLS-protected connection, it does not permit the use of SASL-layer encryption/integrity verification mechanisms on such a connection.
While this restriction is present in Active Directory on Windows 2000 Server operating system and later, versions prior to Windows Server 2008 operating system can fail to reject an LDAP bind
that is requesting SASL-layer encryption/integrity verification mechanisms when that bind request is sent on a SSL/TLS-protected connection.

Copper Contributor

Can you confirm that it will be possible after the january update?

Real Web Point

Thanks in advance!

Brass Contributor
@Alan La Pietra The KB 968389 link doesn't work. Can you get this link corrected or point us to the correct verbiage? This is causing quite a bit of confusion of us as well. -Chad
Microsoft

@ChadWst sorry for that!!

2008 x64: https://www.microsoft.com/en-us/download/details.aspx?id=15109 

Check windows update catalog here: https://www.catalog.update.microsoft.com/Home.aspx

 

Also remember that Extended Support for 2008 R2 SP1 and 2008 SP2, will end on 1/14/2020

Search product lifecycle: https://support.microsoft.com/en-us/lifecycle/search?alpha=windows%20server%202008

 

Regards

 

Alan @ PFE

Microsoft
 
 
 
   
Yes it will

 

Brass Contributor

@Alan La Pietra-- Question about GPO's  if LDAP Signing GPO's are currently enforcing "Negotiate Signing" for  Client/Workstations and LDAP Signing set to "None" for Domain Controllers

 

The January update would have no impact right? The update would essentially set it in the registry to "Require Signing" but once Group Policy refreshed it would revert back to what is set in GPO for example "Negotiate" for Clients and "None" for Domain Controllers.

Copper Contributor

For our third party applications and our OSX member computers that use LDAP over SSL (port 636), will they continue to communicate successfully with the domain controllers set to Require Signing? It sounds like they will fail. In that case we'll never be able to set it to Require Signing.

 

Related, I assume that for Channel Binding as long as we leave the setting at 1, the third part apps will be okay, since that is leaving it unenforced. Is that correct?

Brass Contributor
@CFS3RD, as I understand it "Require Signing" only has to do with non-TLS 389, it doesn't come into play with 636 binds. We have plenty of macs here - if you wanna hit me up in about a month I can probably tell you how it went.
Copper Contributor

ajm-b, yes that would be great. We'll be holding off on the domain controllers until February so I'll have some time. We do have a closed off test network and we may be able to test some Macs there.

 

I don't know too much about Macs and I'm never one who joins them to the domain, but I had been under the impression that they did use port 636 by default. It wasn't until I increased the LDAP logging to "2" that I saw how many of them were using 389. I'm not sure why, but you may want to do the same.

 

That said, I just found an article that allays the confusion which prompted me to ask the question in the first place:

http://setspn.blogspot.com/2016/09/domain-controller-ldap-server-signing.html

As the article says, there is bad wording in the MS article: "If signing is required, then LDAP simple bind and LDAP simple bind through SSL requests are rejected." So I know from what it says in this Blogspot post, that LDAP over SSL/TLS should continue to work.

 

Copper Contributor

I was able to find a Mac that I put in our isolated test network. In that environment, I set the DC GPO for "Domain Controller: require signing", the domain GPO to "Network Client: require signing". On the DC GPO I created the Registry entry for "LDAP Channel Binding = 1". I successfully tested using LDP to make sure simple binds over 389 would fail and over 636 using SSL would succeed.

 

I had no problem joining the Mac (Mavericks, a fairly old OSX version) to the domain. I don't see an option for using secure LDAP or not, so it obviously used secure LDAP or it would have failed. Just wanted to get this out there for anyone who was concerned like me.

 

I still don't understand why a bunch of Macs are using non secure LDAP, but that's our problem to correct.

Copper Contributor

You can use ldp.exe to quickly troubleshoot difference settings.  It helped me solve an issue with a Cisco appliance today.

Brass Contributor

@Alan La Pietra

 

Excellent article - thank you.

This may be asking something obvious but do the updates amend the value of Domain controller: LDAP server signing requirements in the Default Domain Controllers Policy?

Microsoft

@Ricoli610

Correct

Signing Required

CBT = 1

 

you need to have "required" on both Domain Controller Policy and Domain Policy (or a policy that will apply to clients/servers).

Update will default to ldap signing required on DDCP

 

Alan @ PFE

 

 

Brass Contributor
@Alan La Pietra -- I have a question related to the CVE-2017-8563 Would it be safe to assume that if we have been applying the Monthly Roll-up (not the Security-Only) since Oct 2016 to all of our systems, that this would include the update needed? -Chad
Microsoft

@ChadWst

I assume you are correct, but you can double check

Please review the following: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8563

 

Example "Windows 10 for 32-bit Systems" is contained in July 11, 2017 - KB4025338

Windows 10 for 32-bit Systems   4025338 Security Update

 

or for "Windows Server 2012 R2" - KB4025333

Windows Server 2012 R2   4025336 Monthly Rollup Elevation of Privilege Important
4022726
4025333 Security Only

 

Regards

 

Alan @ PFE

Copper Contributor

Horrible article...

 

Does the update involve code updates?

Does the update merely set the registry keys?

Does the update update a GPO (you allude to this above but I find it hard to believe.. - maybe I deleted the Default Domain Controllers GPO.. changed its scope… the patching team DONT have access to modify GPOs anyway... This is stupid on so many levels it has to not be the case)

Does the registry setting set by the patch (if thats all it does) override GPO registry settings (assuming the normal 'policies' folders are used for these types of GPOs..) which wins? what if there is a conflict?

 

Poorly explained and massive lack of fundamental information.

Brass Contributor
@Alan La Pietra If we set LDAP Channel Binding = 0 before the January update is deployed, will the update change the value from 0 to 1 or will customers need to come back after the update and reset it to =0 to disabling it? Please advise and thank you!
Microsoft

@ChadWst The update will change to 1 in DDCpolicy. You will have to set back to 0.

 

After installing ADV190023 both settings (even None and Not Defined) will enforce Require Signature.
Only 0 (OFF) will not enforce Require Signature.

 

By the way with CBT=1 you shouldn't have issues, that's a sort of accept all. This is an intermediate option that allows for application compatibility.

Issue could arise with LDAP Signing=Require

 

Brass Contributor
@Alan La Pietra -- Good catch on the future updates. I wasn't thinking that far in advance yet :) -- Speaking of updates. Do you anticipate these changes being in the Preview Updates?
Microsoft

@ChadWst sorry not aware of this yet

Brass Contributor

Thanks very much!

Brass Contributor
@Alan La Pietra -- Another follow-up to your response. Up til this point I have considered LDAP signing and LDAP CBT mutually exclusive. Is this accurate? For example, could we disable LDAP signing=REQUIRED and move forward with CBT = 1? These changes dont have to be done together right?
Microsoft

Adding some other information

 

Important to point out:

LDAP over TLS/SSL communication are already signed as TLS would detect any modification of the payload as it can't be decrypted. The behavior for LDAP simple binds and LDAP simple binds through SSL are as follows:

  • LDAP simple binds are rejected If signing is required
  • LDAP simple binds through SSL are allowed If signing is required​ as that satisfy the signing requirement 

 

Another important aspect:
Turning off changes made by January 2020 updates 
Separate registry key settings exist for LDAP Signing and Channel Binding. Setting registry values to zero reverts the OS back to the previous defaults:​
  • LdapServerIntegrity = 0​
  • LdapEnforceChannelBinding = 0​​
The values can also be configured via Security Policies set via Group Policy (e.g. to automatically distribute the settings to all DCs):​
  • "Domain controller: LDAP server signing requirements"​
  • "Domain controller: LDAP server channel binding token requirements" (will only show up in the UI after installing the upcoming fix)​

@ChadWst 

CBT setting will be introduced by the update

You can separate the settings, having CBT=1 and Signing=0. They are two separate settings that you can configure via registry or GPO

Also if you download the latest SCT 1.0 (security compliance toolkit) https://www.microsoft.com/en-us/download/details.aspx?id=55319 you will find template "SecGuide.admx" and language file "SecGuide.adml" that you can import in your policies (Central Store or C:\Windows\PolicyDefinitions) and from which you can manage Extended Protection for LDAP.....(CBT)

clipboard_image_1.png

Security baseline (FINAL) for Windows 10 v1909 and Windows Server v1909: 

 

https://techcommunity.microsoft.com/t5/Microsoft-Security-Baselines/Security-baseline-FINAL-for-Wind... 

 

Also one of the things to be aware of is that "Require Signing" may have an impact on third-party systems if you don't configure them correctly. Some examples that I'm thinking of:

  • Printers
  • Storage Area Networks
  • Third party OSs
  • Appliances
  • other Hardware that interacts with DCs
  • etc etc

 

Regards

 

Alan @ PFE

 

Brass Contributor

@Alan La Pietra @ChadWst 

Thank you for all the additional information and links.

Just flagging up that I've tried changing the Domain controller: LDAP server signing requirements setting in the DDCP from None to Required and this changed the ldapserverintegrity registry entry from 1 to 2 (below HKLM\System\CurrentControlSet\Services\NTDS\Parameters). Reverting the policy setting to None changed it back to 1.

Copper Contributor

@Ricoli610

My tests confirm your remarks:

DC: LDAP server signing requirement: None (default) means ldapserverintegrity registry value 1
DC: LDAP server signing requirement: Required means ldapserverintegrity registry value 2

(and not 0 and 1 as expected, which is confusing)

 

This would mean that the previous remark from @Alan La Pietra should be:

 

Turning off changes made by January 2020 updates 
Separate registry key settings exist for LDAP Signing and Channel Binding. Setting registry values to zero reverts the OS back to the previous defaults:​
  • LdapServerIntegrity = 1 (which means ldap server signing requirement none)
  • LdapEnforceChannelBinding = 0​​ (which means binding disabled)

Thank you @Alan La Pietra for confirming this.

Microsoft

@romuel Great!!

Copper Contributor

For those with Macs, it looks like they do not support CBT (Channel Binding Tokens) so it won't be possible to set LdapEnforceChannelBinding to 2, but it does work with it set to 1 (Compatibility Mode).   I'm guessing most people will have to stay in that mode anyway, due to an assortment of 3rd party things.   This was tested using the latest macOS (10.15) as well.

Copper Contributor

If there is a requirement to secure the binding with a certificate, either internal CA or third party CA, and the domain ends in .local, is it possible to obtain a certificate from a third party CA for a upn suffix that is available externally and use this instead to bind securely? Deploying an internal CA for many customers who have .local domains to allow successful ldap binds seems like an overkill. Thoughts?

 

Just a thought - I think based on the many comments and corrections, this article should be updated with clear instructions on the changes being made, how to enable such settings now, how to disable such settings when live etc. A lot of companies won't be ready for the January deadline, so a guide to ensuring smooth transition would be great.

Copper Contributor

Hi @Alan La Pietra,

 

One question here, according to the 2 documents here:

Can I just follow one doc to make my communications between LDAP clients and Active Directory domain controllers more secure? Or I must configure both the 2 to get this advantages. What's the different them, please?

 

Thanks

-Justin 

Microsoft

@Justin_Shi Hi Justin, you can go with only one but to cover all security concerns related to this issue we recommend to change both. Also because the update will update both.

Channel Binding Token info (was FAQ): https://internal.support.services.microsoft.com/en-us/help/2022970

Channel Binding for TLS (ietf) : https://tools.ietf.org/html/draft-altman-tls-channel-bindings-07#page-6

 

CVE-2017-8563 introduces a registry setting that administrators can use to help make LDAP authentication over SSL/TLS more secure.

  • 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

 

Regards

 

Alan @ PFE

Microsoft

Also, just as an example, once you have enabled auditing modifying registry key "16 LDAP Interface Events", you can use the following powershell to search every DC for EventID 2889 and list IP and Account

 

This is only an example (only the last 50 events will be listed, if you need more change the value in -maxevents)

$DCs=Get-ADDomainController -filter *
foreach ($DC in $DCs)
{
write-host $DC.hostname
get-winevent -computername $DC -logname "directory Service" -maxevents 50 | ?{$_.id -eq 2889}|%{Write-Output "$($_.timecreated): $($_.properties[0].value)=>$($_.properties[1].value)"}

Copper Contributor

Thanks, the script is helpful.

 

I was confused as to why I saw no events listed on 4 of 5 DCs until I realized that (of course) the last 50 events are listed *before* filtering for Event ID 2889. If you have lots of other Directory Services events, the last 50 may not include any for Event ID 2889. Keep that in mind when running the script.

Brass Contributor
@Alan La Pietra Do you know if the LDAP Signing registry keys are dynamic like the CBT keys?? Is a reboot required for those to take effect? HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters LDAPServerIntegrity HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ldap\Parameters ldapclientintegrity
Brass Contributor

@Alan La Pietra,

 

Please make it clearer in the article, that the table that explains behavior change is actually about "Domain controller: LDAP server signing requirements" GPO. It was not evident at all, until I read all other comments. Possibly, because GPO doesn't contain "OFF" setting.

 

Is it correct, that after this update, if we want to have at least 1 application not using LDAP Signing, we have to remove this GPO setting completely, and create a registry key with value "0", completely turning off LDAP Signing in whole domain, for all clients? If not, how do we enable one application to not require LDAP signing (given it doesn't support LDAPS)?

 

Below is the description of the policy today. Why does it say that LDAP Simple Bind is not affected?

Domain controller: LDAP server signing requirements

 

This security setting determines whether the LDAP server requires signing to be negotiated with LDAP clients, as follows:

None: Data signing is not required in order to bind with the server. If the client requests data signing, the server supports it.
Require signature: Unless TLS\SSL is being used, the LDAP data signing option must be negotiated.

Default: This policy is not defined, which has the same effect as None.

Caution

If you set the server to Require Signature, you must also set the client. Not setting the client results in loss of connection with the server.

Notes

This setting does not have any impact on LDAP simple bind or LDAP simple bind through SSL. No Microsoft LDAP clients that are shipped with Windows XP Professional use LDAP simple

Brass Contributor
@Alan La Pietra If LDAPServerIntegrity = 0 on the Domain Controller side does the client side ldapclientintegrity need to be "0" as well or would "1" Negotiate still work? Thanks for the updated info and charts related to the "None" and "Not Defined" behavior. This helps for the customers that are working on plans to disabled. It might help to add some verbiage around the client side.
Microsoft

@ChadWst

LDAPServerIntegrity = 0 on the Domain Controller side , this will remain 0 when you install update (releasing in March 2020)

Client Side leave = 1 meaning "negotiate"

 

So to disable this LDAP Signing you have to set Domain Controller Policy to 0 (zero = OFF). This wont be touched by the March 2020 update or future updates. I want to point out that this is NOT Recommended obviously as you are leaving your environment not secure.

LDAP CBT is not a concern with March 2020 update. Leaving = 1 means "negotiate".

When possible, consider configuring CBT = 2 in order to ensure higher security for TLS as well

 

Alan @ PFE

Copper Contributor

@ChadWst 

According to the help for Client Signing Requirements, Negotiate is the default.

 

That said, I have a GPO set for a few clients with Client Signing set to "2" (Require Signing) and I have no issues, even though the DCs are still set to None.

Brass Contributor
@Alan La Pietra -- Most definitely, the plan is to get these features enabled however we haven't had another lead time to get the logging enabled and run down the 1000's of LDAP client apps we have. Its definitely on our radar. A couple of followups 1 -- Are you hinting that the updates might be pushed to March (would look at the official Advisory for this soon)? 2 -- For LDAP Clients... The 2020 updates will NOT change the "Negotiate" to "Required"? or is it irrelevant if the DC/LDAP server side is set to "0"
Brass Contributor
@CFS3RD -- Thats what we have been testing but it looks like the behavior of "1" or "None" changes with the updates. Check out Alan's updates in the main part of the thread.
Brass Contributor

Hello @Alan La Pietra 

 

The policy "Domain controller: LDAP server signing requirements" contains only settings "None" and "Require Signing". So if we need to set the policy to OFF, one of the way would be to set this setting in Group Policy to "Not Defined" and then specify the registry key in GP Preferences, with value 0?

 

What is the effect when LDAPServerIntegrity=0, if Client is configured to Require Signing? Will they not be able to communicate, or will Domain Controller accept signed traffic, even if signing is OFF?

 

Current description of this policy says that "This setting does not have any impact on LDAP simple bind or LDAP simple bind through SSL." It would be nice if the description is corrected to match the information you provided.

 

Have my previous commented been deleted for the red text, highlighting wrong description on GPO? Wow!

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