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/configuring-special-binds.html#requiring-secure-binds > >>> 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_Replication >>> - 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. > > > -- > Jacek Nykis > IS Unix Frontend Engineer > > Fax: +44 (0) 20 8834 8001 > Yahoo! Messenger: nykisj > > > Betfair Limited | Winslow Road | Hammersmith Embankment | London | W6 9HP > Company No. 5140986 > > > The information in this e-mail and any attachment is confidential and is > intended only for the named recipient(s). The e-mail may not be disclosed or > used by any person other than the addressee, nor may it be copied in any way. > If you are not a named recipient please notify the sender immediately and > delete any copies of this message. Any unauthorized copying, disclosure or > distribution of the material in this e-mail is strictly forbidden. Any view or > opinions presented are solely those of the author and do not necessarily > represent those of the company. Betfair (r) and the BETFAIR LOGO are > registered trade marks of The Sporting Exchange Limited. > > ________________________________________________________________________ > In order to protect our email recipients, Betfair Group use SkyScan from > MessageLabs to scan all Incoming and Outgoing mail for viruses. > > ________________________________________________________________________ > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users