Microsoft Official Sources, Security Advisory, Requirements, FAQ and other useful sources are included at the bottom of this page - Microsoft Security Advisory.
Microsoft has identified that the default Domain Controller configuration is vulnerable to "man-in-the-middle attacks" when using authentication without SSL and without signing.
Microsoft is releasing updates that will automatically harden the default configuration to make sure that the "man-in-the-middle attacks" are no longer possible, but these changes may disrupt services or systems which connect to the Domain Controllers if they are incapable or don't support signing or encryption.
If a client today connects to the Domain Controller via LDAP and logs on, they can change settings over LDAP within the scope of their authorizations. If this communication is not encrypted or signed, a "bad actor" can put themselves in the middle of this exchange and rewrite any queries/commands via a man-in-the-middle attack.
- An admin or a privileged user connects to the Domain Controller and adds a user to a group using LDAP.
- The attacker rewrites the command so that his user is included in the group of domain administrators along with this change.
- The attacker now has control of the Domain Controller.
The best way to prevent this is through consistently encrypted and signed connections via LDAP over SSL. Although this is the most secure configuration, you can use unencrypted connections without SSL as long as you use "signing". All Windows clients do this, but not all LDAP clients do this.
Interact supports the upcoming changes but you may need to adjust your configuration, please continue reading to find out more.
If you were required to update your Domain Controllers but have not updated your Interact Configuration, you might experience failed connectivity between Interact and your Domain Controllers due to Security misconfigurations.
The following might occur:
- Profile Source connections to On-Premise Active Directories or LDAP sources might stop working.
- This might result in failed user profile syncs - joiners, movers and leavers process stops working.
- LDAP based authentication might stop working.
- Users may no longer be able to log in to the Intranet as the system may no longer be able to connect to your on-prem AD to check the user's credentials.
Interact natively supports signed and encrypted LDAP connections, so you can proactively get ahead of the update schedule and adjust the configuration and ensure it's more secure.
Since the LDAP Signing and LDAP Channel Binding changes affect supported authentication options, specifically unencrypted Simple Auth and unencrypted unsigned SASL Auth, so you may need to adjust your Interact settings to be compatible with the upcoming hardened configurations.
Interact currently provides three authentication types:
Depending on the used authentication type, you may be affected in different ways. Please see below based on your current Profile Source configuration.
NOTE: If you're already using encrypted (SSL/TLS) or signed connections to your Domain Controllers, then you don't need to make any changes.
Due to the nature of Simple Bind, it is quite insecure and cannot be signed, therefore unless it's sent over an encrypted medium (SSL/TLS) it will be rejected by the Active Domain Controllers with the new hardened settings which now will require signed binds.
Anyone using Simple Bind over port 389 (non-SSL) will need to either upgrade to Simple Bind over SSL/TLS or use Negotiate Authentication Type (SASL) (works with and without SSL as long as LDAP signing is enabled.)
SASL binds support signing and encryption so they're more secure than Simple Binds when sent over an unencrypted medium (non-SSL/TLS) which means once required signing is applied to the Domain Controllers, SASL can still be used with supported applications over port 389.
Customers using Negotiate Authentication Type will be unaffected as Interact supports both Signed and Unsigned variants meaning it will adjust as your Active Directory Controller configuration changes - it will negotiate the more secure protocol.
Upgrading your profile source connectivity to SSL should resolve any connectivity issues resulting from the hardening settings.
- Use the "Fully Qualified Domain Name" of the Domain Controller (instead of IP address) when upgrading to SSL - the certificate will need to be valid for that Domain Name.
- Issue an SSL Certificate from a Public Certificate Authority and install it on your Domain Controller
- Common Issues: https://support.microsoft.com/en-gb/help/938703/how-to-troubleshoot-ldap-over-ssl-connection-problems
- eg. The Active Directory fully qualified domain name of the domain controller appears in one of the following locations:
- The common name (CN) in the Subject field
The Subject Alternative Name (SAN) extension in the DNS entry
- The common name (CN) in the Subject field
- Self-signed certificates require the "Override SSL Certificate Verification" setting to be enabled on your Profile Source.
- Open 636 in your Firewall to allow the new secure traffic - Interact's outbound IP addresses will remain the same.
Before Hardening: No LDAP Channel Binding & No LDAP Signing
After Hardening: LDAP Channel Binding & LDAP Signing
|Auth Type||Port||Before Hardening||After Hardening|
On 13th August 2019, Microsoft has published the ADV190023 Security Advisory stating that when the default Active Directory configurations are used, an elevation of privilege vulnerability exists in Microsoft Windows that could allow a man-in-the-middle attacker to successfully forward an authentication request to a Windows LDAP server, such as a system running AD DS, which has not configured to require channel binding, and signing or sealing on incoming connections.
There have been no reported exploitations of this vulnerability at the time of writing.
The resolution proposed by Microsoft requires setting the following.
|Domain controller: LDAP server channel binding token requirements||Always|
|Domain controller: LDAP server signing requirements||Require Signing|
|Network security: LDAP client signing requirements||Require Signing|
Important: The March 10, 2020 and updates in the foreseeable future will not make changes to LDAP signing or LDAP channel binding policies or their registry equivalent on new or existing domain controllers.
All customers should be evaluating and preparing to harden their configuration as soon as possible.
Microsoft is planning to automatically apply the hardened LDAP settings in Autumn 2020, so you need to make sure you're ready or you might experience widespread outages due to incompatibilities across your systems, networks and third-party providers.
We have compiled a list of relevant pages and guides to aid you in this process.
This policy setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to negotiate data signing.
- This setting does not have any impact on LDAP simple bind through SSL (LDAP TCP/636).
- If signing is required, then LDAP simple binds not using SSL are rejected (LDAP TCP/389).
Caution: If you set the server to Require signature, you must also set the client device. Not setting the client device results in loss of connection with the server."
This policy setting determines the level of data signing that is requested on behalf of client devices that issue LDAP BIND requests. The levels of data signing are described in the following list:
- None. The LDAP BIND request is issued with the caller-specified options.
- 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 caller-specified options. If TLS/SSL has been started, the LDAP BIND request is initiated with the caller-specified options.
- Require signing. This level 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 returned a message that the LDAP BIND command request failed.
Misuse of this policy setting is a common error that can cause data loss or problems with data access or security."
Updated over 3 years ago