starttls does not work with chaining backend

[Jacek Nykis]

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?

--
Jacek Nykis
IS Unix Frontend Engineer

Fax: [phone]
Yahoo! Messenger: nykisj

Betfair Limited | Winslow Road | Hammersmith Embankment | London | W6 9HP
Company No. 5140986

P Please consider the environment before printing

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.

________________________________________________________________________

[Rich Megginson]

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?
> --
>
> Jacek Nykis
>
> IS Unix Frontend Engineer
>
> Fax: [phone]
>
> Yahoo! Messenger: nykisj
>
> Betfair Limited | Winslow Road | Hammersmith Embankment | London | W6 9HP
>
> Company No. 5140986
>
> P* **Please consider the environment before printing*
>
> 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 ® 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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Jacek Nykis]

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

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.

--
Jacek Nykis
IS Unix Frontend Engineer

Fax: [phone]
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.

________________________________________________________________________

[Rich Megginson]

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?
> 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.
> --
> Jacek Nykis
> IS Unix Frontend Engineer
>
> Fax: [phone]
> 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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Jacek Nykis]

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
> > 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: [phone]
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.

________________________________________________________________________

[Rich Megginson]

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-spe...
> > > 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: [phone]
> 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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Jacek Nykis]

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/configuring-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.
> > > > 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_Replicati
> > > > 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.

--
Jacek Nykis
IS Unix Frontend Engineer

Fax: [phone]
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.

________________________________________________________________________

[Rich Megginson]

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/configuring-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.
> > > > > 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_Replicati
> > > > > 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.
>
> --
> Jacek Nykis
> IS Unix Frontend Engineer
>
> Fax: [phone]
> 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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Jacek Nykis]

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.