答复: 回复： mirror mode question
by 田格瑄
Hi Dieter,
Thanks for your kindly replies.
In my case, I don't use any SASL. I want to use simple bind, but my mirror mode can't work when my rootpw in hash( if the rootpw is in cleartext , the mirror mode can work). Could you pls advice what is wrong with my configration?
My slapd.conf file set as below.
moduleload syncprov.la
database bdb
suffix "dc=xxx,dc=xxx"
checkpoint 1024 15
rootdn "cn=manager,dc=xxx,dc=xxx"
rootpw {SSHA}aeiyuikahdkfjhdiuvy
directory /var/lib/ldap/xxx
access to *
by self write
by * read
# Indices to maintain for this database
index objectClass,entryCSN,entryUUID eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
serverID 1 (ldap2 service is 2)
syncrepl rid=001
provider=ldap://other side ip
bindmethod=simple
binddn="cn=manager,dc=xxx,dc=xxx"
credentials={SSHA} aeiyuikahdkfjhdiuvy
searchbase="dc=xxx,dc=xxx"
schemachecking=on
type=refreshAndPersist
retry="60 +"
mirrormode on
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
Thanks and regards
tiangexuan
-----邮件原件-----
发件人: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] 代表 Dieter Klünter
发送时间: 2014年4月8日 16:25
收件人: openldap-technical(a)openldap.org
主题: Re: 回复： mirror mode question
Hi,
If I remeber correctly, you mentioned sasl authentication. My comments on plaintext passwords are only related to sasl authentication. A sasl authentication is based on a SASL MECHANISM, as described in rfc-4422.
In order to compare the sasl authentication string with the stored password value, this has to be cleartext.
If your ldap operation is based on a simple bind, the stored password can, and should be, hashed.
-Dieter
Am Tue, 8 Apr 2014 14:16:31 +0800
schrieb 田格瑄 < <mailto:tiangexuan@sinap.ac.cn> tiangexuan(a)sinap.ac.cn>:
> Hi Michael and Dieter,
>
>
>
> I see the below mail, can I understand only the mirror mode
> replication can’t use the HASH password in rootpw, other Synchronous
> replication mode(example: syncrepl proxy) can use the HASH password?
>
>
>
> Thanks and regards
>
> tiangexuan
>
>
>
> ------------------ 原始邮件 ------------------
>
> 发件人: "Michael Ströder";<michael(a)stroeder.com
> < <mailto:michael@stroeder.com> mailto:michael@stroeder.com> >;
>
> 发送时间: 2014年3月5日(星期三) 下午4:09
>
> 收件人: "Dieter Klünter"< <mailto:dieter@dkluenter.de%20%3cmailto:dieter@dkluenter.de> dieter(a)dkluenter.de <mailto:dieter@dkluenter.de>
> >; "openldap-technical"<openldap-technical(a)openldap.org
> < <mailto:openldap-technical@openldap.org> mailto:openldap-technical@openldap.org> >;
>
> 主题: Re: mirror mode & sasl question
>
>
>
> Dieter Klünter wrote:
> > Am Wed, 5 Mar 2014 14:38:04 +0800
> > schrieb "Eileen(=^ω^=)" < <mailto:123784635@qq.com%20%3cmailto:123784635@qq.com> 123784635(a)qq.com <mailto:123784635@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.
>
>
>
--
Dieter Klünter | Systemberatung
<http://sys4.de> http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
10 years, 7 months
Issue with replication
by Jignesh Patel
We are running openldap in cluster mode with MDB setup, and we started second cluster after some time and we observe that data is non synch between those 2 servers.
So how do we synchronize the data.
> On Sep 7, 2018, at 8:00 AM, openldap-technical-request(a)openldap.org wrote:
>
> Send openldap-technical mailing list submissions to
> openldap-technical(a)openldap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.openldap.org/lists/mm/listinfo/openldap-technical
> or, via email, send a message with subject or body 'help' to
> openldap-technical-request(a)openldap.org
>
> You can reach the person managing the list at
> openldap-technical-owner(a)openldap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openldap-technical digest..."
>
>
> Send openldap-technical mailing list submissions to
> openldap-technical(a)openldap.org
> When replying, please edit your Subject: header so it is more specific than "Re: openldap-technical digest..."
>
> Today's Topics:
>
> 1. Replication issue? Data is different between master and
> consumer with same entryCSNs (Dave Steiner)
> 2. olcSecurity: tls=1 and olcLocalSSF= : what value should I
> use? (Jean-Francois Malouin)
> 3. Re: olcSecurity: tls=1 and olcLocalSSF= : what value should I
> use? (Quanah Gibson-Mount)
> 4. Re: Replication issue? Data is different between master and
> consumer with same entryCSNs (Frank Swasey)
> 5. Re: Replication issue? Data is different between master and
> consumer with same entryCSNs (Quanah Gibson-Mount)
> 6. Re: olcSecurity: tls=1 and olcLocalSSF= : what value should I
> use? (Jean-Francois Malouin)
> 7. Re: Replication issue? Data is different between master and
> consumer with same entryCSNs (Dave Steiner)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 5 Sep 2018 16:49:44 -0400
> From: Dave Steiner <steiner(a)rutgers.edu>
> To: openldap-technical(a)openldap.org
> Subject: Replication issue? Data is different between master and
> consumer with same entryCSNs
> Message-ID: <129e3614-50fe-ba15-4d4b-5f94d14abcd9(a)oit.rutgers.edu>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
>
> I've been noticing various data discrepancies between our LDAP master and LDAP
> consumers.? We are running OpenLDAP v2.4.44.? We have two masters running
> "mirromode TRUE" and all updates go through a VIP that points to the first one
> unless it's not available (doesn't happen very often except for during patches
> and restarts). We have 13 consumers that replicate through that same VIP.
>
> Here's an example of our syncrepl for a client:
>
> syncrepl rid=221
> ? type=refreshAndPersist
> ? schemachecking=on
> ? provider="ldap://ldapmastervip.rutgers.edu/"
> ? bindmethod=sasl
> ? saslmech=EXTERNAL
> ? starttls=yes
> ? tls_reqcert=demand
> ? tls_protocol_min="3.1"
> ? searchbase="dc=rutgers,dc=edu"
> ? attrs="*,+"
> ? retry="10 10 20 +"
> ? logbase="cn=accesslog"
> ? logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
> ? syncdata=accesslog
> ? network-timeout=30
> ? keepalive=180:3:60
>
> I check the contextCSN attributes on all the instances every day and they are
> all in sync (except during any major changes, of course). But I occasionally
> notice discrepancies in the data.... even though the contextCSNs and entryCSNs
> are the same.? For example (note hostnames have been changed):
>
> $ ldapsearch ... -H ldap://ldapmaster.rutgers.edu uid=XXXX postalAddress
> createTimestamp modifyTimestamp entryCSN
> dn: uid=XXXX,ou=People,dc=rutgers,dc=edu
> createTimestamp: 20121220100700Z
> postalAddress: Business And Science Bldg$227 Penn Street$Camden, NJ 081021656
> entryCSN: 20180505002024.083133Z#000000#001#000000
> modifyTimestamp: 20180505002024Z
>
> $ ldapsearch ... -H ldap://ldapconsumer3.rutgers.edu uid=XXXX postalAddress
> createTimestamp modifyTimestamp entryCSN
> dn: uid=XXXX,ou=People,dc=rutgers,dc=edu
> createTimestamp: 20121220100700Z
> postalAddress: BUSINESS AND SCIENCE BLDG$227 PENN STREET$CAMDEN, NJ 081021656
> entryCSN: 20180505002024.083133Z#000000#001#000000
> modifyTimestamp: 20180505002024Z
>
> So I'm trying to figure out why this happens (config issue, bug, ???) and
> second, if I can't use the contextCSN to report that everything is fine, what
> else can I do besides trying to compare ldif dumps.
>
> thanks,
> ds
> --
> Dave Steiner steiner(a)rutgers.edu
> IdM, Enterprise Application Services ?? ASB101; 848.445.5433
> Rutgers University, Office of Information Technology
>
>
5 years, 9 months
Re: objectclass sambaSamAccount
by Laurence Mayer
Hi Scott,
See below.
Thanks
Laurence
[root@fs1 ldap]# cat /etc/openldap/slapd.conf
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
#modulepath /usr/lib64/openldap
#moduleload back_bdb.la
#moduleload back_ldap.la
#moduleload back_ldbm.la
#moduleload back_passwd.la
#moduleload back_shell.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client
software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
access to attrs=userPassword
by self write
by anonymous auth
by * none
#access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
suffix "dc=istraresearch,dc=com"
rootdn "cn=xxxxx,dc=istraresearch,dc=com"
rootpw xxxxxxx
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/sldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
Scott Classen wrote:
> Hi Laurence,
>
> What does your sldap.conf file look like? You are probably not including
> the proper samba schema file.
>
> Scott
>
> On Sep 2, 2008, at 6:47 AM, Laurence Mayer wrote:
>
>> Hi,
>>
>> OS: Linux Redhat x86_64
>> OpenLdap 2.3.27
>>
>> I am trying to add an objectclass sambaSamAccount to my ou=People.
>> My goal would be to have both samba and posix account for each user.
>>
>> I have included the samba schema to the slapd.conf file.
>>
>> I tried adding this to a file and running ldapadd:
>>
>> dn: uid=laurence, ou=People,dc=istraresearch,dc=com
>> sambaLogonTime: 0
>> displayName: Laurence Mayer
>> sambaLMPassword: xxxxx
>> sambaPrimaryGroupSID: S-1-5-21-2447931902-1787058256-3961074038-1201
>> objectClass: sambaSamAccount
>> sambaAcctFlags: [UX ]
>> gidNumber: 100
>> sambaKickoffTime: 2147483647
>> sambaPwdLastSet: 1010179230
>> sambaSID: S-1-5-21-2447931902-1787058256-3961074038-5004
>> sambaPwdCanChange: 0
>> sambaPwdMustChange: 2147483647
>> sambaNTPassword: xxxx
>>
>>
>> However I received the error:
>> adding new entry "uid=laurence, ou=People,dc=istraresearch,dc=com"
>> ldap_add: Internal (implementation specific) error (80)
>> additional info: no structuralObjectClass operational attribute
>>
>>
>> Please can you tell me what I need to do to achieve this.
>>
>> Thanks in advance
>>
>> Laurence
--
--------------------------
Laurence Mayer
Director of Operations & IT
Istra Research Ltd.
Tel: +972545233107
Fax: +972722765124
16 years, 2 months
Re: Security between server and client nodes.
by Jayavant Patil
On Wed, 30 Nov 2011 14:18:00 +0100 Raffael Sahli <public(a)raffaelsahli.com>
wrote:
>On 11/30/2011 01:48 PM, Jayavant Patil wrote:
>
>
> >>On 11/30/2011 08:01 AM, Jayavant Patil wrote:
> >>
> >>
> >> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
> >> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>
> <mailto:jayavant.patil82@gmail.com
> <mailto:jayavant.patil82@gmail.com>>> wrote:
> >>
> >>
> >> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
> >> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>> wrote:
> >> >>Hi
> >>
> >> >>I think you mean SSL connection or the STARTTLS Layer...?
> >> >>Please read the manual http://www.openldap.org/doc/admin24/tls.html
> >> >Ok.
> >>
> >> >>And tree security:
> >> >>On my server, a client user can only see his own object:
> >> >Are you using simple authentication mechanism?
> >>
> >> >>Maybe create a rule like this:
> >> >>access to filter=(objectClass=
> >> >>simpleSecurityObject)
> >> >> by self read
> >> >> by * none
> >>
> >> >I am not getting what the ACL rule specifies. Any suggestions?
> >>
> >>
> >> I have two users ldap_6 and ldap_7. I want to restrict a user to
> >> see his own data only.
> >> In slapd.conf, I specified the rule as follows:
> >> access to *
> >> by self write
> >> by * none
> >>
> >> But ldap_6 can see the ldap_7 user entries (or vice versa) with
> >> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> >> "ou=People,dc=abc,dc=com" "uid=ldap_7"
> >>
> >> Any suggestions?
> >>
> >On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli
> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
> >Yes, that's exactly the rule I wrote above.
>
> >access to filter=(objectClass=
> >simpleSecurityObject)
> > by self read
> > by * none
>
>
> >Maybe you have to change the objectClass to posixAccount, or both or
> >whatever....
>
> >access to
> >filter=(|(objectClass=
simpleSecurityObject)(objectClass=posixAccount))
> > by self read
> > by * none
>
>
> >Just add this rule before the global rule "access to *"
>
>
> >>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> >>"ou=People,dc=abc,dc=com" "uid=ldap_7"
>
> >And if you search like this with bind "admin dn", you will see every
> >object....
> >You have to bind with user ldap_6 and not with root
> But anyway client user knows the admin dn and rootbindpassword. So,
> with this he will look into all directory information to which he is
> not supposed to do.
> e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster
>
> So, how to avoid this?
>
>Why client user knows the admin dn and pw????????
Because /etc/ldap.conf file on client contains admin dn and pw.
Each user information in the directory contains the following entries(here,
e.g. ldap_6)
dn: uid=ldap_6,ou=People,dc=abc,dc=com
uid: ldap_6
cn: ldap_6
sn: ldap_6
mail: ldap_6(a)abc.com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
objectClass: hostObject
objectClass: simpleSecurityObject
shadowLastChange: 13998
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 514
gidNumber: 514
homeDirectory: /home/ldap_6
host: *
userPassword:: e2NyeXB0fSQxJGRUb1p6bVp5JGY2VFF5UWMxNndSbjdLcHpnMUlsdS8=
So, what should be the ACL rule so that each user can see his data only? I
tried but not getting the required, even the user himself is unable to see
his own data.
--
Thanks & Regards,
Jayavant Ningoji Patil
Engineer: System Software
Computational Research Laboratories Ltd.
Pune-411 004.
Maharashtra, India.
+91 9923536030.
12 years, 11 months
Re: top-level data entries not replicating, 2.4.15, now 2.4.17
by Brian Neu
I compiled new rpms and upgraded to 2.4.17 on both the provider and consumer. The problem persists.
New entries like:
dn:cn=test2,dc=srg,dc=com
objectclass: top
objectclass: person
userpassword:blah
sn:test2
don't replicate. But other entries do, like:
dn: uid=user1,ou=People,dc=srg,dc=com
uid: user1
cn: Advanced Open Systems
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword::
shadowLastChange: 14441
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 5000
gidNumber: 5000
homeDirectory: /home/user1
gecos: Advanced Open Systems
I've attached the slapd.conf for the master/provider.
Thank you in advance for any assistance.
--- On Thu, 8/20/09, Brian Neu <proclivity76(a)yahoo.com> wrote:
> From: Brian Neu <proclivity76(a)yahoo.com>
> Subject: Re: top-level data entries not replicating, 2.4.15
> To: "Jonathan Clarke" <jonathan(a)phillipoux.net>
> Cc: openldap-technical(a)openldap.org
> Date: Thursday, August 20, 2009, 8:39 AM
> Forgive me if pasting here is bad
> etiquette.
>
>
> <consumer slapd.conf>
>
> include
> /etc/openldap/schema/corba.schema
> include
> /etc/openldap/schema/core.schema
> include
> /etc/openldap/schema/cosine.schema
> include
> /etc/openldap/schema/duaconf.schema
> include
> /etc/openldap/schema/dyngroup.schema
> include
> /etc/openldap/schema/inetorgperson.schema
> include
> /etc/openldap/schema/java.schema
> include
> /etc/openldap/schema/misc.schema
> include
> /etc/openldap/schema/nis.schema
> include
> /etc/openldap/schema/openldap.schema
> include
> /etc/openldap/schema/ppolicy.schema
> include
> /etc/openldap/schema/collective.schema
> include
> /etc/openldap/schema/samba.schema
>
> allow bind_v2
>
> pidfile
> /var/run/openldap/slapd.pid
> argsfile
> /var/run/openldap/slapd.args
>
> TLSCACertificateFile /etc/openldap/cacerts/cavictory2.crt
> TLSCertificateFile /etc/openldap/keys/victory3cert.pem
> TLSCertificateKeyFile /etc/openldap/keys/victory3key.pem
>
> database hdb
> suffix "dc=srg,dc=com"
> checkpoint 1024 15
> rootdn
> "cn=Manager,dc=srg,dc=com"
>
> rootpw {MD5}blah
>
> directory /var/lib/ldap
>
> index objectClass
> eq,pres
> index ou,cn,mail,surname,givenname
> eq,pres,sub
> index uidNumber,gidNumber,loginShell eq,pres
> index uid,memberUid
> eq,pres,sub
> index nisMapName,nisMapEntry
> eq,pres,sub
>
> syncrepl rid=0
>
> provider=ldap://victory2.srg.com:389
> bindmethod=simple
> starttls=critical
>
> binddn="cn=replicator,dc=srg,dc=com"
> credentials=blah
> searchbase="dc=srg,dc=com"
> logbase="cn=accesslog"
> schemachecking=on
> type=refreshAndPersist
> retry="60 +"
> syncdata=accesslog
>
> updateref
> ldaps://victory2.srg.com
>
> database monitor
>
> access to *
> by
> dn.exact="cn=Manager,dc=srg,dc=com" write
> by * none
>
> </consumer slapd.conf>
>
>
> --- On Thu, 8/20/09, Jonathan Clarke <jonathan(a)phillipoux.net>
> wrote:
>
> > From: Jonathan Clarke <jonathan(a)phillipoux.net>
> > Subject: Re: top-level data entries not replicating,
> 2.4.15
> > To: "Brian Neu" <proclivity76(a)yahoo.com>
> > Cc: openldap-technical(a)openldap.org
> > Date: Thursday, August 20, 2009, 8:02 AM
> > On 19/08/2009 19:29, Brian Neu
> > wrote:
> > > Even with no logfilter on the consumer,
> > >
> > cn=replicator,dc=domain,dc=com&
> > >
> > sambaDomainName=SRG,dc=domain,dc=com
> > >
> > > don't replicate, even after wiping the database
> and
> > restarting. Everything else seems to replicate
> fine.
> > >
> > > How do I get top-level data entries to
> replicate?
> >
> > This really depends on your syncrepl configuration on
> the
> > consumer.
> > If you provide it here, maybe we can take a look.
> >
> > Aside from that, the latest version, 2.4.17, contains
> a few
> > fixes that
> > might help with this problem.
> >
> > Jonathan
> >
>
15 years, 3 months
RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
This is expected to be the final testing call for 2.4.45, with an
anticipated release, depending on feedback, during the week of 2017/05/29.
For this testing call, we particularly need folks to test OpenLDAP with
startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and with
the 1.1 series). There is currenly nothing in the test suite that covers
encrypted connections (Although it's on my todo list). To build against
OpenSSL 1.1 may also require cyrus-sasl HEAD out of the cyrus-sasl GIT
repository, depending on your build options as the current cyrus-sasl
release does not support the OpenSSL 1.1 series. It can be found at
<https://github.com/cyrusimap/cyrus-sasl>. If you build with GSSAPI and
use Heimdal, you will also need the Heimdal 7.1.0 or later release (as that
is where OpenSSL 1.1 support was added). It can be obtained from
<http://h5l.org/>.
Also new with this release is the ability to run "make its" in the tests/
directory. This will run a specific set of tests around past bugs to
ensure there are no regressions. While I've tested this with modular
openldap builds, it has not been tested with the modules and backends built
into slapd, so there could be some issues in that scenario.
Generally, get the code for RE24:
<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…>
Configure & build.
Execute the test suite (via make test) after it is built. Optionally, cd
tests && make its run through the regression suite.
Thanks!
OpenLDAP 2.4.45 Engineering
Added slapd support for OpenSSL 1.1.0 series (ITS#8353, ITS#8533,
ITS#8634)
Fixed libldap to fail ldap_result if the handle is already bad
(ITS#8585)
Fixed libldap to expose error if user specified CA doesn't exist
(ITS#8529)
Fixed libldap handling of Diffie-Hellman parameters (ITS#7506)
Fixed libldap GnuTLS use after free (ITS#8385)
Fixed libldap SASL initialization (ITS#8648)
Fixed slapd bconfig rDN escape handling (ITS#8574)
Fixed slapd segfault with invalid hostname (ITS#8631)
Fixed slapd sasl SEGV rebind in same session (ITS#8568)
Fixed slapd syncrepl filter handling (ITS#8413)
Fixed slapd syncrepl infinite looping mods with delta-sync MMR
(ITS#8432)
Fixed slapd callback struct so older modules without writewait
should function.
Custom modules may need to be updated for sc_writewait
callback (ITS#8435)
Fixed slapd-ldap/meta broken LDAP_TAILQ macro (ITS#8576)
Fixed slapd-mdb so it passes ITS6794 regression test (ITS#6794)
Fixed slapd-mdb double free with size zero paged result (ITS#8655)
Fixed slapd-meta uninitialized diagnostic message (ITS#8442)
Fixed slapo-accesslog to honor pauses during purge for cn=config
update (ITS#8423)
Fixed slapo-accesslog with multiple modifications to the same
attribute (ITS#6545)
Fixed slapo-relay to correctly initialize sc_writewait (ITS#8428)
Fixed slapo-sssvlv double free (ITS#8592)
Fixed slapo-unique with empty modifications (ITS#8266)
Build Environment
Added test065 for proxyauthz (ITS#8571)
Fix test008 to be portable (ITS#8414)
Fix test064 to wait for slapd to start (ITS#8644)
Fix its4336 regression test (ITS#8534)
Fix its4337 regression test (ITS#8535)
Fix regression tests to execute on all backends (ITS#8539)
Contrib
Added slapo-autogroup(5) man page (ITS#8569)
Added passwd missing conversion scripts for apr1 (ITS#6826)
Fixed contrib modules where the writewait callback was not
correctly initialized (ITS#8435)
Fixed smbk5pwd to build with newer OpenSSL releases
(ITS#8525)
Documentation
admin24 fixed tls_cipher_suite bindconf option (ITS#8099)
admin24 fixed typo cn=config to be slapd.d (ITS#8449)
admin24 fixed slapo-syncprov information to be curent
(ITS#8253)
admin24 fixed typo in access control docs (ITS#7341,
ITS#8391)
admin24 fixed minor typo in tuning guide (ITS#8499)
admin24 fixed information about the limits option (ITS#7700)
admin24 fixed missing options for syncrepl configuration
(ITS#7700)
admin24 fixed accesslog documentation to note it should not
be replicated (ITS#8344)
Fixed ldap.conf(5) missing information on SASL_NOCANON
option (ITS#7177)
Fixed ldapsearch(1) information on the V[V] flag behavior
(ITS#7177, ITS#6339)
Fixed slapd-config(5), slapd.conf(5) clarification on
interval keyword for refreshAndPersist (ITS#8538)
Fixed slapd-config(5), slapd.conf(5) clarify serverID
requirements (ITS#8635)
Fixed slapd-config(5), slapd.conf(5) clarification on
loglevel settings (ITS#8123)
Fixed slapo-ppolicy(5) to clearly note rootdn requirement
(ITS#8565)
Fixed slapo-memberof(5) to note it is not safe to use with
replication (ITS#8613)
Fixed slapo-syncprov(5) documentation to be current
(ITS#8253)
Fixed slapadd(8) manpage to note slapd-mdb (ITS#8215)
Fixed various minor grammar issues in the man pages
(ITS#8544)
Fixed various typos (ITS#8587)
LMDB 0.9.20 Release Engineering
Fix mdb_load with escaped plaintext (ITS#8558)
Fix mdb_cursor_last / mdb_put interaction (ITS#8557)
Thanks,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
7 years, 6 months
Re: slapd.conf for proxy to AD
by Del
Just to elaborate on some of my own points below:
> Like a lot of people I guess, I'm having trouble configuring slapd to
> work as a proxy server in front of Microsoft's Active Directory. AD in
> this case is configured to refuse to allow anonymous searches but I want
> to allow anonymous searches on the proxy. Therefore the configuration
> I'm hoping for is:
>
> * Anonymous binds to slapd get translated into an authenticated bind to AD.
> * Authenticated binds to slapd have their credentials (DN and password)
> passed through to AD.
According to man slapd-ldap, which says:
idassert-bind bindmethod=none|simple|sasl [binddn=<simple DN>]
[credentials=<simple password>] [saslmech=<SASL mech>]
[secprops=<properties>] [realm=<realm>] [authcId=<authentication
ID>] [authzId=<authorization ID>] [authz={native|proxyauthz}]
[mode=<mode>] [flags=<flags>] [starttls=no|yes|critical]
[tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>]
[tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand]
[tls_ciphersuite=<ciphers>] [tls_protocol_min=<version>]
[tls_crlcheck=none|peer|all]
Allows to define the parameters of the authentication method
that is internally used by the proxy to authorize connections
that are authenticated by other databases. The identity defined
by this directive, according to the properties associated to the
authentication method, is supposed to have auth access on the
target server to attributes used on the proxy for authentication
and authorization, and to be allowed to authorize the users.
This requires to have proxyAuthz privileges on a wide set of
DNs, e.g. authzTo=dn.subtree:"", and the remote server to have
authz-policy set to to or both. See slapd.conf(5) for details
on these statements and for remarks and drawbacks about their
usage. The supported bindmethods are
So it seems that this is the parameter I want.
none|simple|sasl
where none is the default, i.e. no identity assertion is
performed.
I think I need "simple" here because I want OpenLDAP to do a simple bind (non-SASL) to AD.
...
The supported modes are:
<mode> := {legacy|anonymous|none|self}
If <mode> is not present, and authzId is given, the proxy always
authorizes that identity. <authorization ID> can be
u:<user>
[dn:]<DN>
The former is supposed to be expanded by the remote server
according to the authz rules; see slapd.conf(5) for details. In
the latter case, whether or not the dn: prefix is present, the
string must pass DN validation and normalization.
The default mode is legacy, which implies that the proxy will
either perform a simple bind as the authcDN or a SASL bind as
the authcID and assert the client’s identity when it is not
anonymous. Direct binds are always proxied. The other modes
imply that the proxy will always either perform a simple bind as
the authcDN or a SASL bind as the authcID, unless restricted by
idassert-authzFrom rules (see below), in which case the
operation will fail; eventually, it will assert some other
identity according to <mode>.
It seems to me that I want mode=legacy according to this. I want it to perform a simple bind
as some ID (VALID-BIND-DN below) when the client is anonymous, but assert the client's identity
when it is not anonymous.
I have to say that the language of the manual here is far from clear. It doesn't actually
define what is meant by "authcDN" for example, I'm only assuming that that means the "<simple
DN>" given as the argument to the binddn option of this parameter. Also it could skip the
double negatives.
However it doesn't appear to work. Any ideas?
> Here's what I have so far, based on the documentation. I'm using
> slapd.conf rather than the new conf.d directory based config, and I'm
> currently running openldap 2.4.19:
>
> --
> database ldap
> chase-referrals no
> suffix "MY-AD-SUFFIX-HERE"
> uri "ldaps://MY-AD-SERVER-HERE/"
> cancel abandon
>
> acl-bind bindmethod=simple binddn="VALID-BIND-DN"
> credentials="VALID-PASSWORD"
>
> idassert-bind bindmethod=simple binddn="VALID-BIND-DN
> credentials="VALID-PASSWORD" mode=legacy flags=non-prescriptive
>
> idassert-authzFrom "dn.regex:.*"
>
> access to * by * read
> --
>
> You can assume I've used valid bind DNs, suffixes, server names and
> passwords in the places where I've resorted to capitals above. I've
> tested these binds from the command line directly against the AD server
> and they all work.
>
> I have tested the above on OpenLDAP 2.3, it works for anonymous binds if
> and only if a successful authenticated bind is done first. The same was
> reported in this post:
>
> http://www.openldap.org/lists/openldap-technical/200907/msg00043.html
>
> In OpenLDAP 2.4 it fails to recognise the idassert-bind completely, all
> attempts at anonymous bind seem to fail. A similar problem was reported
> while upgrading to 2.3.11 to 2.3.27, here:
>
> http://www.openldap.org/lists/openldap-software/200701/msg00055.html
>
> Am I using the correct configuration directives to achieve what I want,
> and if not what should I be using?
>
> Thanx,
>
--
Del
13 years, 9 months
ACL doesn't work on my Centos 6
by Dong Xi
Hi,
Just set up openldap on my CentOS 6.5. Looks like very easy to set up. And
it is working. However, I found ACL doesn't work as expected. I am trying
to disable read access to anonymous, and give userPassword write access to
self and binduser. But it doesn't work: anonymous can still read whole ldap
entries, and no one except cn=Manager,dc=domain,dc=com can change
userPassword. I even change following section to access to * by * none to
lock down ldap, but still anonymous can read all.
===
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to attrs=userPassword
by self write
by dn.exact="cn=binduser,dc=domain,dc=com" write
by users read
by anonymous auth
access to *
by users read
by anonymous auth
===
to
===
access to * by * none
===
Here is the complete slapd.conf. Look like only default ACL works, whatever
ACL policy I am trying to apply. Please help.
slapd.conf
====
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules
# - modulepath is architecture dependent value (32/64-bit system)
# - back_sql.la overlay requires openldap-server-sql package
# - dyngroup.la and dynlist.la cannot be used at the same time
# modulepath /usr/lib/openldap
# modulepath /usr/lib64/openldap
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload back_sql.la
# moduleload chain.la
# moduleload collect.la
# moduleload constraint.la
# moduleload dds.la
# moduleload deref.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload memberof.la
# moduleload pbind.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload seqmod.la
# moduleload smbk5pwd.la
# moduleload sssvlv.la
# moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by running
# /usr/libexec/openldap/generate-server-cert.sh. Your client software may
balk
# at self-signed certificates, however.
#TLSCACertificatePath /etc/openldap/certs
#TLSCertificateFile "\"OpenLDAP Server\""
#TLSCertificateKeyFile /etc/openldap/certs/password
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
#access to dn.base="" by * read
#access to dn.base="cn=Subschema" by * read
#access to *
# by self write
# by users read
# by anonymous auth
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to attrs=userPassword
by self write
by dn.exact="cn=binduser,dc=domain,dc=com" write
by users read
by anonymous auth
access to *
by users read
by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
# enable on-the-fly configuration (cn=config)
database config
access to *
by * none
# enable server status monitoring (cn=monitor)
database monitor
access to *
by * none
#######################################################################
# database definitions
#######################################################################
database bdb
suffix "dc=domain,dc=com"
checkpoint 1024 15
rootdn "cn=Manager,dc=domain,dc=com"
rootpw {SSHA}f3F8TAj9BihNSUtVdMyqrvlcIoawHDgb
loglevel 256
sizelimit unlimited
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
#rootpw {SSHA}f3F8TAj9BihNSUtVdMyqrvlcIoawHDgb
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
10 years, 3 months
Re: slapd-meta
by Fr3ddie
On 04/03/2016 20:33, Quanah Gibson-Mount wrote:
>
>> Then I modified the ldif file in order to create the meta-DB and its
>> sub-DBs
>> containing the URIs of the target servers (if I correctly understood):
>>
>> version: 1
>>
>> dn: olcDatabase={3}meta,cn=config
>> objectClass: olcDatabaseConfig
>> objectClass: olcMetaConfig
>> olcDatabase: {3}meta
>> olcSuffix: dc=loc1,dc=root
>> olcSuffix: dc=loc2,dc=root
>> olcSuffix: dc=loc3,dc=root
>
> I've never used meta backend, but the above doesn't look valid to me
> (multiple suffixes). The man page shows a single suffix, with URI
> directives for additional representations of the DB.
>
> [OMISSIS]
> The slapd-meta test suit shows an additional parameter, mode=self,
> being set. That may or may not help. ;)
Hello,
I performed further testing but I have no good news :(
about the multiple "olcSuffix" I'm inserting into the
"olcDatabase={3}meta" (I don't know where I'm supposed to put
multiple entries of the olcSuffix except the olcDatabase since it is an
attribute of olcDatabaseConfig objectclass),
I configured the meta backend with just one DB suffix and just one
target, in order to keep it easy and avoid,
as much as possible, my configuration mistakes. I believe this is the
configuration I would have been supposed to
do in order to properly configure the slapd-/ldap/ backend (?).
Moreover, although I tried both "mode=self", "mode=none" and
"authzID="dn:cn=admin,dc=loc1,dc=root""
(and "flags=non-prescriptive" too, while without the "authzID" of
course), the result is the same.
Logs from the slapd-meta equipped server report (I'm simply trying to
directly access the admin dn):
Mar 4 19:50:59 server01 slapd[28946]: conn=1160 op=11 SRCH
base="cn=admin,dc=loc1,dc=root" scope=0 deref=0 filter="(objectClass=*)"
Mar 4 19:50:59 server01 slapd[28946]: conn=1160 op=11 SRCH
attr=hasSubordinates objectClass
Mar 4 19:50:59 server01 slapd[28946]: conn=1160 op=11
meta_search_dobind_init[0] mc=0x7175f3e8: non-empty dn with empty cred;
binding anonymously
Mar 4 19:50:59 server01 slapd[28946]: conn=1160 op=11 SEARCH RESULT
tag=101 err=0 nentries=0 text=
and from the target server:
Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 fd=59 ACCEPT from
IP=10.0.x.55:51909 (IP=10.0.y.85:389)
Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 op=0 BIND
dn="cn=admin,dc=loc1,dc=root" method=128
Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 op=0 RESULT tag=97
err=53 text=unauthenticated bind (DN with no password) disallowed
Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 op=1 UNBIND
Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 fd=59 closed
Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 fd=59 closed
thus the target server refuses unauthenticated bind and closes the
connection (as it is configured to do so).
Moreover, if I try to put double quotes around the "binddn" directive it
seems that slapd-meta doesn't recognize at all
the dn I'm trying to use to bind to the target, and the target server's
log reports:
Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 fd=58 ACCEPT from
IP=10.0.x.55:49353 (IP=10.0.y.85:389)
Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 op=0 BIND dn="" method=128
Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 op=0 RESULT tag=97
err=0 text=
Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 op=1 SEARCH RESULT
tag=101 err=123 nentries=0 text=anonymous proxied authorization not allowed
Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 op=1 do_search:
get_ctrls failed
Just to be complete, this is (one of) the configurations I'm trying:
dn: olcMetaSub={0}uri
objectClass: olcConfig
objectClass: olcMetaTargetConfig
olcMetaSub: {0}uri
olcDbURI: "ldap://server01.loc1.root/dc=loc1,dc=root"
olcDbIDAssertBind: mode=self bindmethod=simple
binddn=cn=admin,dc=loc1,dc=root credentials=xxxxxxx starttls=no
authzID="dn:cn=admin,dc=loc1,dc=root"
while the rest of the configuration stayed the same as the one from my
first mail.
At this point I'm really stuck and the only thing I can think of it is
the presence of a bug somewhere into slapd-meta,
since the behaviour doesn't reflect the configuration on, somehow
simple, parameters.
Is there anybody having the same issues?
Is it still my fault on configuration?
I really don't know where to put my hands on...
Thanks for support
--
Fr3ddie
/fr3ddie(a)fr3ddie.it <mailto:fr3ddie@fr3ddie.it>/
A computer is like an air conditioner:
it stops working when you open Windows
8 years, 8 months
Re: Syncrepl over TLS for mirrormode
by Daniel Qian
Yes I wasn't aware of subjectAltName and I am still not sure if nss_ldap
in the OS honors that but I will test it out. Thanks Chris for answering
back.
On 11-08-27 4:23 PM, Chris Jacobs wrote:
> Apologies for taking a while (and top posting - blackberry).
>
> 1)I setup the mirror-mode servers behind a VIP (named ldapmaster1 &
> 2). VIP hosted on an F5 BigIP - which doesn't load balance StartTLS -
> which was fine by us - all 389 connections are insecure and all 686
> (?) are secure.
> 2) I created a cert via a CA trusted on all my client machines with:
> 2.A) Subject: ldap-vip.[domain]
> 2.B) subjectAltName(s): ldapmaster1.[domain], ldapmaster2.[domain],
> ldap-vip.[domain]
>
> (Subject included in alt name list as some clients - like firefox -
> ignore the subject if alt names exist - dumb IMNSHO.)
>
> Then the servers use the same cert to sync w/ each other as the
> clients use to connect to the VIP (or if needed, directly to the
> ldapmaster servers).
>
> The subjectAltName part of a cert is the 'tricky' part I think you're
> missing knowledge of.
>
> A wildcard cert works too, but then it'd be valid for any host
> *.[domain]. Not the most secure setup.
>
> - chris
>
> Chris Jacobs, Systems Administrator, Technology Services Group
> Apollo Group | Apollo Marketing and Product Development | Aptimus, Inc.
> 2001 6th Ave | Suite 3200 | Seattle, WA 98121
> direct 206.839.8245 | cell 206.601.3256 | fax 206.839.8106
> email chris.jacobs(a)apollogrp.edu
>
> ------------------------------------------------------------------------
> *From*: Daniel Qian <daniel(a)up247solution.com>
> *To*: Chris Jacobs
> *Cc*: 'openldap-technical(a)openldap.org' <openldap-technical(a)openldap.org>
> *Sent*: Fri Aug 26 13:35:10 2011
> *Subject*: Re: Syncrepl over TLS for mirrormode
>
> Still not sure how you did it. Are you saying you set the same
> certificate in slapd and played with DNS to make it look like only one
> server(URL) to everyone?
>
> Thanks,
> Daniel
>
> On 11-08-26 4:03 PM, Chris Jacobs wrote:
>> What I did:
>> * setup servers behind VIP
>> * obtain cert with primary name of vip DNS w/ secondary names of the
>> servers.
>>
>> That way, the servers can sync/tryst each other via the same cert
>> used by clients.
>>
>> Note: some clients (lookin at you Firefox) won't use the primary name
>> if subjectaltname exists - so include primary name in the alt names JIC.
>>
>> - chris
>>
>> Chris Jacobs, Systems Administrator, Technology Services Group
>> Apollo Group | Apollo Marketing and Product Development� |�
>> Aptimus, Inc.
>> 2001 6th Ave� |� Suite 3200� |� Seattle, WA 98121
>> direct 206.839.8245� |� cell 206.601.3256� |� fax 206.839.8106
>> email chris.jacobs(a)apollogrp.edu
>>
>> ------------------------------------------------------------------------
>> *From*: openldap-technical-bounces(a)OpenLDAP.org
>> <openldap-technical-bounces(a)OpenLDAP.org>
>> *To*: openldap-technical(a)openldap.org <openldap-technical(a)openldap.org>
>> *Sent*: Fri Aug 26 12:49:04 2011
>> *Subject*: Syncrepl over TLS for mirrormode
>>
>> From the openldap website the two nodes have to use different URLs
>> like below:
>>
>> syncrepl rid=001
>> provider=ldap://ldap-sid2.example.com
>> bindmethod=simple
>> binddn="cn=mirrormode,dc=example,dc=com"
>> credentials=mirrormode
>> searchbase="dc=example,dc=com"
>> schemachecking=on
>> type=refreshAndPersist
>> retry="60 +"
>> and
>> syncrepl rid=001
>> provider=ldap://ldap-sid1.example.com
>> bindmethod=simple
>> binddn="cn=mirrormode,dc=example,dc=com"
>> credentials=mirrormode
>> searchbase="dc=example,dc=com"
>> schemachecking=on
>> type=refreshAndPersist
>> retry="60 +"
>>
>> I can set two different certificates so that TLS is fine for sync
>> between the two nodes. However we will have regular Ldap client
>> access these two nodes behind a loadbalancer over TLS too. Obviously
>> the client can't connect with ldap-sid2.example.com, nor with
>> ldap-sid1.example.com. So what is the solution to this scenario?
>> Setup a pool of consumers with same hostname?
>>
>> Thanks,
>> Daniel
>>
>> ------------------------------------------------------------------------
>> This message is private and confidential. If you have received it in
>> error, please notify the sender and remove it from your system.
>>
>
>
> ------------------------------------------------------------------------
> This message is private and confidential. If you have received it in
> error, please notify the sender and remove it from your system.
>
13 years, 2 months