Does the enterprise connection support AD LDS?

I see enterprise connection supports Active Directory / LDAP. I am wondering if it supports AD LDS. I tried to set up one for validation. I created the connection, download the installation, and installed it on a server behind our firewall. During the configuration, I got an error: “Cannot bind to LDAP”. Is that mean it does not support AD LDS?

Hi @johnxjcheng

I don’t know, but I think it should be.

Can you give more details about the error? It sounds like it cannot find the AD instance, is it there and listening on the LDAP connection string?

The docs say that string refers to a domain controller, that could possibly be the issue. But first, make sure that string (and the associated username/password) is correct.

Do you see any entries in the AD LDS logs?

John

Hi john gateley,

This is not an AD, but a clustered AD LDS servers that are behind a load balancer. On the same machine where I am configuring the AD LDAP Connector, I can use another tool, Active Directory Explorer tool, to connect with the server without issue. I tried to use either the load balancer’s FQDN, or the server’s FQDN for the Connector. They both show errors but are different. Below are the results:

Usering load balance:

Directly connect to the server:

Thanks,
John Cheng

Hi @johnxjcheng

In both cases, you can connect to the AD LDS instance, but it is failing. The second one, connection reset, could be a firewall or the load balancer rejecting the connection. For the first, can you check the logs on the AD LDS servers? They may be able to tell you more.

John

Hi john.gateley,

I used Wireshark to monitor the network communication generated by the Auth0 AD LDAP Connector, and by the ADSI Edit (a Microsoft AD tool). The first picture shows the traffic from ADSI that is filtered by the source and destination IP address: 10.41.109.9, which is the IP of our AD LDS load balancer. The second picture shows the traffic from the Auth0 AD LDAP Connector. The second one is much shorter. That’s because the communication was stopped. One obvious difference to me is that the Connector does not show secure communication: TLSv1.2. I did give it fqdn:636, and the log also confirm its traffic was on port 636. Do you have any idea why is that?

Traffic from ADSI:

Traffic from Connector:

I can’t tell much from this, sorry. Looks like there is no data in the second one. I don’t see a RST so this isn’t the connection reset. But the load balancer side is terminating the connection (FIN). This could be a load balancer issue? But Wireshark probably isn’t the best tool to analyze this - can you get to the LB logs and to the AD LDS logs?

John

I tried more tests of directly connecting to the AD LDS server as you asked. I found no server-side logs that correspond to the time of my testing. I also captured the Wireshark log for the direct tests, as my previous logs were for the load balancer. Here is the Wireshark log for Connector when it gets RST:

Here is the log from ldp.exe to the LDS server directly:

Looks to me like the server rejected the Connector’s SSL request. I am wondering why is the Connector not using TLSv1.2? Do you know for a fact that out of the box, AD LDAP Connector works AD LDS?

Hi @johnxjcheng

As I said in my first message, I don’t know if the connector supports AD LDS, but I think it should be.

The wireshark dumps and lack of AD LDS logs indicate the connector is not even reaching the AD LDS. This indicates the LB, maybe filtering the traffic for some reason.

The SSL is troubling: that may be worth a support ticket, but I don’t know.

My best suggestion: create a simpler environment for testing only, without the LB. See if the connector can connect to AD LDS. If it cannot, then we know it is not supported. If it can, the issue is with the load balancer.

John

Hi john.gateley,

My last test was directly hitting the LDS server (10.41.109.182). Before, I was hitting the load balancer (10.41.109.9).

John Cheng

Hi john.gateley,

I want to try more on the Connector and went to the Troubleshooting tab to run the diagnostic step. From there I discovered it’s a few more things, such as the .pem file. I added certs\cert.pem under the installation folder. That helped me move one step further. Then I get this error:

Where do I specify the thumbprint on the connection? Here is what I entered on the Configuration tab:

Thanks,

John Cheng

Hi John,

You are far outside my realm of expertise now (Windows Cert Managment), but I suspect you will need to add the signer of that PEM to the Windows trusted CA list.

John