Bug 1394008 - Running setup-ds-admin.pl -u on a master with nsslapd-require-secure-bind=on fails
Summary: Running setup-ds-admin.pl -u on a master with nsslapd-require-secure-bind=on ...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Directory Server
Classification: Red Hat
Component: Command Line Utilities
Version: 10.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: DS10.1.1
: ---
Assignee: mreynolds
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-10 19:56 UTC by Brian J. Atkisson
Modified: 2020-07-29 13:02 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-29 13:02:27 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Brian J. Atkisson 2016-11-10 19:56:08 UTC
Description of problem:

It appears that running setup-ds-admin.pl in update mode (-u) fails when that is the server hosting o=netscaperoot and that server has nsslapd-require-secure-binds=on set.  setup-ds-admin.pl appears to have some logic that uses TLS when running on a replica, but when running on the server hosting o=netscaperoot, it tries to do plaintext connection.  This of course fails if you have nsslapd-require-secure-bind=on.  Maybe add a flag to require TLS?


Version-Release number of selected component (if applicable):
389-ds-base-1.3.5.10-11.el7.x86_64

Comment 1 mreynolds 2017-04-14 15:04:48 UTC
Hmm this works fine for me.  I did set nsslapd-require-secure-binds to on in cn=config.  I tested 389-ds-base-1.3.5.16 and the latest 1.3.6 on F25, and they both worked as expected


# setup-ds-admin.pl -u

==============================================================================
The update option will allow you to re-register your servers with the
configuration directory server and update the information about your
servers that the console and admin server uses.  You will need your
configuration directory server admin ID and password to continue.

Continue? [yes]: 

==============================================================================
Please specify the information about your configuration directory
server.  The following information is required:
- host (fully qualified), port (non-secure or secure), suffix,
  protocol (ldap or ldaps) - this information should be provided in the
  form of an LDAP url e.g. for non-secure
ldap://host.example.com:389/o=NetscapeRoot
  or for secure
ldaps://host.example.com:636/o=NetscapeRoot
- admin ID and password
- admin domain
- a CA certificate file may be required if you choose to use ldaps and
  security has not yet been configured - the file must be in PEM/ASCII
  format - specify the absolute path and filename

Configuration directory server URL [ldaps://localhost.localdomain:636/o=NetscapeRoot]: 
Configuration directory server admin ID [uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot]: 
Configuration directory server admin password: 
Configuration directory server admin domain [example.com]: 

==============================================================================
The interactive phase is complete.  The script will now set up your
servers.  Enter No or go Back if you want to change something.

Are you ready to set up your servers? [yes]: 
Updating instance (slapd-localhost)...
Successfully updated instance (slapd-localhost).
Registering the directory server instances with the configuration directory server . . .
Beginning Admin Server reconfiguration . . .
Registering admin server with the configuration directory server . . .
Updating adm.conf with information from configuration directory server . . .
Exiting . . .
Log file is '/tmp/setupjetPV6.log'




Access log:

[14/Apr/2017:10:26:16.793245635 -0400] conn=10 fd=65 slot=65 SSL connection from ::1 to ::1
[14/Apr/2017:10:26:16.797144057 -0400] conn=10 TLS1.2 128-bit AES-GCM
[14/Apr/2017:10:26:16.797280223 -0400] conn=10 op=0 BIND dn="uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot" method=128 version=3
[14/Apr/2017:10:26:16.797447961 -0400] conn=10 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot"
[14/Apr/2017:10:26:16.803241583 -0400] conn=10 op=1 SRCH base="cn=localhost.localdomain,ou=example.com,o=NetscapeRoot" scope=0 filter="(objectClass=*)" attrs="* aci"
[14/Apr/2017:10:26:16.804775331 -0400] conn=10 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[14/Apr/2017:10:26:16.805820467 -0400] conn=10 op=2 SRCH base="cn=localhost.localdomain,ou=example.com,o=NetscapeRoot" scope=0 filter="(objectClass=*)" attrs="* aci"
[14/Apr/2017:10:26:16.806745116 -0400] conn=10 op=2 RESULT err=0 tag=101 nentries=1 etime=0
...
...



I need to request a RHEL 7 lab machine to test exact version Brian used to see if it's an issue with that RHEL build.

Brian, what version of 389-admin is on your system?

Thanks,
Mark

Comment 2 Brian J. Atkisson 2017-06-22 15:47:46 UTC
I'll put this on my todo list to verify if it is still a problem.  This was with RHDS 10.0.

Comment 3 Viktor Ashirov 2019-08-26 08:12:37 UTC
Brian, is it still a problem?


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