directory-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/DIRSTUDIO-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16381490#comment-16381490
] 

Emmanuel Lecharny commented on DIRSTUDIO-1173:
----------------------------------------------

{{StartTLS}} is a LDAP operation, so Studio will send it *prior* to any other operation, be
it sent over port 389 or any other port.

What would help to understand what's going on is a Wireshark capture.

> StartTLS fails when required by LDAP service
> --------------------------------------------
>
>                 Key: DIRSTUDIO-1173
>                 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1173
>             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
StartTLS.
> 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
like:
> ldapsearch -x -H ldap://lbhost.example.com -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
does.
> Of course, I'm hoping this is an easy fix...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message