Enable LDAP Channel Binding and LDAP Siging

[SteveDW]

Hello, If I understand correctly, Microsoft Active Directory requires LDAP Channel Binding to be enabled and LDAP Signing to be activated before using the Directory Sync SSL or StartTLS transport. Should the Windows Server Certificate Authority or the stand-alone Certificate Services be used for this to activate the encrypted SSL/STARTTLS transport? My current configuration is using the RADIUS proxy server as a member server of an Active Directory domain and using clear transport.

[DuoKristina]

What Duo product are you trying to bind to AD?

Generally, the Authentication Proxy just needs you to provide it the CA chain so that it can verify the certificate presented by the LDAP server when it tries to connect. The Authentication Proxy does not care about what kind of CA it is, just that it has the chain available to verify.

So, with AD Sync as an example, during AD Sync config if you choose LDAPS transport there is a box in the config page in the Duo Admin Panel where you will paste in your CA chain (in PEM format).

Microsoft walked back their plan to enforce LDAP channel binding and signing in 2020 so it’s still optional (configurable via registry).

Note that channel binding support requires Duo Authentication proxy v5 or later.

These articles may help:

Does the Authentication Proxy support LDAP channel binding?
Does the Duo Authentication Proxy support “Sign and Seal”?
Why do I receive an LDAP bind error when configuring Active Directory sync to use LDAPS or STARTTLS with channel binding validation enabled on a domain controller?

[SteveDW]

Thank you for the information. I’m using the Duo Authentication Proxy Manager for the Cisco AnyConnect Client VPN via a Meraki MX250. It’s up and running on two different networks.

I would have preferred to have invoked the encrypted transport, but I had issues when attempting to apply my certificate when initially configuring the AD sync. It did not work with the PEM syntax. Due to time constraints, I had to opt for my proxy server to use the “integrated” authentication type on a Windows server with clear transport. Is it possible to continue using the integrated authentication type with either the LDAPS or STARTTLS transport type and without LDAP channel binding?

I tried unsuccessfully to connect using SSL/STARTTLS transport when initially setting up the server. The PEM formatted syntax was entered into the SSL CA certs field (in between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----). I opened the .cer to obtain the PEM syntax. The acert.exe app produced the same syntax that was in the xxxxxxx.cer file. Is it suggested that I check the “SSL Verify Hostname” box? Do I need to place quotes within the ssl_ca_certs_file=C:\Program Files\Duo Security Authentication Proxy\conf\xxxxx.cer path?

DuoKristina, I really appreciate your insight.

[DuoKristina]

The Duo Authentication Proxy defers to the domain controller while using SSPI. If the domain controller requires channel binding and the proxy config can do it, then it will.

Regarding your other issues with SSL and the cert…

• checking “SSL Verify Hostname” means it will compare the hostname of the domain controller provided by you in the config to the issued-to name in the certificate. If they do not match, the SSL connection won’t be established. If “SSL Verify Hostname” isn’t checked, then it doesn’t do that check, so wouldn’t fail to establish the SSL connection due to a hostname mismatch.

• you do not need to put quotes around the path to the ssl_ca_certs_file. In fact, it supports paths relative to the Authentication Proxy’s conf directory, so if you have your PEM cert file in conf you could put ssl_ca_certs=mycert.cer.

If you enable debug logging for the proxy (add debug=true to the [main] section of authproxy.cfg and cycle), it should give you a reason why it couldn’t establish the ssl connection. Like, if the issue was hostname validation the OpenSSL error says something like “could not verify hostname”, etc.

One common reason it might fail is if the certificate file specified for ssl_ca_certs is the leaf certificate, and not the root or roots in the issuing chain. The Duo proxy does not need the cert issued to the domain controller. It needs the chain that issued the cert to the domain controller (it will not read the roots from the machine store i.e. trusted roots seen in certlm.msc).

The exception to this is if the domain controller is using a self-signed cert for SSL, in which case the ssl_ca_certs file should contain that self-signed cert, and also the key usage must include “Certificate Signing”.

Hope that helps!