directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] [Commented] (DIRSTUDIO-1173) StartTLS fails when required by LDAP service
Date Thu, 01 Mar 2018 16:11:00 GMT


Emmanuel Lecharny commented on DIRSTUDIO-1173:

The difference is that {{JNDI}} is antiquated, dead in the water, and crappy.

We keep it as an option for the sake of offering an option to user who may experiment some
difficulties with the API. It was an early choice, allowing us to test the API in Studio while
not blocking our users if we were to met some issues with the API.

Now that the LDAP API 1.0.0 has been released (it took us 6 years and a half to come with
such a milestone !), I bet we can say it's solid enough... However, I was working on it last
weeks, and I must admit I found bugs and dirty things in it :-) This is a never ending story
anyway !

Feel free to close the issue if you think switching to API solves it.

Thanks !

> StartTLS fails when required by LDAP service
> --------------------------------------------
>                 Key: DIRSTUDIO-1173
>                 URL:
>             Project: Directory Studio
>          Issue Type: Bug
>    Affects Versions: 2.0.0-M13
>         Environment: Windows 10 Pro 64bit
>            Reporter: Anthony Winstanley
>            Priority: Major
> We have 389-ds sitting behind an f5 load balancer. The load balancer requires connections
on port 389 to use StartTLS. It makes connections to the 389-ds servers on port 389 using
> If I connect directly to port 389 on a 389-ds server with "Use StartTLS extension", the
connection is fine. If I change the hostname of this connection to the load-balanced hostname,
I get:
> "The connection failed - [LDAP: error code 48 - STARTTLS required]"
> However, ldapsearch successfully makes STARTTLS connections through the load balancer
> ldapsearch -x -H ldap:// -ZZ
> My guess is that ADS is not activating StartTLS soon enough when connecting to port 389...
which is fine if the connection doesn't require the use of StartTLS, but unworkable when it
> Of course, I'm hoping this is an easy fix...

This message was sent by Atlassian JIRA

View raw message