On 02/18/2016 03:19 AM, Dieter Klünter wrote:
> Am Wed, 17 Feb 2016 20:25:56 -0700
> schrieb Joshua Schaeffer <jschaeffer0922(a)gmail.com>:
>
>> What is the proper way to setup SASL and TLS with different security
>> strength factors? I've setup SASL on my OpenLDAP server so that it
>> can connect to my Kerberos server using GSSAPI. I also have TLS setup
>> for simple auth. My database config is below:
> [...]
>> olcSecurity: sasl=56 simple_bind=256 ssf=256
>
> ssf=x specifies the overall security, a value '1' enables security.
> This setting would meet your requirements:
> olcSecurity: ssf=1 sasl=56 tls=256
>
>
> -Dieter
>
I updated olcSecurity and now I get the following when using simple auth:
root@immortal:/var/log/kerberos# ldapsearch -LLL -x -D cn=admin,dc=harmonywave,dc=com -W -H ldap://baneling.harmonywave.com/????starttls -b dc=harmonywave,dc=com
Enter LDAP Password:
ldap_bind: Confidentiality required (13)
additional info: SASL confidentiality required
I see this in the logs:
Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 ACCEPT from IP=10.1.10.12:55750 (IP=0.0.0.0:389)
Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 STARTTLS
Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 RESULT oid= err=0 text=
Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 TLS established tls_ssf=256 ssf=256
Feb 18 22:19:08 baneling slapd[22171]: conn=1005 op=1 BIND dn="cn=admin,dc=harmonywave,dc=com" method=128
Feb 18 22:19:08 baneling slapd[22171]: conn=1005 op=1 RESULT tag=97 err=13 text=SASL confidentiality required
Feb 18 22:19:08 baneling slapd[22171]: conn=1005 op=2 UNBIND
Feb 18 22:19:08 baneling slapd[22171]: conn=1005 fd=15 closed
Hello,
I have 2 CentOS 5.4 servers running OpenLDAP 2.4.20
installed from Buchan Milne's repository (openldap2.4-
servers-2.4.20-1.el5).
The first server is a Sync Provider.
The second is a consumer with 'starttls=critical'.
I have no problem after 'yum update' of the master
(openldap2.4-servers-2.4.22-1.el5 is installed and replication is OK).
But after 'yum update' of the slave, syncrepl won't work anymore
because of TLS failures.
Here are the logs on the master :
Oct 20 16:51:15 vcos-castor slapd2.4[20097]: @(#) $OpenLDAP: slapd
2.4.22 (Apr 27 2010 12:04:27) $
bgmilne@centos5-32.ranger.dnsalias.com:/home/bgmilne/rpm/BUILD/
openldap-2.4.22/servers/slapd
Oct 20 16:51:15 vcos-castor slapd2.4[20098]: slapd starting
Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 fd=16 ACCEPT
from IP=IP.OF.THE.SLAVE:46212 (IP=0.0.0.0:389)
Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 STARTTLS
Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 RESULT
oid= err=0 text=
Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 fd=16 closed
(TLS negotiation failure)
Here are the logs on the slave :
Oct 20 16:51:45 vcos-pollux slapd2.4[1808]: @(#) $OpenLDAP: slapd
2.4.22 (Apr 27 2010 12:04:27) $
bgmilne@centos5-32.ranger.dnsalias.com:/home/bgmilne/rpm/BUILD/
openldap-2.4.22/servers/slapd
Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: slapd starting
Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: slap_client_connect:
URI=ldap://NAME_OF_THE_MASTER Error, ldap_start_tls failed (-11)
Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: do_syncrepl: rid=000 rc
-11 retrying (4 retries left)
ldapsearch from the slave can do TLS :
$ ldapsearch -ZZ -x -h NAME_OF_THE_MASTER
This is ldapsearch from openldap-clients-2.3.43-12.el5_5.2 as packaged
by CentOS
Any ideas on how to troubleshoot the problem?
Regards,
Thierry
PS : as a side note both servers are Xen VMs running on CentOS hosts.
On 11/05/2012 04:05 PM, Dan White wrote:
> On 11/05/12 08:29 +0100, Admus wrote:
>> On 11/04/2012 11:59 PM, Dan White wrote:
>>> On 11/04/12 23:13 +0100, admus wrote:
>>>> Hello,
>>>> I'm following
>>>> https://help.ubuntu.com/12.04/serverguide/openldap-server.html#openldap-tls…
>>>> how to:
>>>> LDAP serwer starts correctly but when I tries to test StartTLS:
>>>> ldapsearch -x -H ldap:/// -ZZ -d -1
>>>> I gets the following error:
>>>> TLS: peer cert untrusted or revoked (0x42)
>>>> TLS: can't connect: (unknown error code).
>>>> ldap_err2string
>>>> ldap_start_tls: Connect error (-11)
>>>> additional info: (unknown error code)
>>>> Any idea?
>>>
>>> Your hostname will need to match the certificate you have installed.
>>> '-H
>>> ldap:///' will, instead, need to include the hostname matching your
>>> certificate.
>>>
>>> For project documentation, see chapter 16 of the OpenLDAP
>>> Administrator's
>>> Guide, slapd-config(5), ldap.conf(5), and ldapsearch(1).
>>>
>>
>> ldapsearch -x -H ldap://ldap1.example.com -ZZ -d -1
>>
>> Does not help, same error. CN in my certificate is ldap1.example.com.
>
> Assuming that your OpenLDAP was compiled against GnuTLS, use the GnuTLS
> tools to trouble shoot your certificate.
>
> A google search for "peer cert untrusted or revoked (0x42)" finds
> users who
> also received that error.
>
The output of `gnutls-cli --print-cert -p 636 ldap1.example.com` is:
- The hostname in the certificate matches 'ldap1.example.com'.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.2
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed
On Thu, 19 Sep 2013, espeake(a)oreillyauto.com wrote:
> We have a client server that is failing on the ssl handshake using TLS.
> The following is from the server log when the client is trying to connect.
>
> Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 ACCEPT from
> IP=172.17.1.10:55469 (IP=0.0.0.0:389)
> Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 EXT
> oid=1.3.6.1.4.1.1466.20037
> Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 STARTTLS
> Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 RESULT oid=
> err=0 text=
> Sep 19 09:12:50 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 closed (TLS
> negotiation failure)
>
> On the client when I run the following:
>
> openssl s_client -showcerts -connect tntest-ldap.oreillyauto.com:389
That doesn't do StartTLS (like your client is attempting), though.
Try something like
https://groups.google.com/forum/#!topic/mailing.openssl.users/1OOwXp45iIw
if you'd like. Or OpenLDAP Software such as ldapsearch(1).
Turning up the slapd(8) debug level may be of some use, too.
> I get this on the client
>
> CONNECTED(00000003)
> 139669033973408:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:s23_lib.c:177:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 226 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
>
> If I do the same command on port 636 I can see the certificate. All of our
> applications that use ldap are all set for TLS. Even if I force them to
> port 636 they fail.
>
> Any ideas to look at are appreciated.
>
> Eric Speake
> Web Systems Administrator
> O'Reilly Auto Parts
>
> This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS ? 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
>
>
On 05/18/2011 08:26 AM, Sayantan Ray wrote:
> Hi,
> During initial communication setup with LDAP server with TLS on we are
> doing:
> ldap_initialize()
> ldap_set_option()
> ldap_start_tls_s()
> ldap_sasl_bind_s()
> and
> We are running the LDAP server remotely
> We observed that ldap_start_tls_s() is taking around 15 sec time to
> execute.
> Anybody has any idea why this is taking this much time?
> Please help
> Thanks,
> Sayantan Ray
Could it be a DNS issue?
R's,
Hugo Monteiro.
--
fct.unl.pt:~# cat .signature
Hugo Monteiro
Email : hugo.monteiro(a)fct.unl.pt
Telefone : +351 212948300 Ext.15307
Web : http://hmonteiro.net
Divisão de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.fct.unl.pt apoio(a)fct.unl.pt
fct.unl.pt:~# _
On Fri, 28 Dec 2012, Wiebe Cazemier wrote:
> I understand that, but this way, even when you're forcing TLS, users can
> still expose their passwords if their computers are mal-configured.
> SMTP, IMAP, FTP, etc don't allow this, because they reject the
> connection if LOGINNAME is given before STARTTLS.
That is not true of SMTP's AUTH PLAIN, IMAP's AUTHENTICATE PLAIN, or
IMAP's LOGIN. The PLAIN SASL mechanism and IMAP's LOGIN command both send
the username and password without waiting for a response from the
server**.
> It's kind of a security issue. Is it because in LDAP, username and
> password are given as one command, and the server doesn't have the
> chance to abort at that point? If so, then I guess it's unavoidable.
Correct.
Philip Guenther
** Well, to be completely accurate, IMAP AUTHENTICATE requires a server
response if the server doesn't support the SASL-IR capability
I'm having a lot of trouble with replication when using SSL. If I configure
everything exactly the same without SSL, it works flawlessly. The instant I
try to encrypt traffic, one or both servers will deadlock, even after
restart.
I'm configuring according to the instructions at
http://www.openldap.org/doc/admin24/replication.html#N-Way Multi-Master,
except using ldaps:// instead of ldap://.
In cn=config, I've setup:
olcTLSCACertificateFile: /etc/openldap/certs/Operations_CA_Certificate.pem
olcTLSCertificateFile: /etc/openldap/certs/ldap.pem
olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.key
I've also tried using STARTTLS over ldap:// and it seems to make no
difference.
Permissions are right and I can connect via SSL from clients without issue.
I'm completely stumped as to what might be going on. Has anyone seen this
before?
This is running on Scientific Linux 6 with the following packages:
openldap-2.4.23-32.el6_4.x86_64
openldap-clients-2.4.23-32.el6_4.x86_64
openldap-servers-2.4.23-32.el6_4.x86_64
Yeah, that's the trick though. The OP indicated if they used uri ldap://[hostname] StartTLS doesn't work.
- chris
-----Original Message-----
From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Andreas Ntaflos
Sent: Friday, January 07, 2011 10:46 AM
To: openldap-technical(a)openldap.org
Subject: Re: Strange behavior with TLS with self-signed certs
On Friday 07 January 2011 04:18:40 Michael Starling wrote:
> #TLS settings
> ssl start_tls
> ssl on
That should be either "ssl start_tls" OR "ssl on", not both. If you specify "ssl start_tls" then you should use the ldap:// URL schema, if you specify "ssl on" then you should use ldaps://.
Andreas
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Stopping users that are "unauthenticated" makes no sense; everything's
unauthenticated at time=0. You might as well stop slapd if you want a 100%
inability to serve data.
You can deny anonymous users that aren't plaintext, including any
ldaps:/// connections, with something like:
access to *
by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break
by anonymous none
early on in your ACL stanzas. I'm pretty sure this'll deny anonymous
StartTLS users on 389, though; not sure if that's what you want. I can't
think of any way to use the slapd access language to differentiate based
on listeners, which would probably be the most elegant way to handle what
you asked. To be fair, this entire exercise seems really odd from where I
sit -- are you positive that this will have the desired effect? (If
somebody out in Peru is permitted to connect in unencrypted and make
anonymous queries, why not allow them to make those same queries
encrypted? What's the difference?)
--On Monday, January 28, 2008 2:57 PM +0000 Chris Carr
<chris.carr(a)Camden.gov.uk> wrote:
> Hi All,
>
> I've been running slapd with "-h ldaps:///" so that it takes SSL/TLS
> connections on port 636. This has worked with most clients (Outlook,
> Seamonkey, Thunderbird) but does not work for Evolution. I don't know
> why not, but Evolution seems to insist on using port 389 for secure
> connections.
>
> When I type
>
> openssl s_client -connect my.server.com:389
If you read the documentation on openssl, it clearly states it doesn't
support doing LDAP startTLS over port 389.
I suggest using ldapsearch -ZZ -H ldap://my.server.com:389/
or similar.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
