On 2013.07.31 06.36, Tony Davis wrote:
> Hi,
>
> I wonder if anyone can help me with a question I have regarding an
> openldap setup on Redhat / Centos 5.8 using openldap-2.3.43.
>
> I am trying to setup replication, I have set this up using the simple
> bind method, which stores a password for the replication in the config.
> (This works) but I wondered if there was a way to have this replication
> take place using ssl certificates without the need to store the unhashed
> password in the slapd.conf? Is this possible? or do I still have to
> specify a replication user and pass, but all the auth takes place over ssl?
you are talking about two different things. one is encryption, and one
is authentication.
making some basic assumptions [e.g. that the provider is properly
configured for encryption], using starttls means that communication is
encrypted, regardless of how you might be authenticating or what sasl
mechanism might be in use.
as far authentication goes, if you want to do certificate based
authentication, first read the section in the admin guide which covers
this [chapter 16. using tls]. then, use ldapsearch or friends for the
exercise of set up and testing of the provider. once that is working,
translate those settings to the consumer syncrepl config element.
on a related note, the tls_cert/tls_key syncrepl settings are to specify
the key and cert of the client [e.g. the consumer]. not the provider.
those files are what the consumer will use when authenticating to the
provider via certificates.
-ben
On 09/25/13 13:43 -0700, Chad Scott wrote:
>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.
Does slapd still respond? If so, verify that your entropy is not being
depleted for your ssl connections. I believe by default openssl uses
/dev/random which can block. Check /proc/sys/kernel/random/entropy_avail.
>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
--
Dan White
Quanah Gibson-Mount wrote:
>
>
> --On Wednesday, October 9, 2019 3:23 PM +0000 Howard.Gillison(a)gvltec.edu wrote:
>
>>
>>
>> Good morning to you,
>
> I suggest you read the OpenLDAP client code and the libldap code which fully utilizes the API to make connections with or without TLS. I think the *function*> you're looking for is ldap_start_tls_s (at least for startTLS over port 389):
Since he mentions port 636, he should just be using an ldaps://<host> URL with ldap_initialize().
>
> <https://www.openldap.org/software/man.cgi?query=ldap_start_tls_s&apropos=0&…>
>
>> From the library, I would suggest perusing libldap/init.c, libldap/open.c,
> libldap/options.c, and libldap/unbind.c
>
> Since this is open source software it is of course trivial to access the code and have working examples before you.
>
> Regards,
> Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Friday, November 17, 2017 12:53 PM +1000 William Brown
<wibrown(a)redhat.com> wrote:
Hi William,
> Hey mate,
>
> Just want to point out there are some security risks with ssf settings.
> I have documented these here:
>
> https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.html
>
> This is a flaw in the ldap protocol and can never be resolved without
> breaking the standard. The issue is that by the time the ssf check is
> done, you have already cleartexted sensitive material.
I think what you mean is: There is no way with startTLS to prevent possible
leakage of credentials when using simple binds. ;) Your blog certainly
covers this concept well, but just wanted to be very clear on what the
actual issue is. ;) I've been rather unhappy about this for a long time as
well, and have had a discussion going on the openldap-devel list about
LDAPv4 and breaking backwards compatibility to fix this protocol bug.
Another note -- The reason GSSAPI shows up as an SSF of 56 is because it
has been hard coded that way in cyrus-sasl. Starting with cyrus-sasl
version 2.1.27, which is near release, the actual SASL SSF is finally
passed back into the caller. It may be worthwhile noting this in your blog
post. ;)
Warm regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Hi
On the LDAP Server , I run following command is ok:
#ldapsearch -x -H ldap://ldap.server.com -ZZ
#ldapsearch -x -H ldap://ldap.server.com
But on my client , I run "#ldapsearch -x -H ldap://ldap.server.com", is ok;
Run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I get the following error:
[root@client cacerts]# ldapsearch -x -H ldap://ldap.server.com -ZZ
ldap_start_tls: Connect error (-11)
On LDAP Server log file, I get the following error messages:
Oct 23 16:41:25 auth slapd[4213]: conn=206 fd=24 ACCEPT from IP=192.168.9.9:45648 (IP=0.0.0.0:389)
Oct 23 16:41:25 auth slapd[4213]: conn=206 op=0 STARTTLS
Oct 23 16:41:25 auth slapd[4213]: conn=206 op=0 RESULT oid= err=0 text=
Oct 23 16:41:25 auth slapd[4213]: conn=206 fd=24 closed (TLS negotiation failure)
My client ldap configuration:
/etc/openldap/ldap.conf file:
URI ldap://ldap.server.com/
BASE dc=server,dc=com
TLS_CACERT /etc/openldap/cacerts/ca.crt
SSL ON
TLS_REQCERT demand
/etc/ldap.conf file:
BASE dc=server,dc=com
URI ldap://ldap.server.com
SSL ON
TLS_CACERT /etc/openldap/cacert/ca.crt
TLS_REQCERT demand
Any suggestion what cause TLS negotiation failure?
Thanks!
Tian Zhiying
Dieter Klünter wrote:
> Am Wed, 5 Mar 2014 14:38:04 +0800
> schrieb "Eileen(=^ω^=)" <123784635(a)qq.com>:
>> This is Eileen from China SINAP. I am a beginner for openldap soft. I
>> encountered a problem in my study on two LDAP services replication.
>> I have 2 LDAP services, one name LDPA1, the other is LDAP2 . I want
>> to make them synchronously in mirror mode. But when I set LDAP
>> services rootpw both in hash, the 2 LDAP serivces can’t be
>> synchronous. My question is
>> 1. if I set my rootpw in hash, my bindmethod must be SASL? If I
>> must use sasl method, can I put the sasl service in the same ldap
>> service? If bindmethod=sasl then what is the saslmech should be?
>> 2. If I change to sasl method, do I need change my database
>> record?
>
> In order to use sasl, passwords must be cleartext and you should
> configure an apropriate authz-regexp, see man slapd.conf(5)
> You may use any sasl mechanism that you sasl framework provides.
> [...]
To be more precise: In order to use password-based SASL mechs the passwords
have to be stored in clear-text.
Well, if working with SASL and TLS (LDAPS, StartTLS) one should consider using
client certs and SASL/EXTERNAL for replication.
Ciao, Michael.
"Klaus Nagel" <m_a_i_l(a)web.de> writes:
> Hello, I have a little problem with the chain overlay and hope, someone
> can help me. I have a master and a slave server (both debian lenny with
> openldap 2.4.11) and a normal syncrepl replication between both, but I
> can't get the chain working.
>
> my slave slapd.conf entries:
>
> moduleload back_ldap
> overlay chain
> chain-uri "ldap://10.8.0.1:389/"
> chain-rebind-as-user TRUE
> chain-idassert-bind bindmethod=simple
> binddn="cn=admin,dc=test,dc=de"
> credentials=testpw
> mode=self
> chain-tls start
> chain-return-error TRUE
the global part of my slapd.conf
overlay chain
chain-uri ldap://ldap.avci.de
chain-idassert-bind
bindmethod=simple
binddn="cn=replicator,o=avci,c=de"
credentials="xxx"
mode=self
flags=non-prescriptive
starttls=yes
tls_cacert=/opt/openldap/etc/openldap/certs/avciCA.pem
tls_reqcert=demand
chain-return-error TRUE
chain-rebind-as-user TRUE
chain-tls start
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:8EF7B6C6
53°37'09,95"N
10°08'02,42"E
>>> Quanah Gibson-Mount <quanah(a)fast-mail.org> schrieb am 30.03.2022 um 19:54
in
Nachricht <C8313B172407454CBF061C89(a)[192.168.1.12]>:
>
> ‑‑On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania
> <stefan(a)xn--kaniaonline-pf3f.de> wrote:
>
>> That's what can be found in the FAQ on openldap.org:
>>
>> https://www.openldap.org/faq/data/cache/605.html
>>
>> I would trust this more then any rumors on any stackxxxx page ;)
>
> Unfortunately, the FAQ is dead weight we want to kill and not maintained in
> any way, shape, or form. It's currently provided for historical purposes.
>
> As to this overall discussion, one of the primary issues with connections
> over ldap:/// is that there's zero way with simple binds to prevent the
> bind dn + password being sent in the clear by a client to the server. With
> ldaps:/// the encryption is set up before the BIND occurs so you don't run
> this risk.
>
> So from that standpoint, I'd personally prefer to see ldaps:/// qualified
> in an RFC so the standardization argument goes away and ldaps be noted as
> the preferred method for sites that require encryption.
So while talking about FAQs, maybe someone add:
"How to convert am OpenLDAP STARTLTS configuration to ldaps://?"
>
> ‑‑Quanah
