On Monday 13 September 2010 23:48:45 Rich Megginson wrote:
Jacek Nykis wrote:
On Tuesday 07 September 2010 16:04:22 Rich Megginson wrote:
Jacek Nykis wrote:
On Friday 03 September 2010 16:30:34 Rich Megginson wrote:
Jacek Nykis wrote:
On Thursday 02 September 2010 18:45:44 Rich Megginson wrote: > Jacek Nykis wrote: >> Hi, >> >> >> >> I am trying to setup chaining backend and I encountered some >> problems. >> >> I setup nsBackendInstance object with all attributes but it would >> seem that "nsusestarttls" does not have any effect. Here is what >> happens: >> >> >> >> If I use ldaps over port 636 everything is fine: >> >> nsusestarttls: off >> >> nsfarmserverurl: ldaps://xxx:636 >> >> >> >> But when I change values to below it stops: >> >> nsusestarttls: on >> >> nsfarmserverurl: ldap://xxx:389 >> >> >> >> Logs on master server suggest that slave does not use startTLS when >> connecting. >> >> >> >> On slave server I can see this: >> >> [02/Sep/2010:15:53:22 +0000] conn=1 fd=64 slot=64 connection from >> <client IP> to <Slave IP> >> >> [02/Sep/2010:15:53:22 +0000] conn=1 op=0 EXT >> oid="1.3.6.1.4.1.1466.20037" name="startTLS" >> >> [02/Sep/2010:15:53:22 +0000] conn=1 op=0 RESULT err=0 tag=120 >> nentries=0 etime=0 >> >> [02/Sep/2010:15:53:22 +0000] conn=1 SSL 256-bit AES >> >> [02/Sep/2010:15:53:22 +0000] conn=1 op=1 BIND >> dn="uid=xxx,ou=xxx,dc=xxx" method=128 version=3 >> >> [02/Sep/2010:15:53:22 +0000] conn=1 op=1 RESULT err=13 tag=97 >> nentries=0 etime=0 >> >> [02/Sep/2010:15:53:22 +0000] conn=1 op=-1 fd=64 closed - B1 >> >> >> >> On master: >> >> [02/Sep/2010:15:53:22 +0000] conn=34 fd=64 slot=64 connection from >> <Slave IP> to <Master IP> >> >> [02/Sep/2010:15:53:22 +0000] conn=34 op=0 BIND >> dn="uid=xxx,ou=xxx,dc=xxx" method=128 version=3 >> >> [02/Sep/2010:15:53:22 +0000] conn=34 op=0 RESULT err=13 tag=97 >> nentries=0 etime=0 >> >> >> >> We would prefer to use startTLS on port 389, does anybody know if >> this is possible or if anything else is required to make it work? > > What platform? What version of 389-ds-base?
Hi,
I am using CentOS 5.5 x86_64 on all machines. 389-ds-base v 1.2.6
which version of 1.2.6? 1.2.6-1, the official released version, or one of the .a or .rc releases?
Sorry I should have been more specific: 1.2.6-0.11.rc7
Does it work if you turn off the Require Secure Bind option on the master? http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/configurin g-sp ecial-binds.html#requiring-secure-binds
I have just tested and yes if I disable Require Secure Bind option on master everything works fine.
Ok. Please file a bug with the exact steps to reproduce.
Bug reported: https://bugzilla.redhat.com/show_bug.cgi?id=633803
thank you for looking into this issue.
I also noticed something strange. I am trying to setup global password lockout policy: http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Managing_Replica ti on - Replicating-Password-Attributes.html
When I set "passwordIsGlobalPolicy" to off problem disappears and I can bind and change passwords fine with startTLS on port 389. When I set it to on I cannot even bind.
err=13 is LDAP_CONFIDENTIALITY_REQUIRED - which means you attempted a SIMPLE BIND (i.e. DN and password) over a clear text connection. The log from the master shows that the connection attempt was made without LDAPS or a startTLS operation.
Yes. To be precise it is Slave server trying to chain request to Master with no startTLS. The problem is that this happens despite nsusestarttls attribute set to "on".
It looks this way: Client -----> Slave(read only) -----> Master
With "passwordisglobalpolicy: off" client binds to read only Slave using startTLS fine and everything works fine including password change which is chained to Master.
As soon as I set "passwordisglobalpolicy: on" on Slave it all brakes. Client cannot bind against Slave and I can see err=13 on Master during bind attempt.