- Secure domain controllers with LDAP channel binding and LDAP signing - Tue, Jul 13 2021
- Use case for action cards: Send low storage space alert to Microsoft Teams and start WAC to fix the problem - Mon, Jun 21 2021
- Move or migrate WSUS to a new server - Wed, Dec 16 2020
To eliminate this security hole, Microsoft initially wanted to activate LDAP signing and channel binding via an update by default. However, this plan has now been replaced by an explicit recommendation, which can be found in the support document ADV190023.
There are several articles on the internet that compare LDAP signing with LDAP over SSL (LDAPS). However, the latter is a certificate-based protocol that is technically different from LDAP signing.
Although LDAPS also eliminates the risk of a possible man-in-the-middle attack, Microsoft recommends the use of LDAP signing and channel binding instead. The following sections explain the various techniques in detail, including their differences.
Domain controllers and clients are in constant exchange. The LDAP protocol, which communicates via port 389 (TCP and UDP), is primarily used for this purpose. Clients use this protocol to send authentication requests to domain controllers, Exchange servers query mail addresses, and domain admins manage Active Directory via this protocol.
Therefore, it is obvious that LDAP traffic should be encrypted. LDAPS protects the connection by using SSL certificates. It should be noted that the encrypted version does not communicate via port 389, but via 636.
To find out whether connecting via LDAPS is possible, use the tool ldp.exe, which is part of RSAT. First, check whether an unencrypted connection to the server over port 389 is rejected. Communication via LDAPS can be tested on port 636 by checking the SSL box.
The disadvantage of LDAPS is that not all devices are compatible with it. Old telephone systems or legacy applications use LDAP for authentication and do not offer support for communication via SSL.
Furthermore, some administrators who manage small infrastructures and rarely work with servers are not familiar with certificate management and hence would prefer a simpler way of securing LDAP.
Channel binding connects the application layer with the transport layer. This creates a unique fingerprint for LDAP communication.
After a reconnect, which would happen with a man-in-the-middle attack, the previous fingerprint is no longer valid within the new connection.
LDAP signing adds a digital signature to the connection. It ensures the authenticity and integrity of the transmitted data. This means that the recipient can verify the sender and determine whether the data has been manipulated along the way.
The mechanism can be configured via the registry of clients and servers, usually by means of group policy.
LDAP security, as recommended by Microsoft
It is important to follow the correct order when implementing this best practice. First, the clients must be configured to request LDAP signing (i.e., its use is optional).
Once this setting has been set via GPO, you now have to wait until this change affects all clients. Only then can you configure the domain controllers so that they require a signature. Finally, LDAP signing is also enforced on the clients. If you don't adhere to this sequence, then in the worst case no client can log on.
Configuring the clients
Using a new group policy, first change the settings Network security: LDAP client signing requirements.
This can be found under: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.
The option is set to Negotiate signing. Wait until the setting has been applied to all clients.
Adjusting the domain controller
As soon as the change has affected all clients, create another group policy. In the same path as in the previous step, modify the setting Domain controller: LDAP server signing requirements.
There, select the Require signing option. Then, link the GPO to the domain controller container.
Finalizing the clients
If the changes are now also active on the DCs, the group policy from the first step can be adapted so that the clients also require LDAP signing.
The option Network security: LDAP client signing requirements can now simply be changed from Negotiate signing to Require signing.
Activating channel binding
Channel binding is configured on the domain controllers by adding or modifying a corresponding entry in the registry. If it does not already exist, create a new DWORD entry under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters with the description LdapEnforceChannelBinding. The values to be assigned are as follows:
DWORD-Value 0: Disabled
DWORD-Value 1: Enabled, if supported
DWORD-Value 2: Always enabled
In the long term, a value of 2 is recommended, but for the transition phase, the option with a value of 1 can be a good compromise. After the change, the respective domain controller must be restarted.
Since the March 2020 update, the group policy Domain controller: LDAP server channel binding token requirements has been available for this purpose. There, you can choose between the options Never, When supported, and Always.
LDAP signing and channel binding are now active. You can now check this again using LDP.
After successfully connecting using port 389, you can use the bind option (accessible via Connection) to check whether the configuration is working correctly. To do this, select Simple bind and enter the login data of a user.
Subscribe to 4sysops newsletter!
The error message Error <8>: ldap_simple_bind_s() failed: Strong Authentication Required should now appear, confirming successful configuration.