Bug 1394008

Summary: Running setup-ds-admin.pl -u on a master with nsslapd-require-secure-bind=on fails
Product: Red Hat Directory Server Reporter: Brian J. Atkisson <batkisso>
Component: Command Line UtilitiesAssignee: mreynolds
Status: CLOSED WORKSFORME QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 10.0CC: batkisso, dminnich, mreynolds, nkinder, pasik
Target Milestone: DS10.1.1   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-29 13:02:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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?