Anyone?
Siddharth Choure
Senior Systems Engineer
On 11/22/13, 4:15 PM, "Choure, Sidd" <schoure(a)apartments.com> wrote:
>Everything is setup on RHEL 6.4 with Openldap 2.4.
>
>I have one provider and one consumer. StartTLS has been enabled and
>everything is working as intended. My only problem arises here -
>When a user is setup with a password and he tries to change his password
>on a consumer pointing client, I get a passwd: Authentication token
>manipulation error. This message is misleading since the password is in
>fact changed on the provider ( I have the olcUpdateRef directive setup).
>This creates a situation where the user can login to consumer pointed
>boxes with his old password and provider pointed boxes with his new
>password. If the user tries to change his password for the second time on
>consumer pointed boxes, I get Password change failed. Server message:
>unwilling to verify old password passwd: Authentication token
>manipulation error which understandably is because the password in the
>actual LDAP db is different from what is being supplied and being
>accepted by the client. What is going on here? Why isn¹t the password not
>getting updated properly in the consumer?
>
>Here are some of the relevant snippets of configs -
>For Syncrepl in olcDatabase={2}bdb.ldif on consumer
>
>
>###For Replication
>
>olcSyncrepl: rid=100
>
> provider="ldap://server.com
>
> type=refreshAndPersist
>
> retry="60 30 300 +"
>
> searchbase=³dc=ex,dc=example,dc=com"
>
> bindmethod=simple
>
> binddn="cn=Manager,dc=ex,dc=example,dc=com"
>
> credentials=secret
>
> starttls=yes
>
> tls_cacert=/etc/pki/CA/cacert.pem
>
> tls_cert=/etc/pki/tls/certs/cert.pem
>
> tls_key=/etc/pki/tls/certs/key.pem
>
>olcUpdateRef: ldap://server.com
>
>
>ACL on provider -
>
>lcAccess: to attrs=userPassword
>
> by self write
>
> by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
>
> by anonymous auth
>
> by * none
>
>olcAccess: to *
>
> by self write
>
> by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
>
> by users read
>
>olcAccess: to attrs=entry
>
> by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
>
> by * read
>
>
>
>Let me know if any more configs are needed and I will post them. Any help
>is appreciated.
>
>Siddharth Choure
>Senior Systems Engineer
>
>
>
>
Hi to all,
is it now save to use mmr of cn=config with OpenLDAP 2.6? I got it
running with 4 server.
I'm installing all 4 server with Ansible so I created a basic configuration:
------------------
dn: cn=config
objectClass: olcGlobal
cn: config
olcLogLevel: sync
olcLogLevel: stats
olcPidFile: /var/symas/run/slapd.pid
olcArgsFile: /var/symas/run/slapd.args
olcToolThreads: 1
olcServerID: 4
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
# Read all needed schema from variable in default/main.yml
include: file:///opt/symas/etc/openldap/schema/core.ldif
include: file:///opt/symas/etc/openldap/schema/cosine.ldif
include: file:///opt/symas/etc/openldap/schema/nis.ldif
include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif
include: file:///opt/symas/etc/openldap/schema/dyngroup.ldif
include: file:///opt/symas/etc/openldap/schema/kerberos.openldap.ldif
# Read all modules from variable in default/main.yml
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /opt/symas/lib/openldap
olcModuleLoad: back_mdb
olcModuleLoad: back_monitor
olcModuleLoad: autoca.la
olcModuleLoad: otp.la
olcModuleLoad: argon2.la
olcModuleLoad: syncprov
olcModuleLoad: back_monitor
olcModuleLoad: accesslog.la
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcSizeLimit: 500
olcAccess: {0}to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by
dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth
manage
by * break
olcAccess: {1}to dn="" by * read
olcAccess: {2}to dn.base="cn=subschema" by * read
olcPasswordHash: {ARGON2}
dn: olcBackend={0}mdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}mdb
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=admin,cn=config
olcRootPW:
{ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4
olcAccess: {0}to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by
dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth
manage
by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write
by * break
dn: olcDatabase={1}monitor,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {1}monitor
olcAccess: {0}to dn.subtree="cn=monitor"
by dn.exact=cn=admin,cn=config read
by dn.exact=cn=admin,dc=example,dc=net read
dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcmdbConfig
olcDatabase: {2}mdb
olcSuffix: dc=example,dc=net
olcRootDN: cn=admin,dc=example,dc=net
olcRootPW:
{ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4
olcSizeLimit: unlimited
olcTimeLimit: unlimited
olcDbCheckpoint: 512 30
olcDbDirectory: /var/symas/openldap-data
olcDbIndex: default eq
olcDbIndex: objectClass
olcDbIndex: entryUUID
olcDbIndex: entryCSN
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: mail pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: description pres,eq,sub
olcDbIndex: title pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbMaxSize: 85899345920
olcAccess: {0} to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by
dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth
manage
by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write
by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read
by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=subschema" by * read
olcAccess: {3} to attrs=userPassword
by anonymous auth by self write by * none
olcLimits: {0} dn.exact="uid=repl-user,ou=users,dc=example,dc=net"
time=unlimited
size=unlimited
olcLimits: {1} dn.exact="uid=ldap-admin,ou=users,dc=example,dc=net"
time=unlimited
size=unlimited
------------------
The "ServerID" is different for every server, every thing else is
identical.
Then I created a file to change the serverID:
------------------
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://ldap01.example.net
olcServerID: 2 ldap://ldap02.example.net
olcServerID: 3 ldap://ldap03.example.net
olcServerID: 4 ldap://ldap04.example.net
------------------
and a file to configure the replication:
------------------
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcSyncRepl
olcSyncRepl: rid=1
provider=ldap://ldap01.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
olcSyncRepl: rid=2
provider=ldap://ldap02.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
olcSyncRepl: rid=3
provider=ldap://ldap03.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
olcSyncRepl: rid=4
provider=ldap://ldap04.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
-
add: olcMirrorMode
olcMirrorMode: TRUE
------------------
When I configure the server via Ansible (everything in one playbook) the
replication of cn=config is not working. When I only do the basic
configuration via Ansible and then add the change of serverID and then
the replication of cn=config step by step on every single server:
-------------
ldapmodify -Y EXTERNAL -H ldapi:/// -f serverid.ldif
ldapmodify -Y EXTERNAL -H ldapi:/// -f repl_config.ldif
-------------
everything is fine. The two files "serverid.ldif" and "repl_config.ldif"
are the files Ansible created, so the content of the file is the same.
Can it be, that the problem is because Ansible first sets all the
ServerIDs on all servers and then configure the replication of cn=config
on all servers?
For setting up the configuration I took:
https://www.openldap.org/devel/admin/replication.html
Starting at 18.3.3
What I don't understand: Do I realy have to put all Servers in the
replication, even the server it self? So do I realy have to add on
Server-01, the Server "server-01, server-02, server-03 ,server-04" to
the replication? Dosn't it mean that server-01 is replicating to it
self? If it's correct, can someone explain why? O did I understud
something wrong on the webpage?
Stefan
Thanks Rich,
> You should make sure the openldap-debuginfo
On track : I rolled back to simple bindmethod at this
stage and have created a dedicated proxyuser for
replication.
Once I can get this package (internal procedures...),
I'll check and come back on that issue.
Thanks,
---
Olivier
On Fri, Aug 12, 2011 at 4:14 PM, Rich Megginson
<rich.megginson(a)gmail.com> wrote:
> On 08/12/2011 07:17 AM, Olivier wrote:
>>
>> My N-WAY replication works properly with a
>> "bindmethod=simple".
>>
>> However, I don't like keeping a password in clear in
>> a configuration file, then I tryed this :
>>
>> On server "ldap-master1.example.fr" :
>>
>> TLSVerifyClient allow
>>
>> syncrepl rid=101
>> provider=ldap://ldap-master2.example.fr:389
>> searchbase="dc=example,dc=fr"
>> schemachecking=on
>> type=refreshOnly
>> interval=00:00:01:00
>> retry="10 +"
>> bindmethod=sasl
>> saslmech=EXTERNAL
>> starttls=critical
>> tls_cert=/etc/openldap/cacerts/master1/server.crt
>> tls_key=/etc/openldap/cacerts/master1/server.key
>> tls_cacert=/etc/openldap/cacerts/CA.crt
>> tls_reqcert=demand
>>
>> On server "ldap-master2.example.fr" :
>>
>> TLSVerifyClient allow
>>
>> syncrepl rid=201
>> provider=ldap://ldap-master1.example.fr:389
>> searchbase="dc=example,dc=fr"
>> schemachecking=on
>> type=refreshOnly
>> interval=00:00:01:00
>> retry="10 +"
>> bindmethod=sasl
>> saslmech=EXTERNAL
>> starttls=critical
>> tls_cert=/etc/openldap/cacerts/master2/server.crt
>> tls_key=/etc/openldap/cacerts/master2/server.key
>> tls_cacert=/etc/openldap/cacerts/CA.crt
>>
>> I get a segmentation fault :
>>
>> ldap-master1 #$ /usr/sbin/slapd -h ldap:/// -u ldap -d256
>>
>> @(#) $OpenLDAP: slapd 2.4.23 (Apr 12 2011 19:26:36) $
>>
>> mockbuild@x86-001.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd
>> bdb_monitor_db_open: monitoring disabled; configure monitor database to
>> enable
>> <= bdb_inequality_candidates: (entryCSN) not indexed
>> slapd starting
>> slap_client_connect: URI=ldap://ldap-master2.example.fr:389 Error,
>> ldap_start_tls failed (-1)
>> do_syncrepl: rid=101 rc -1 retrying
>> conn=1000 fd=12 ACCEPT from IP=10.1.92.25:47353 (IP=0.0.0.0:389)
>> conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037
>> conn=1000 op=0 STARTTLS
>> conn=1000 op=0 RESULT oid= err=0 text=
>> conn=1000 fd=12 TLS established tls_ssf=256 ssf=256
>> conn=1000 op=1 BIND dn="" method=163
>> conn=1000 op=1 BIND
>>
>> authcid="email=max(a)example.fr,cn=ldap-master2.example.fr,ou=ldap,o=example,l=somewhere,st=france,c=fr"
>>
>> authzid="email=max(a)example.fr,cn=ldap-master2.example.fr,ou=ldap,o=example,l=somewhere,st=france,c=fr"
>> conn=1000 op=1 BIND
>>
>> dn="email=max(a)example.fr,cn=ldap-master2.example.fr,ou=ldap,o=example,l=somewhere,st=france,c=fr"
>> mech=EXTERNAL sasl_ssf=0 ssf=256
>> conn=1000 op=1 RESULT tag=97 err=0 text=
>> conn=1000 op=2 SRCH base="dc=example,dc=fr" scope=2 deref=0
>> filter="(objectClass=*)"
>> conn=1000 op=2 SRCH attr=* +
>> conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text=
>> conn=1000 op=3 UNBIND
>> conn=1000 fd=12 closed
>> Erreur de segmentation
>>
>> The segfault happened when the second server tried to sync with the first
>> one :
>>
>> [root@ldap-master2 cacerts]# /usr/sbin/slapd -h ldap:/// -u ldap -d256
>> @(#) $OpenLDAP: slapd 2.4.23 (Apr 12 2011 19:26:36) $
>>
>> mockbuild@x86-001.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd
>> bdb_monitor_db_open: monitoring disabled; configure monitor database to
>> enable
>> slapd starting
>> conn=1000 fd=12 ACCEPT from IP=10.1.92.24:55208 (IP=0.0.0.0:389)
>> conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037
>> conn=1000 op=0 STARTTLS
>> conn=1000 op=0 RESULT oid= err=0 text=
>> TLS: error: accept - force handshake failure: errno 2 - moznss error -5938
>> TLS: can't accept: TLS error -5938:Encountered end of file.
>> conn=1000 fd=12 closed (TLS negotiation failure)
>> ^C
>> daemon: shutdown requested and initiated.
>> slapd shutdown: waiting for 0 operations/tasks to finish
>> slapd stopped.
>>
>> Any idea ?
>
> Can you get a core file and a stack trace from the server that gets the seg
> fault?
> I'm assuming from the build that you are running on Fedora 14 or later, or
> RHEL6.1. You should make sure the openldap-debuginfo package is installed
> (e.g. debuginfo-install openldap) and install abrt. This will collect the
> core files in /var/spool/abrt
>>
>> NOTE : if I start the daemon on ldap-master2, that's ldap-master2 that
>> produce the seg fault.
>>
>> ---
>> Olivier
>>
>
>
I've been using the Symas OpenLDAP debian packages, and following the
Quick-Start guide for 2.5:
https://www.openldap.org/doc/admin25/quickstart.html
Following steps 1 - 10 has been straight forward, but when I get to step 11
(Add initial entries to your directory), I run into trouble when running
the ldapadd command:
root@openldap-x:/opt/symas/etc/openldap# ldapadd -x -D
"cn=Manager,dc=example,dc=com" -W -f bootstrap.ldif
Enter LDAP Password:
ldap_bind: Confidentiality required (13)
additional info: confidentiality required
root@openldap-x:/opt/symas/etc/openldap#
I used the provided slapd.ldif.default to seed the cn=config (updating it
with the appropriate domain components), as per the instructions in the
Quick-Start, so slapd isn't yet configured to run with ssl or starttls. Is
there a default SSF factor that I should adjust to get past this
bootstrapping failure? I don't see anything like that explicitly set in the
configs that were rendered into /opt/symas/etc/openldap/slapd.d, from my
slapd.ldif.
I'm not new to openldap, but this is the first time I've used the Symas
packages and also the first time trying to use olc instead of a slapd.conf
based configuration.
Ben
On 10/20/21 09:43, Bastian Tweddell wrote:
> On 19Oct21 18:17+0200, Michael Ströder wrote:
>> Find below ae-slapd.service generated by Æ-DIR's ansible role.
>
>> PIDFile=/run/ae-dir/slapd/slapd.pid
>
> still need a pidfile?
Probably not.
(I'm also following the current discussion on systemd-devel list.)
>> ExecStart=/usr/lib64/slapd -d none -n ae-slapd -l LOCAL4 -s 7 -f
>> /opt/ae-dir/etc/openldap/slapd.conf -h
>> 'ldapi://%%2Frun%%2Fae-dir%%2Fslapd%%2Fldapi/????x-mod=0777 ldap://*:389
>> ldaps://*:636' -o slp=off
>
> listening plaintext on all interfaces might be discouraged.
But using StartTLS has to be possible. Æ-DIR does not allow any
clear-text connections because slapd.conf contains:
security ssf=128
>> LimitNOFILE=96
>
> this could be too low, depending on use case. it limits nr of incoming
> connections.
Yes, a deliberately slow test value, see my other answer.
Ciao, Michael.
On Mon, 28 May 2012, Michael Ströder wrote:
> Peter Marschall wrote:
> > how do the openldap tools technically verfify certificates with ldapi:// ?
>
> Which certs do you want to verify?
I assume the answer is "the one the server returns when you do StartTLS on
the ldapi:// connection".
It's pretty unusual to do that, of course. The normal solution for
authenticating the server in the ldapi case is to put the socket somewhere
that only the trusted user can write to, so you know that the socket you
connected to is trusted.
If that's not a sufficient option, and verifying certs is required, then
it appears the code will treat the socket path as the hostname to verify
for. For OpenSSL, for example, that means it'll compare it against any
DNS: subjectAltNames as well as against the last CN component of the cert
subject.
(A related question is what slapd will use as your authentication id for
SASL EXTERNAL if you do TLS with a client cert on an ldapi socket: will it
use the cert's subject or the "gidNumber=%d+uidNumber=%d,...etc" DN of the
ldapi connection. The former seems like the obvious choice, being the
"more recent" of the two in this case, and a quick look at the slapd code
would seem to confirm that...but I would test it before designing a system
to depend on it...)
Philip Guenther
Hi
I think you mean SSL connection or the STARTTLS Layer...?
Please read the manual http://www.openldap.org/doc/admin24/tls.html
And tree security:
On my server, a client user can only see his own object:
Maybe create a rule like this:
access to filter=(objectClass=simpleSecurityObject)
by self read
by * none
....
--
Raffael Sahli
public(a)raffaelsahli.com
On 11/28/2011 10:04 AM, Jayavant Patil wrote:
> Hi,
>
> I am using openLDAP-2.4.19-4 on fedora 12 machine. I want to make
> server secure from client nodes so that clients don't hack the server
> node. Hack in the sense that one client doesn't even read the data of
> another client, client doesn't tamper the server directory information
> or try to spoof the server.
>
> Does anybody have any suggestions how to avoid these things in openLDAP?
>
> Thanks in advance.
>
> --
>
> Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
--On Monday, February 04, 2013 9:16 AM +0200 Chris <chris(a)flamengro.co.za>
wrote:
> Thank you for the link. I have downloaded the newest version.
Please keep replies on the list.
> I get the following error message in my messages file when I start slapd
>
> Feb 4 09:15:53 ibm-01 slapd[25637]: [INFO] Using /etc/default/slapd for
> configuration
> Feb 4 09:15:53 ibm-01 slapd[25642]: [INFO] Launching OpenLDAP
> configuration test...
> Feb 4 09:15:53 ibm-01 nslcd[18834]: [a6c6dc] failed to bind to LDAP
> server ldaps://ibm-01: Can't contact LDAP server
> ldpasearch gives the following results
>
> ldapsearch -x -Z -b'dc=flamengro,dc=co,dc=za' uid=izak
> ldap_start_tls: Protocol error (2)
> additional info: unsupported extended operation
Are you using startTLS (extended operation) or ldaps? These are two
different things, and yet it seems you are trying to use both.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
On 07/05/2012 06:18 PM, Gavin Henry wrote:
> HI all,
>
> Taking advantage of the technical list for once and the OpenLDAP
> "related" questions :-)
>
> Anyone messed with ejabberd and OpenLDAP? I'm looking for an XMPP
> server with the best LDAP support.
>
> ejabberd does auth, rosters and vcards but the ability to load a list
> of hosts/domains from LDAP like you can do
> with Exim etc. would rule.
>
> Any suggestions?
i went through this exercise, albeit some time ago, and ultimately
settled on openfire. others i considered at the time were ejabberd,
in.jabberd, jabberd2, openfire, prosody, and tigase. none had what i
would call fantastic ldap support, but openfire came reasonably close,
and offered other benefits which outweighed the areas in which its ldap
implementation lacked. most notably, there was only support for ldaps.
no starttls. i don't recall any providing the ability to read hosts
or domains from ldap. prosody also seemed to have promise, but at the
time, it was too early in it's development stages to be used as a daily
service.
regards
-ben
On 10/14/2011 01:48 AM, Olivier Guillard wrote:
> Hi Rich
>
> as far as I remember, when I used this version :
> openldap-servers-2.4.23-15.el6_1.1.x86_64
>
> I could use external mecanism in syncrepl and was
> able to present the client certificate without asking for
> the server one.
>
> My syncrepl sections looked like this :
>
> syncrepl rid=121
> provider=ldap://ldap2.example.fr
> searchbase="dc=example,dc=fr"
> schemachecking=on
> type=refreshOnly
> interval=00:00:00:05
> retry="10 +"
> bindmethod=sasl
> saslmech=external
> tls_cert=/etc/openldap/cacerts/syncrepl.crt
> tls_key=/etc/openldap/cacerts/syncrepl.key
>
> And that worked. BTW, I'm not sure that his should have
> worked since I think normaly the protocole indicates that
> the client should check the server cert before sending its.
Yes, that's odd.
> Anyway that worked (-:
>
> With openldap-servers-2.4.23-15.el6_1.3.x86_64, I'm not
> able to use the external mecanism anymore if I don't add
> explicitely the following directives in syncrepl: "starttls=yes",
> "tls_cacert=.../cacerts/CA.crt" and "tls_reqcert=allow/try/demand"
I don't think it ever should have worked without at least specifying
starttls=yes (and assuming that didn't fallback - I think starttls=yes
is misleading, as it will just silently fallback to plain LDAP if it
doesn't establish a TLS connection - everything will seem to be working,
but unless you have set up the server to require a TLS connection, it
will just work and you won't know that it is not using TLS). I
recommend always using starttls=critical to make sure your client will
only work if TLS was successfully established.
> That works in master/slave mode, that doesn't in multimaster.
>
> Now last thing : I've never been able to make work syncrepl
> with : "starttls=yes", "tls_cacert=.../cacerts/CA.crt" and
> "tls_reqcert=allow/try/demand" in multimaster N-WAY mode
> anyway (nor now, nor before).
>
> I only made it work in master/salve and that weither using
> simple or sasl bindmethod.
>
> So the problem is not linked to sasl in my view but with
> tls in synchrepl (may be both slapd try to use the first
> TLS session opened to exchange in both direction in
> multimaster, a shared variable mixing information about
> certicates ? something like that).
Would it be possible for you to get it working with simple
binddn/password auth first, to see if that is working? Then we could at
least narrow down the problem to being related to sasl/external auth.
> I just realise that I had a core dump collected by abrtd (not
> sure if that could help nor how to use it, I'm not familiar with
> this kind of debugging) : let me know if that file could help
> (or if I could try to run any gdb command using that file).
Yes indeed that would be very helpful.
https://bugzilla.redhat.com/show_bug.cgi?id=701678#c6 has some
information about handling openldap core dumps on RHEL6
> Best,
>
> ---
> Olivier
>
> On Wed, Oct 12, 2011 at 10:25 PM, Rich Megginson
> <rich.megginson(a)gmail.com> wrote:
>> On 10/11/2011 02:38 AM, Olivier Guillard wrote:
>>> Thanks Rich, see below :
>>>
>>>> -12272 is SSL_ERROR_BAD_MAC_ALERT and -12273 is SSL_ERROR_BAD_MAC_READ
>>>> I've seen this when the client and server do not have the same SSL
>>>> certificate signature algorithm support. Is everything running on RHEL6
>>>> and/or Fedora 14 and later?
>>> [root@ldap2 ~]# cat /etc/issue
>>> Red Hat Enterprise Linux Server release 6.1 (Santiago)
>>> Kernel \r on an \m
>>>
>>> [root@ldap2 ~]# rpm -qa | grep -i openldap
>>> openldap-2.4.23-15.el6_1.3.x86_64
>>> openldap-servers-2.4.23-15.el6_1.3.x86_64
>>> openldap-debuginfo-2.4.23-15.el6_1.1.x86_64
>>> openldap-clients-2.4.23-15.el6_1.3.x86_64
>>>
>>> [root@ldap1 ~]# cat /etc/issue
>>> Red Hat Enterprise Linux Server release 6.1 (Santiago)
>>> Kernel \r on an \m
>>>
>>> [root@ldap1 ~]# rpm -qa | grep -i openldap
>>> openldap-debuginfo-2.4.23-15.el6_1.1.x86_64
>>> openldap-clients-2.4.23-15.el6_1.3.x86_64
>>> openldap-2.4.23-15.el6_1.3.x86_64
>>> openldap-servers-2.4.23-15.el6_1.3.x86_64
>>>
>>> [root@ldap2 cacerts]# rpm -qa | grep openssl
>>> openssl-1.0.0-10.el6_1.4.x86_64
>>>
>>> [root@ldap1 ldap1]# rpm -qa | grep openssl
>>> openssl-1.0.0-10.el6_1.4.x86_64
>>>
>>> Not sure if that made a difference but I "yum-updated"
>>> on last friday and openldap servers version passed :
>>>
>>> from
>>> openldap-servers-2.4.23-15.el6_1.1.x86_64
>>> to
>>> openldap-servers-2.4.23-15.el6_1.3.x86_64
>> Was it working before you yum updated?
>>> ---
>>> Olivier
>>>
>>> On Mon, Oct 10, 2011 at 9:54 PM, Rich Megginson
>>> <rich.megginson(a)gmail.com> wrote:
>>>
>>>>> here is what I get :
>>>>>
>>>>> ldap1 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync
>>>>> ...
>>>>> TLS: error: accept - force handshake failure: errno 11 - moznss error
>>>>> -12273
>>>>> TLS: can't accept: TLS error -12273:Unknown code ___P 15.
>>>>> TLS: error: connect - force handshake failure: errno 0 - moznss error
>>>>> -12272
>>>>> TLS: can't connect: TLS error -12272:Unknown code ___P 16.
>>>>> slap_client_connect: URI=ldap://ldap2.example.fr Warning,
>>>>> ldap_start_tls failed (-11)
>>>>> slap_client_connect: URI=ldap://ldap2.example.fr
>>>>> ldap_sasl_interactive_bind_s failed (-6)
>>>>> do_syncrepl: rid=121 rc -6 retrying
>>>>>
>>>>> ldap2 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync
>>>>> ...
>>>>> TLS: error: connect - force handshake failure: errno 0 - moznss error
>>>>> -12272
>>>>> TLS: can't connect: TLS error -12272:Unknown code ___P 16.
>>>>> slap_client_connect: URI=ldap://ldap1.eaxample.fr:389 Warning,
>>>>> ldap_start_tls failed (-11)
>>>>> slap_client_connect: URI=ldap://ldap1.example.fr:389
>>>>> ldap_sasl_interactive_bind_s failed (-6)
>>>>> do_syncrepl: rid=211 rc -6 retrying
>>>>> TLS: error: accept - force handshake failure: errno 11 - moznss error
>>>>> -12273
>>>>> TLS: can't accept: TLS error -12273:Unknown code ___P 15.
>>>>>
>>>>> Any idea ?
>>
