Bug 1581737 - passthrough plugin configured to do starttls does not work.
Summary: passthrough plugin configured to do starttls does not work.
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.7-Alt
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: mreynolds
QA Contact: RHDS QE
Marc Muehlfeld
Depends On:
Blocks: 1635138
TreeView+ depends on / blocked
Reported: 2018-05-23 14:13 UTC by German Parente
Modified: 2020-09-13 22:10 UTC (History)
9 users (show)

Fixed In Version: 389-ds-base-
Doc Type: Bug Fix
Doc Text:
The Directory Server *Pass-through* plug-in now supports encrypted connections using the *STARTTLS* command Previously, the *Pass-through* plug-in in Directory Server did not support encrypted connections if the encryption was started using the *STARTTLS* command. The problem has been fixed, and the *Pass-through* plug-in now supports connections that use the *STARTTLS* command.
Clone Of:
: 1635138 (view as bug list)
Last Closed: 2018-10-30 10:13:48 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 2807 0 None None None 2020-09-13 22:10:51 UTC
Red Hat Product Errata RHSA-2018:3127 0 None None None 2018-10-30 10:14:32 UTC

Description German Parente 2018-05-23 14:13:15 UTC
Description of problem:

I have configured passthrough plugin to do Starttls:

nsslapd-pluginarg0: ldap://nslcd.parente.local:1389/dc=parente,dc=local 3,5,30

I have added plugin debug logs. To have that login, I had to define this in source code and re-build:


Then I see clearly:

passthru-plugin - PTA server host: "nslcd.parente.local", port: 1389, secure: 2, maxconnections: 3, maxconcurrency: 5, timeout: 300, ldversion: 3, connlifetime: 300

secure: 2 means starttls:

        if (starttls) {
            srvr->ptsrvr_secure = 2;

bind as:

ldapsearch -D "uid=omc,ou=people,dc=parente,dc=local" -w secret12 -b "dc=parente,dc=local" -s base

But in the access logs, we see clearly:

[23/May/2018:10:07:20.883924603 -0400] conn=1 fd=64 slot=64 connection from to
[23/May/2018:10:07:20.884685945 -0400] conn=1 op=0 BIND dn="uid=omc,ou=people,dc=parente,dc=local" method=128 version=3
[23/May/2018:10:07:20.886823710 -0400] conn=1 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0002572394 dn="uid=omc,ou=people,dc=parente,dc=local"

No startls.

Now, in the code, when parsing the url:

    /* use secure setting from url if none given */
    if (!secure && ludp) {
        if (secureurl) {
            secure = SLAPI_LDAP_INIT_FLAG_SSL;
        } else if (0 /* starttls option - not supported yet in LDAP URLs */) {
            secure = SLAPI_LDAP_INIT_FLAG_startTLS;

So, I wonder if the problem is not that the starttls is not supported in ldap urls but ... in the passthrough plugin we cannot but specify ldapurl

Version-Release number of selected component (if applicable):


Comment 4 mreynolds 2018-06-04 16:24:00 UTC
Upstream ticket:

Comment 5 mreynolds 2018-06-05 15:46:17 UTC
Fixed upstream

Comment 11 Akshay Adhikari 2018-08-10 11:04:13 UTC
Build Tested: 389-ds-base-
Note: Target server is the machine on which SSL is configured and source server is the one on which passthrough plugin is configured.
1) Configure passthrough plugin to do starttls:
   dn: cn=Pass Through Authentication,cn=plugins,cn=config
   changetype: modify
   replace: nsslapd-pluginarg0
   nsslapd-pluginarg0:  ldap://<hostname>:<ldap_port>/dc=example,dc=com 3,5,300,3,300,1
2) Set nsslapd-pluginEnabled to ON.
3) Restart the source server.
4) Add a user under the suffix "dc=example,dc=com".
5) Add the CA certificate from Target machine to the source.
6) Restart the source server.
(Acess log of Target Machine)

[07/Aug/2018:19:12:40.815180192 +051800] conn=53 fd=64 slot=64 connection from to
[07/Aug/2018:19:12:40.815427962 +051800] conn=53 op=0 EXT oid="" name="start_tls_plugin"
[07/Aug/2018:19:12:40.815608583 +051800] conn=53 op=0 RESULT err=0 tag=120 nentries=0 etime=0.0000319538
[07/Aug/2018:19:12:41.335641674 +051800] conn=53 TLS1.2 256-bit AES-GCM
[07/Aug/2018:19:12:42.169458011 +051800] conn=53 op=1 BIND dn="uid=adam,ou=people,dc=example,dc=com" method=128 version=3
[07/Aug/2018:19:12:42.170164748 +051800] conn=53 op=1 RESULT err=0 tag=97 nentries=0 etime=1.0101292500 dn="uid=adam,ou=people,dc=example,dc=com"

Comment 15 errata-xmlrpc 2018-10-30 10:13:48 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.