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
--On Tuesday, February 11, 2025 6:47 AM -0500 Dino Edwards
<dino.edwards(a)mydirectmail.net> wrote:
>> Trying to get pass-through authentication working however, I'm running
>> to the following error in OpenLDAP:
>
>
>> Is the system it supposed to auth against another ldap server? If so I
> would recommend slapo-remoteauth instead:
>
> Hi, thanks for replying.
>
> Yes the plan is to auth against AD. I didn't even know about remoteauth
> which looks much simpler to implement. The problem I'm facing is that I'm
> attempting to utilize the bitnami openldap container to accomplish this
> and the documentation you pointed to talks about editing the slapd.conf
> file which the bitnami container does not utilize. Instead it utilizes the
> dynamic runtime configuration engine for config flexibility which
> requires a LDIF database instead. I'm not familiar enough with openldap
> to configure that.
I would suggest you start with a local installation and then adapt the
container configuration from there.
But here's an example for cn-config, you'd probably have to adjust for your
own environment.
dn: olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcRemoteAuthCfg
olcOverlay: {6}remoteauth
olcRemoteAuthTLS: starttls=yes tls_reqcert=never
olcRemoteAuthMapping: default ldaps://ad.example.com:636
olcRemoteAuthDNAttribute: seeAlso
olcRemoteAuthDomainAttribute: maildrop
olcRemoteAuthDefaultDomain: default
olcRemoteAuthDefaultRealm: ldaps://ad.example.com:636
olcRemoteAuthStore: FALSE
olcRemoteAuthRetryCount: 3
--Quanah
>>> 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
Using an ldaps://... URI works, so I'll just do that I guess. If
there's a starttls way of doing this, that would be nice to know about,
but at least I can create a secure connection.
-Ron-
2011-07-01_09:42:56-0400 Ron Peterson <rpeterso(a)mtholyoke.edu>:
> Hi,
>
> I have a rewrite map configured like:
>
> database ldap
> suffix "ou=myou"
> uri "ldap://my.backend/"
> tls start tls_cacertdir=/my/ca/cert/dir
> rwm-rewriteMap ldap uid2adminDN "ldap://my.backend/ou=yada,dc=yada?dn?sub" binddn="uid=someone,..." credentials="etc"
>
> My back end is configured to require tls, i.e.
>
> security ssf=128 update_ssf=128 simple_bind=128
>
> If I remove that requirement, everything works. When I add it, my back
> end ldap server logs:
>
> Jul 1 09:24:28 mid slapd[13011]: conn=1006 op=0 BIND dn="uid=someone,..." method=128
> Jul 1 09:24:28 mid slapd[13011]: conn=1006 op=0 RESULT tag=97 err=13 text=confidentiality required
>
> How do I configure rwm-rewritemap to use tls?
>
> -Ron-
On 21/02/11 20:25, Chris Jackson wrote:
> I am having trouble accessing my openldap server over SSL using an
> iPhone/iPad/iPod Touch using ios 4.2.1. If I check the SSL box in the
> client setup on the iPhone/iPad/iPod Touch I get an error in the slapd
> log -- TLS negotiation Failure. With logging level 9 I get TLS accept
> failure error=-1 id=1.
>
> Other clients work fine over SSL/StartTLS. Outlook, addressbook in osX
> 10.6, jxplorer.
>
> I am using openldap 2.4.19-15 on RHEL6 with a comodo wildcard SSL cert.
FWIW we had a similar problem here with our mail server accepting IMAPS
connections fine from everything except iPhones.
After some experimentation, I eventually found out it was because I had
generated our new SSL keys with "openssl gendsa" and it seems that for
some reason known only to Apple, only RSA keys as opposed to DSA keys
are supported in their iPhone TLS/SSL implementation. Regenerating a new
key with "openssl genrsa" instead and using that to sign the server SSL
certificate instead solved the problem and allowed the iPhones to connect.
HTH,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
Daniel Qian wrote:
> The problem direction has the same syncrepl configuration as the working
> one except for the rid and provider name:
>
> olcSyncrepl: {0}
> rid=102 provider="ldap://server2.prod:389/"
> type=refreshAndPersist
> retry="60 30 300 +"
> keepalive=1200:10:3
> searchbase="dc=mydomain,dc=com"
> bindmethod=simple
> binddn="cn=replica,dc=mydomain,dc=com"
> credentials=xxxxxx
> starttls=critical
> tls_cacert="/etc/pki/CA/cacert.pem"
>
> On the consumer side I am seeing these messages:
>
> Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrep2: rid=102 got search
> entry without Sync State control
> Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrepl: rid=102 rc -1
> retrying (29 retries left)
>
> and on the provider side I am seeing these:
> The sync connection is supposed to be persistent but it keeps closing
> down and reconnecting.
>
> Anyone know what could be the reason?
Obviously your "provider side" doesn't actually have the syncprov overlay
configured.
--
-- 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 10/18/12 13:28 -0700, Alejandro Rodriguez Luna wrote:
>Hi all!
>I have a TDS (Tivoli Directory Server) in one of my servers, every time i
> need to query it i need to go to another server and do it, i'd like to
>be able to query from my machine, but i can't using openldap, do you
>guys have a hint/idea/clue??
>
>i use this from another server
>
>idsldapsearch -h ldapserver.homeluna.org -Z -K /opt/PolicyDirector/ssl/homeluna.kdb -P passw0rd -b "" -s base objectclass=*
>
>btw, My servers only accepts SSL conections.
Assuming that -Z has the same effect as with OpenLDAP's ldapsearch, it
performs StartTLS over port 389, not ssl over port 636.
>btw, i put the following values inside /etc/openldap/ldap.conf without succeed.
>
>#
># LDAP Defaults
>#
>BASE l=world
>URI ldap://ldapserver.homeluna.org ldap://ldapserver.homeluna.org:636
>PORT 636
>
>TLS_CACERT /home/alexrl/Desktop/ldapserver.homeluna.org.cer
>TLS_REQCERT demand
>
>alexrl@localhost ~ $ ldapsearch -v -H ldaps://ldapserver.homeluna.org -Dcn=root -w passw0rd -bl=world uid=alex*
>ldap_initialize( ldaps://ldapserver.homeluna.org:636/??base )
>ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Try using options '-H ldap://ldapserver.homeluna.org' and '-Z' (or '-ZZ').
See the manpage for ldapsearch.
--
Dan White