Re: [389-users] starttls does not work with chaining backend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux