Description of problem: Setting passwordisglobalpolicy attribute to "on" on slave brakes TLS chaining to master server. Version-Release number of selected component (if applicable): 1.2.6-0.11.rc7.el5 How reproducible: Every time Steps to Reproduce: 1. Setup environemnt this way: Client -----> Slave -----> Master * secure binds enforced on slave and master * client has no direct access to master * slave is set to chain updates to master on port 389 with nsusestarttls attribute set to on * set passwordisglobalpolicy attribute to on 2. Run search on client: ldapsearch -x -ZZ -h <slave> -D "xxxxx" -y passwordfile -b xxxxxx ldap_bind: Confidentiality required (13) additional info: Operation requires a secure connection Actual results: 1. Error message on client: ldap_bind: Confidentiality required (13) additional info: Operation requires a secure connection 2. In logs on Master server: [14/Sep/2010:12:30:14 +0000] conn=102 op=17 BIND dn="xxxxx" method=128 version=3 [14/Sep/2010:12:30:14 +0000] conn=102 op=17 RESULT err=13 tag=97 nentries=0 etime=0 Expected results: Search should be working fine regardless of passwordisglobalpolicy value. Additional info: Mailing-list thread: http://www.spinics.net/lists/fedora-directory/msg12044.html We know about 3 workarounds so far: 1. Disable secure binds on master (http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/configuring-special-binds.html#requiring-secure-binds) 2. Set nsusestarttls to off and replace "ldap" with "ldaps" in nsfarmserverurl attribute 3. Set passwordisglobalpolicy to off
Created attachment 519337 [details] 0001-Bug-633803-passwordisglobalpolicy-attribute-brakes-T.patch
To ssh://git.fedorahosted.org/git/389/ds.git 116f683..e1c9a73 master -> master commit e1c9a73a8ec2a86c5a2f6c7e3b4cb39046475666 Author: Rich Megginson <rmeggins> Date: Mon Aug 22 13:18:53 2011 -0600 Reviewed by: nkinder (Thanks!) Branch: master Fix Description: If not binding in cb_get_connection, we need to explicitly do the start_tls. The start_tls and mechanism settings were not being applied to the bind_pool connections. I tried setting passwordIsGlobalPolicy on and off. That did not seem to make a difference. I believe the problem is caused by the nsslapd-require-secure-binds attribute set to "on". Platforms tested: RHEL6 x86_64 Flag Day: no Doc impact: no