I am trying to create a vulnerable environment to demonstrate how the ADCS ESC8 vulnerability works. For that purpose, I have created a lab that consists of a Windows Server 2016 machine with Active Directory installed. I have also installed and configured ADCS.

I am trying to do an ldapsearch from an external Kali Linux machine, but it doesn´t work. This is the code I use:

ldapsearch -x -H ldaps://192.168.217.131 -D "<dc-user>@emergentes.ad" -w '<password>' -b "DC=emergentes,DC=ad"

I consistently keep getting the following error:

ldap_url_parse_ext(ldaps://WIN-QDH2EF0M0FR.emergentes.ad) ldap_create ldap_url_parse_ext(ldaps://WIN-QDH2EF0M0FR.emergentes.ad:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP WIN-QDH2EF0M0FR.emergentes.ad:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.217.131:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS: peer cert untrusted or revoked (0x42) TLS: can't connect: (unknown error code). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

On the other hand, if I switch to ldap instead of using ldaps, it works. That lead to me thinking: maybe I don't have ldaps correctly configured. It is a good hypothesis, but if I do ldaps://WIN-QDH2EF0M0FR from the domain controller, it works succesfully.

What could be my problem?

I am trying to create a vulnerable environment to demonstrate how the ADCS ESC8 vulnerability works. For that purpose, I have created a lab that consists of a Windows Server 2016 machine with Active Directory installed. I have also installed and configured ADCS.

I am trying to do an ldapsearch from an external Kali Linux machine, but it doesn´t work. This is the code I use:

ldapsearch -x -H ldaps://192.168.217.131 -D "<dc-user>@emergentes.ad" -w '<password>' -b "DC=emergentes,DC=ad"

I consistently keep getting the following error:

ldap_url_parse_ext(ldaps://WIN-QDH2EF0M0FR.emergentes.ad) ldap_create ldap_url_parse_ext(ldaps://WIN-QDH2EF0M0FR.emergentes.ad:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP WIN-QDH2EF0M0FR.emergentes.ad:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.217.131:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS: peer cert untrusted or revoked (0x42) TLS: can't connect: (unknown error code). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

On the other hand, if I switch to ldap instead of using ldaps, it works. That lead to me thinking: maybe I don't have ldaps correctly configured. It is a good hypothesis, but if I do ldaps://WIN-QDH2EF0M0FR from the domain controller, it works succesfully.

What could be my problem?

• active-directory
• ldap

Share Improve this question Follow asked Nov 18, 2024 at 22:12 Ibon Castro LlorenteIbon Castro Llorente 2322 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 0

1. You're testing the connections from two different systems, and you haven't mentioned anything about deploying the AD CS root CA certificate to the external Kali system. Generally, if a TLS client doesn't have the issuing CA "trusted" already, then it doesn't have any means to validate the server's certificate.

   Use the Linux distribution's instructions for installing a CA cert system-wide (e.g. if Kali is Debian-based it might use update-ca-certificates, or if it's Fedora it might use trust anchor <path>).

   Alternatively, specify the CA only for the libldap tools, as documented in man ldap.conf (via system-wide config, or user-level config, or environment variables).

2. You are using different URLs in your ldapsearch example vs "from the domain controller" example. That's a really significant difference for TLS certificate validation, as the certificate's CN/SAN are directly compared against the host name specified in the URL – so the same certificate may be valid for one URL but not for another. (Which is kind of the entire point of TLS certificates!)

   Generally, as well as with AD CS specifically, certificates are issued for host names – not for IP addresses – so the LDAP server's certificate is probably valid only for WIN-QDH2EF0M0FR but not for 192.168.217.131, and depending on AD CS configuration it might or might not be valid for WIN-QDH2EF0M0FR.emergentes.ad; look at the actual certificate to find out.

   (Not to mention that with TLS SNI, the client might even receive an entirely different certificate depending on what host name it requests from the server. I don't think AD LDAP uses SNI, but still.)

Usually libldap uses either OpenSSL or GnuTLS, so run a manual TLS connection to get more information:

• gnutls-cli SERVER -p PORT

• openssl s_client -connect SERVER:PORT -verify_hostname SERVER -status

  (I think in latest OpenSSL openssl s_client -connect SERVER:PORT -status might suffice, but older versions definitely needed -verify_hostname to be given manually.)