N-Way Multi-Master TLS problem
by Patrick Lists
Hi,
As an exercise I tried setting up a 2 node N-Way Multi-Master with TLS
and TLS replication based on section 18.3.3 of the Admin Gguide. I
bumped into a problem that I haven't been able to fix. The error is:
TLS: hostname (ldap02.local) does not match common name in certificate
(ldap01.local).
51f87d48 slap_client_connect: URI=ldap://ldap02.local Error,
ldap_start_tls failed (-11
I have tested the certificates manually and I can't see anything wrong
with them. I use FQDNs everywhere. Also it seems odd that, based on
strace slapd output, ldap01 needs acess to the public and private
certificate of ldap02 and vice versa.
OpenLDAP version 2.4.35 + fixes recommended by Quanah on the list.
Ntp is running, iptables & SELinux are off
The config below is added with:
slapadd -v -F /etc/openldap-2.4/slapd.d -l ./test.ldif -n 0
Anyone have a hint what I am doing wrong?
-------------------------------------------------------------------
Config ldap01:
-------------------------------------------------------------------
# global configuration settings
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/openldap-2.4/slapd-2.4.args
olcPidFile: /var/run/openldap-2.4/slapd-2.4.pid
olcLogFile: /var/log/openldap-2.4/slapd-2.4.log
olcLogLevel: 127 16384
olcTLSCACertificateFile: /etc/pki/tls/certs/Test-CA.crt
olcTLSCertificateFile: /etc/pki/tls/certs/ldap01.local.crt
olcTLSCertificateKeyFile: /etc/pki/tls/private/ldap01.local.key.crt
olcTLSVerifyClient: demand
olcLocalSSF: 256
olcSecurity: ssf=256
olcPasswordCryptSaltFormat: $6$%s
olcPasswordHash: {CRYPT}
olcServerID: 1 ldap://ldap01.local
olcServerID: 2 ldap://ldap02.local
# load modules
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/local/lib64/openldap-2.4
olcModuleLoad: back_mdb.la
olcModuleLoad: back_monitor.la
olcModuleload: syncprov.la
# schema definitions
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
# include the schemas
include: file:///etc/openldap-2.4/schema/core.ldif
include: file:///etc/openldap-2.4/schema/corba.ldif
include: file:///etc/openldap-2.4/schema/cosine.ldif
include: file:///etc/openldap-2.4/schema/duaconf.ldif
include: file:///etc/openldap-2.4/schema/dyngroup.ldif
include: file:///etc/openldap-2.4/schema/inetorgperson.ldif
include: file:///etc/openldap-2.4/schema/java.ldif
include: file:///etc/openldap-2.4/schema/misc.ldif
include: file:///etc/openldap-2.4/schema/nis.ldif
include: file:///etc/openldap-2.4/schema/openldap.ldif
include: file:///etc/openldap-2.4/schema/ppolicy.ldif
include: file:///etc/openldap-2.4/schema/collective.ldif
# global database parameters
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
# setup cn=config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcRootPW: {CRYPT}$6$<somepass>
olcSyncrepl: rid=1 provider=ldap://ldap01.local
searchbase="cn=config" type=refreshAndPersist timeout=1
schemachecking=off interval=00:00:00:5 retry="5 +"
bindmethod=simple binddn="cn=config" credentials=password
starttls=critical tls_cert=/etc/pki/tls/certs/config.crt
tls_key=/etc/pki/tls/private/config.key.crt
tls_cacert=/etc/pki/tls/certs/Test-CA.crt
tls_reqcert=demand
olcSyncrepl: rid=2 provider=ldap://ldap02.local
searchbase="cn=config" type=refreshAndPersist timeout=1
schemachecking=off interval=00:00:00:5 retry="5 +" bindmethod=simple
binddn="cn=config" credentials=1234 starttls=critical
tls_cert=/etc/pki/tls/certs/config.crt
tls_key=/etc/pki/tls/private/config.key.crt
tls_cacert=/etc/pki/tls/certs/Test-CA.crt
tls_reqcert=demand
olcMirrorMode: TRUE
olcAccess: to *
by dn.exact="cn=Manager,dc=local" write
by * none
# setup monitoring
dn: olcDatabase={1}monitor,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMonitorConfig
olcDatabase: monitor
olcAccess: to dn.subtree=cn=Monitor
by dn.exact="cn=Manager,dc=local" write
by * none
dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcSuffix: dc=local
olcRootDN: cn=Manager,dc=local
olcRootPW: {CRYPT}$6$<somepass>
olcDbDirectory: /var/lib/ldap-2.4/local
olcDbIndex: cn pres,eq,sub
olcDbIndex: gidNumber pres,eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: memberUid pres,eq
olcDbIndex: objectClass pres,eq
olcDbIndex: ou pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: uid pres,eq
olcDbIndex: uidNumber pres,eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbMaxReaders: 0
olcDbMode: 0600
olcDbSearchStack: 16
# size in bytes - 1GB = 1073741824 bytes
olcDbMaxSize: 5368709120
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbNoSync: FALSE
olcSizeLimit: unlimited
olcTimeLimit: unlimited
olcDbEnvFlags: writemap
olcDbEnvFlags: nometasync
olcAccess: to attrs=userPassword
by dn.exact="cn=Manager,dc=local" write
by self write
by anonymous auth
by * none
olcAccess: to *
by dn.exact="cn=Manager,dc=local" write
by self write
by * read
olcLimits: dn.exact="cn=Manager,dc=local" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcSyncrepl: rid=3 provider=ldap://ldap01.local
searchbase="dc=local" type=refreshAndPersist timeout=1
schemachecking=off interval=00:00:00:5 retry="5 +"
bindmethod=simple binddn="cn=Manager,dc=local"
credentials=password
starttls=critical
tls_cert=/etc/pki/tls/certs/Manager.crt
tls_key=/etc/pki/tls/private/Manager.key.crt
tls_cacert=/etc/pki/tls/certs/Test-CA.crt
tls_reqcert=demand
olcSyncrepl: rid=4 provider=ldap://ldap02.local
searchbase="dc=local" type=refreshAndPersist timeout=1
schemachecking=off interval=00:00:00:5 retry="5 +"
bindmethod=simple binddn="cn=Manager,dc=local"
credentials=password
starttls=critical
tls_cert=/etc/pki/tls/certs/Manager.crt
tls_key=/etc/pki/tls/private/Manager.key.crt
tls_cacert=/etc/pki/tls/certs/Test-CA.crt
tls_reqcert=demand
olcMirrorMode: TRUE
# add the syncprov overlay to the cn=config database
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
# add the syncprov overlay to the main mdb database
dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
-------------------------------------------------------------------
Config ldap02:
-------------------------------------------------------------------
# global configuration settings
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/openldap-2.4/slapd-2.4.args
olcPidFile: /var/run/openldap-2.4/slapd-2.4.pid
olcLogFile: /var/log/openldap-2.4/slapd-2.4.log
olcLogLevel: 127 16384
olcTLSCACertificateFile: /etc/pki/tls/certs/Test-CA.crt
olcTLSCertificateFile: /etc/pki/tls/certs/ldap01.local.crt
olcTLSCertificateKeyFile: /etc/pki/tls/private/ldap01.local.key.crt
olcTLSCipherSuite: TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:!RC4:@STRENGTH
olcTLSVerifyClient: demand
olcLocalSSF: 256
olcSecurity: ssf=256
olcPasswordCryptSaltFormat: $6$%s
olcPasswordHash: {CRYPT}
olcServerID: 1 ldap://ldap01.local
olcServerID: 2 ldap://ldap02.local
# load modules
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/local/lib64/openldap-2.4
olcModuleLoad: back_mdb.la
olcModuleLoad: back_monitor.la
olcModuleLoad: memberof.la
olcModuleLoad: refint.la
olcModuleLoad: auditlog.la
olcModuleLoad: ppolicy.la
olcModuleload: syncprov.la
# schema definitions
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
# include the schemas
include: file:///etc/openldap-2.4/schema/core.ldif
include: file:///etc/openldap-2.4/schema/corba.ldif
include: file:///etc/openldap-2.4/schema/cosine.ldif
include: file:///etc/openldap-2.4/schema/duaconf.ldif
include: file:///etc/openldap-2.4/schema/dyngroup.ldif
include: file:///etc/openldap-2.4/schema/inetorgperson.ldif
include: file:///etc/openldap-2.4/schema/java.ldif
include: file:///etc/openldap-2.4/schema/misc.ldif
include: file:///etc/openldap-2.4/schema/nis.ldif
include: file:///etc/openldap-2.4/schema/openldap.ldif
include: file:///etc/openldap-2.4/schema/ppolicy.ldif
include: file:///etc/openldap-2.4/schema/collective.ldif
# global database parameters
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
# setup cn=config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcRootPW: {CRYPT}$6$<somepass>
olcSyncrepl: rid=1 provider=ldap://ldap01.local
searchbase="cn=config" type=refreshAndPersist timeout=1
schemachecking=off interval=00:00:00:5 retry="5 +"
bindmethod=simple binddn="cn=config" credentials=password
starttls=critical tls_cert=/etc/pki/tls/certs/config.crt
tls_key=/etc/pki/tls/private/config.key.crt
tls_cacert=/etc/pki/tls/certs/Test-CA.crt
tls_reqcert=demand
olcSyncrepl: rid=2 provider=ldap://ldap02.local
searchbase="cn=config" type=refreshAndPersist timeout=1
schemachecking=off interval=00:00:00:5 retry="5 +" bindmethod=simple
binddn="cn=config" credentials=1234 starttls=critical
tls_cert=/etc/pki/tls/certs/config.crt
tls_key=/etc/pki/tls/private/config.key.crt
tls_cacert=/etc/pki/tls/certs/Test-CA.crt
tls_reqcert=demand
olcMirrorMode: TRUE
olcAccess: to *
by dn.exact="cn=Manager,dc=local" write
by * none
# setup monitoring
dn: olcDatabase={1}monitor,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMonitorConfig
olcDatabase: monitor
olcAccess: to dn.subtree=cn=Monitor
by dn.exact="cn=Manager,dc=local" write
by * none
# add the syncprov overlay to the cn=config database
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
Thank you for any pointers.
Regards,
Patrick
11 years, 3 months
Re: syncrepl failing with ldap_start_tls failed (-11)
by Rich Megginson
On Sat, Jan 28, 2012 at 4:38 AM, Iain Georgeson
<iain.georgeson(a)kaust.edu.sa> wrote:
> Hello,
>
> * Summary:
>
> I'm trying to set up syncrepl in my LDAP infrastructure. The logs on
> my consumer show that syncrepl is failing to negotiate TLS when
> connecting to the provider. Other LDAP commands such as ldapsearch and
> sssd show no problem connecting using the same TLS configuration.
>
> At this point, I don't have a good idea of how to continue debugging
> this problem. Are there any more configuration items affecting TLS I
> should be looking at? Or any way of getting more details on the TLS
> nagotiation?
There were a few moznss TLS issues fixed between 2.4.23-15 and
2.4.23-20 in RHEL 6.2 (back ported from openldap upstream
2.4.24-2.4.28)
I don't know how far behind SL is compared to RHEL but if you can, try
with openldap 2.4.23-20
>
>
> * The provider ("auth-00.[MYDOMAIN]"):
>
> slapd 2.4.23 from openldap-servers-2.4.23-15.el6.x86_64 on Scientific
> Linux 6. TLS is configured with
>
> [cn=config]
> olcTLSCACertificateFile: /etc/ssl/[MYCA].pem
> olcTLSCertificateFile: /etc/ssl/certs/auth-00.crt.pem # Has
> CN=auth-00.[MYDOMAIN]
> olcTLSCertificateKeyFile: /etc/ssl/private/auth-00.key.pem
> olcTLSVerifyClient: never
>
> If I try:
> $ ldapsearch -ZZ -x -H ldap://auth-00.[MYDOMAIN]/ uid=iain
> it connects and cheerfully returns objects
>
>
> * The provider ("auth-01.MYDOMAIN"):
>
> Same slapd version, same package, same OS. syncrepl configuration:
>
> olcSyncrepl: rid=001 provider=ldap://auth-00.[MYDOMAIN]:389
> bindmethod=simple timeout=0
> network-timeout=0 binddn="cn=syncrepl,dc=[MYDOMAIN]"
> credentials="[MYPASSWORD]"
> keepalive=0:0:0 filter="(objectClass=*)" searchbase="dc=[MYDOMAIN]" scope=sub
> schemachecking=off type=refreshAndPersist retry="10 3 120 5 600 +"
> starttls=critical
> tls_cacert=/etc/ssl/MYCA.pem
>
>
> * The error
>
> Consumer:
> Jan 28 11:53:12 auth-01 slapd[5595]: slapd starting
> Jan 28 11:53:12 auth-01 slapd[5595]: slap_client_connect:
> URI=ldap://auth-00.[MYDOMAIN]:389 Error, ldap_start_tls failed (-11)
> Jan 28 11:53:13 auth-01 slapd[5595]: do_syncrepl: rid=001 rc -11
> retrying (2 retries left)
>
> Provider receiving syncrepl connection:
> Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 fd=32 ACCEPT from
> IP=[AUTH-01'S IP]:42669 (IP=0.0.0.0:389)
> Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 op=0 EXT
> oid=1.3.6.1.4.1.1466.20037
> Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 op=0 STARTTLS
> Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 op=0 RESULT oid= err=0 text=
> Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 fd=32 closed (TLS
> negotiation failure)
>
> Provider receiving ldapsearch connection:
> Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 fd=103 ACCEPT from
> IP=[AUTH-01'S IP]:42765 (IP=0.0.0.0:389)
> Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=0 EXT
> oid=1.3.6.1.4.1.1466.20037
> Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=0 STARTTLS
> Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=0 RESULT oid= err=0 text=
> Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 fd=103 TLS established
> tls_ssf=256 ssf=256
> Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=1 BIND [...]
>
>
> Thanks,
>
> Iain.
>
> --
> Systems Engineer
> KAUST Visualisation Laboratory
>
12 years, 9 months
syncrepl failing with TLS negotiation failure
by Iain Georgeson
Hello,
I'm trying to get syncrepl working, using simple bind over TLS. TLS is
failing with
Consumer:
Oct 12 17:21:53 auth-01 slapd[23241]: slap_client_connect:
URI=ldap://auth-00.vis.kaust.edu.sa Error, ldap_start_tls failed (-11)
Oct 12 17:21:53 auth-01 slapd[23241]: do_syncrepl: rid=000 rc -11
retrying (3 retries left)
Provider:
Oct 12 17:21:53 auth-00 slapd[7190]: conn=451 fd=137 ACCEPT from
IP=109.171.138.17:39458 (IP=0.0.0.0:389)
Oct 12 17:21:53 auth-00 slapd[7190]: conn=451 op=0 STARTTLS
Oct 12 17:21:53 auth-00 slapd[7190]: conn=451 op=0 RESULT oid= err=0 text=
Oct 12 17:21:53 auth-00 slapd[7190]: conn=451 fd=137 closed (TLS
negotiation failure)
TLS is working for other uses of the server including ldapsearch:
auth-01$ ldapsearch -ZZ -x -D cn=syncrepl,dc=vis,dc=kaust,dc=edu,dc=sa
-W -H ldap://auth-00.vis.kaust.edu.sa uid=iain
Oct 12 17:23:58 auth-00 slapd[7190]: conn=466 fd=137 ACCEPT from
IP=109.171.138.17:39460 (IP=0.0.0.0:389)
Oct 12 17:23:58 auth-00 slapd[7190]: conn=466 op=0 STARTTLS
Oct 12 17:23:58 auth-00 slapd[7190]: conn=466 op=0 RESULT oid= err=0 text=
Oct 12 17:23:58 auth-00 slapd[7190]: conn=466 fd=137 TLS established
tls_ssf=256 ssf=256
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=1 BIND
dn="cn=syncrepl,dc=vis,dc=kaust,dc=edu,dc=sa" method=128
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=1 BIND
dn="cn=syncrepl,dc=vis,dc=kaust,dc=edu,dc=sa" mech=SIMPLE ssf=0
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=1 RESULT tag=97 err=0 text=
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=2 SRCH
base="dc=vis,dc=kaust,dc=edu,dc=sa" scope=2 deref=0
filter="(uid=iain)"
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=2 ENTRY
dn="uid=iain,ou=people,dc=vis,dc=kaust,dc=edu,dc=sa"
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=2 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=3 UNBIND
Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 fd=137 closed
and any number of clients are cheerfully using it through
{pam,nss}_ldap and sssd.
I'm not sure where to attack this from. The TLS settings should be
identical. Any thoughts on how to proceed would be appreciated.
consumer:
$ lsb_release -a
LSB Version: :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: Scientific
Description: Scientific Linux release 6.1 (Carbon)
Release: 6.1
Codename: Carbon
$ rpm -q openldap-servers
openldap-servers-2.4.23-15.el6.x86_64
>From slapd.conf:
syncrepl rid=000
provider=ldap://auth-00.vis.kaust.edu.sa
searchbase=dc=vis,dc=kaust,dc=edu,dc=sa
bindmethod=simple
binddn=cn=syncrepl,dc=vis,dc=kaust,dc=edu,dc=sa
credentials=mysecret
type=refreshOnly
retry="10 3 120 5 600 +"
tls_cacert=/etc/ssl/VisLabCA.pem
tls_reqcert=allow
starttls=critical
provider:
$ lsb_release -a
LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 5.6 (Final)
Release: 5.6
Codename: Final
$ rpm -q openldap-servers
openldap-servers-2.3.43-12.el5_5.3
Iain.
--
Systems Engineer
KAUST Visualisation Laboratory
13 years, 1 month
Re: ssf settings for SASL and TLS
by Michael Ströder
Dieter Klünter wrote:
> Am Thu, 18 Feb 2016 22:20:16 -0700
>> Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 ACCEPT from
>> IP=10.1.10.12:55750 (IP=0.0.0.0:389) Feb 18 22:19:04 baneling
>> slapd[22171]: conn=1005 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Feb 18
>> 22:19:04 baneling slapd[22171]: conn=1005 op=0 STARTTLS Feb 18
>> 22:19:04 baneling slapd[22171]: conn=1005 op=0 RESULT oid= err=0
>> text= Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 TLS
>> established tls_ssf=256 ssf=256
> [...]
>
> You still have a overall security ssf=256 and it seems your TLS session
> used a key length lower than 256 bit, check your TLS configuration.
Dieter, the log lines say: tls_ssf=256
=> TLS seems to be ok.
Ciao, Michael.
8 years, 9 months
Antw: RE: Syncrepl and mmr
by Ulrich Windl
>>> "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> schrieb am
19.02.2014 um 20:20 in Nachricht
<201402191921.s1JJL9q9079356(a)boole.openldap.org>:
> Thanks Quanah for your reply. It answered a lot of questions.
>
> I took a back step, and slapcat'd all my cn=configs and main_dbase from
> all three servers, then ran slapadd to put each into place. Taking one of
> the cn=configs (using mm-server2's) I modified it for each server pretty much
> based on your suggestions below to set up Syncreplication with mm-server1 as
> the master (right now). When I brought them up, they were replicating (I was
> so happy!) --> any change I made on mm-server1 was immediately replicated over to
> mm-server2 and 3.
>
> I did learn a great deal over the last week or so. Patience being one of
> them. I will forward to you in a separate email my cn=configs.
>
> When running slapadd, I did run into this error (which I resolved -- but am
> curious about) on mm-server1:
>
> First had this (mm-server1):
> 5304e1ff olcMirrorMode: value #0: <olcMirrorMode> database is not a shadow
> slapadd: could not add entry dn=olcDatabase={1}bdb,cn=config (line=2260)
Shouldn't it be like:
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
>
> Resolution: set olcMirrorMode to FALSE (made this change on the other
> servers' ldifs)
>
> This caused an error when, later, running ldapmodify on the main dbase when
> all servers were running slapd.
>
> ldap_modify: server unwilling to perform (53)
> additional info: shadow context: no update referral
>
> Resolution: Removed olcMirrorMode from all ldifs.
>
> Why, even with it set to FALSE, would MirrorMode cause this issue?
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
> Sent: Wednesday, February 19, 2014 2:02 PM
> To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
> Subject: RE: Syncrepl and mmr
>
> Hi John,
>
> SIDs (server IDs) must be unique across servers.
>
> RIDs (replication IDs) must be unique inside a single server.
>
> So the answer to your question is essentially "no".
>
> If you email me your full cn=config db bits from both servers (minus
> passwords), there's some cleanup on them I can send back.
>
> The serverID: 1 <URI> bit is only necessary if you are doing cn=config
> replication, which you are not doing. If you are going to use the <#> <URI>
> form, then the <URI> must EXACTLY MATCH the arguments slapd is being started
> with.
>
> Personally, since I do not do cn=config replication, and the URIs are
> customizable by customers, I go with the much simpler:
>
> olcServerID: <#>
>
> form. Then each server only has a single value for olcServerID, which is
> its specific serverID. This way I never have to worry that MMR replication
> is going to get mesed up because of URI changes.
>
> --Quanah
>
> --On Tuesday, February 18, 2014 10:09 AM -0500 "Borresen, John - 0442 - MITLL"
> <John.Borresen(a)ll.mit.edu> wrote:
>
>> All,
>>
>> The long weekend didn't help...still at a loss. Question...
>>
>> If the olcServerIDs look like, on all three servers:
>>
>> olcServerID: 1 ldap://mm-server1.example.ldap
>> olcServerID: 2 ldap://mm-server2.example.ldap
>> olcServerID: 3 ldap://mm-server3.example.ldap
>>
>> Should the Replica IDs (rid) in the olcSycnrepl directive be:
>>
>> olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password> interval=01:00:00:00
>> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
>> schemachecking=on type=refreshAndPersist retry="60 +"
> filter="(objectClass=*)" attrs=*,+"
>> syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002
>> provider=mm-server2.example.ldap bindmethod=simple
>> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
>> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
>> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
>> retry="60
>> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>> olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password> interval=01:00:00:00
>> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
>> schemachecking=on type=refreshAndPersist retry="60 +"
> filter="(objectClass=*)" attrs=*,+"
>> syncdata=accesslog starttls=no
>>
>> OR
>>
>> olcSyncrepl: {0} rid=1 provider=mm-server1.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password>
>> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
>> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
>> retry="60
>> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>> olcSyncrepl: {1} rid=2 provider=mm-server2.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password>
>> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
>> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
>> retry="60
>> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>> olcSyncrepl: {0} rid=3 provider=mm-server3.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password>
>> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
>> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
>> retry="60
>> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>>
>> OR
>>
>> Does it matter?
>>
>> Also, should the all three olcSycrepl directives be loaded on all
>> three servers so they look identical. What I mean by that is should
>> each Server "replicate" to itself? There is confusion on this matter.
>> I asked Quanah that back in late January, and he stated that the
>> system knows about itself so it knows what to ignore. Then last week,
>> he asked why I had the master replicating to itself.
>>
>> Also, since I have refreshAndPersist configured do I need an interval
>> as well?
>>
>> Thanks in advance,
>>
>> John
>>
>> -----Original Message-----
>> From: openldap-technical-bounces(a)OpenLDAP.org
>> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of
>> Borresen, John - 0442 - MITLL Sent: Friday, February 14, 2014 4:28 PM
>> To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
>> Subject: RE: Syncrepl and mmr
>>
>> All,
>>
>> I just created an mm-server3, using the config_dbase and main_dbase
>> from
>> mm-server2 -- copied the ldif's I created from mm-server2 then ran
>> slapadd.
>>
>> On mm-server3:
>> olcServerID: 1 ldap://mm-server1.example.ldap
>> olcServerID: 2 ldap://mm-server2.example.ldap
>> olcServerID: 3 ldap://mm-server3.example.ldap
>>
>> olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password> interval=01:00:00:00
>> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
>> schemachecking=on type=refreshAndPersist retry="60 +"
> filter="(objectClass=*)" attrs=*,+"
>> syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002
>> provider=mm-server2.example.ldap bindmethod=simple
>> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
>> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
>> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
>> retry="60
>> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>> olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password> interval=01:00:00:00
>> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
>> schemachecking=on type=refreshAndPersist retry="60 +"
> filter="(objectClass=*)" attrs=*,+"
>> syncdata=accesslog starttls=no
>>
>> Started slapd, no errors. It immediately sync'd up with mm-server1!
>> Changes that I made on mm-server1 days ago which have never replicated
>> over to mm-server2...replicated to mm-server3 immediately on startup.
>>
>> I had not even got around to adding mm-server3 to mm-server1 (or
>> mm-server2) yet.
>>
>> The olcServerIDs and olcSyncrepl on both mm-server1 and 2 show:
>> olcServerID: 1 ldap://mm-server1.example.ldap
>> olcServerID: 2 ldap://mm-server2.example.ldap
>>
>> olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password> interval=01:00:00:00
>> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
>> schemachecking=on type=refreshAndPersist retry="60 +"
> filter="(objectClass=*)" attrs=*,+"
>> syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002
>> provider=mm-server2.example.ldap bindmethod=simple
>> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
>> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
>> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
>> retry="60
>> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>>
>> So...now, I am at even more of a loss. Why would mm-server1 be
>> replicating to mm-server3 and not 2? When the configs are the same
>> between mm-server2 and 3???
>>
>>
>>
>> Thanks in advance...
>> John
>>
>>
>> -----Original Message-----
>> From: openldap-technical-bounces(a)OpenLDAP.org
>> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of
>> Borresen, John - 0442 - MITLL Sent: Friday, February 14, 2014 1:34 PM
>> To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
>> Subject: RE: Syncrepl and mmr
>>
>> All,
>>
>> If I went off the beaten' path...where did I go wrong? (my config and
>> error messages are in a previous posting)
>>
>> Thanks in advance,
>> John
>>
>> -----Original Message-----
>> From: openldap-technical-bounces(a)OpenLDAP.org
>> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of
>> Borresen, John - 0442 - MITLL Sent: Friday, February 14, 2014 8:40 AM
>> To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
>> Subject: RE: Syncrepl and mmr
>>
>> Thanks Quanah,
>>
>> A few weeks back I asked that question (on 1/30):
>>> All Masters in the chain have the olcServerID's and olcSynRepl for
>>> itself and its partner? I can understand having each knowing about
>>> the others but why itself? It's replicating to itself?
>> -You replied
>> -It knows about itself so it knows what to ignore.
>>
>> Even in the Admin Guide is specifies setting it up that way...each
>> server has all the others and itself listed. I was following the
>> procedures delineated in the Admin Guide and in the man-pages
>> (including how I understood what was put out on the board): From the Admin
> Guide:
>> 8.3.3. N-Way Multi-Master
>>
>> For the following example we will be using 3 Master nodes. Keeping in
>> line with test050-syncrepl-multimaster of the OpenLDAP test suite, we
>> will be configuring slapd(8) via cn=config
>>
>> This sets up the config database:
>>
>> dn: cn=config
>> objectClass: olcGlobal
>> cn: config
>> olcServerID: 1
>>
>> dn: olcDatabase={0}config,cn=config
>> objectClass: olcDatabaseConfig
>> olcDatabase: {0}config
>> olcRootPW: secret
>>
>> second and third servers will have a different olcServerID obviously:
>>
>> dn: cn=config
>> objectClass: olcGlobal
>> cn: config
>> olcServerID: 2
>>
>> dn: olcDatabase={0}config,cn=config
>> objectClass: olcDatabaseConfig
>> olcDatabase: {0}config
>> olcRootPW: secret
>>
>> This sets up syncrepl as a provider (since these are all masters):
>>
>> dn: cn=module,cn=config
>> objectClass: olcModuleList
>> cn: module
>> olcModulePath: /usr/local/libexec/openldap
>> olcModuleLoad: syncprov.la
>>
>> Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc.
>> with your actual ldap urls):
>>
>> dn: cn=config
>> changetype: modify
>> replace: olcServerID
>> olcServerID: 1 $URI1
>> olcServerID: 2 $URI2
>> olcServerID: 3 $URI3
>>
>> dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
>> changetype: add
>> objectClass: olcOverlayConfig
>> objectClass: olcSyncProvConfig
>> olcOverlay: syncprov
>>
>> dn: olcDatabase={0}config,cn=config
>> changetype: modify
>> add: olcSyncRepl
>> olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config"
>> bindmethod=simple credentials=secret searchbase="cn=config"
>> type=refreshAndPersist retry="5 5 300 5" timeout=1
>> olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config"
>> bindmethod=simple credentials=secret searchbase="cn=config"
>> type=refreshAndPersist retry="5 5 300 5" timeout=1
>> olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config"
>> bindmethod=simple credentials=secret searchbase="cn=config"
>> type=refreshAndPersist retry="5 5 300 5" timeout=1
>> -
>> add: olcMirrorMode
>> olcMirrorMode: TRUE
>>
>> I followed what is put in the Admin Guide, etc...
>>
>> Thanks
>>
>> -----Original Message-----
>> From: openldap-technical-bounces(a)OpenLDAP.org
>> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Quanah
>> Gibson-Mount Sent: Thursday, February 13, 2014 1:57 PM
>> To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
>> Subject: Re: Syncrepl and mmr
>>
>> --On Thursday, February 13, 2014 10:54 AM -0500 "Borresen, John - 0442
>> - MITLL" <John.Borresen(a)ll.mit.edu> wrote:
>>
>>> All,
>>
>> Your configuration is very confused. Why do you have the master
>> replicate to itself, for example?
>>
>> --Quanah
>>
>>
>> --
>>
>> Quanah Gibson-Mount
>> Architect - Server
>> Zimbra, Inc.
>> --------------------
>> Zimbra :: the leader in open source messaging and collaboration
>>
>>
>>
>>
>
>
>
> --
>
> Quanah Gibson-Mount
> Architect - Server
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
10 years, 8 months
Re: slapd-meta
by Quanah Gibson-Mount
--On Tuesday, March 01, 2016 7:23 PM +0100 Fr3ddie <fr3ddie(a)fr3ddie.it>
wrote:
> Il 18/11/2015 02:32, Quanah Gibson-Mount ha scritto:
>> --On Tuesday, November 17, 2015 7:57 PM +0200 Fr3ddie
>> <fr3ddie(a)fr3ddie.it> wrote:
>>
>>> Il 10/11/2015 13:06, Fr3ddie ha scritto:
>>>> Hello to the list,
>>>
>>> Nobody has any hint?
>>
>> I suggest reading the code, because the answer is actually fairly
>> obvious if you look at slapd-meta/config.c:
>>
>> "NAME 'olcMetaTargetConfig' "
>> "MUST ( olcMetaSub $ olcDbURI ) "
>>
>> Yet you aren't using the olcMetaTargetConfig objectClass in your entry.
>
>
> Thank you very much for your help Quanah.
> Please excuse the delay, I have not been able to access the servers
> to perform other tests during this period...
>
> I tried your suggestion and read the code, as much as I could have been
> able to.
>
> 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.
> dn: olcMetaSub={0}uri,olcDatabase={3}meta,cn=config
> objectClass: olcConfig
> objectClass: olcMetaTargetConfig
> olcMetaSub: {0}uri
> olcDbUri: "ldap://server-loc1.loc1.root/dc=loc1,dc=root"
> olcDbIdAssertBind: bindmethod=simple
> binddn="cn=admin,dc=loc1,dc=root" credentials=xxxxxxxxx starttls=yes
> tls_reqcert=demand
>
>
> dn: olcMetaSub={1}uri,olcDatabase={3}meta,cn=config
> objectClass: olcConfig
> objectClass: olcMetaTargetConfig
> olcMetaSub: {1}uri
> olcDbUri: "ldap://server-loc2.loc2.root/dc=loc2,dc=root"
> olcDbIdAssertBind: bindmethod=simple
> binddn="cn=admin,dc=loc2,dc=root" credentials=xxxxxxxxx starttls=yes
> tls_reqcert=demand
The slapd-meta test suit shows an additional parameter, mode=self, being
set. That may or may not help. ;)
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
A division of Synacor, Inc
8 years, 8 months
Re: updating from 2.4.20 to 2.4.22 breaks syncrepl/TLS
by Buchan Milne
On Wednesday, 20 October 2010 16:13:44 Thierry Lacoste wrote:
> Hello,
>
> I have 2 CentOS 5.4 servers running OpenLDAP 2.4.20
> installed from Buchan Milne's repository (openldap2.4-
> servers-2.4.20-1.el5).
>
> The first server is a Sync Provider.
> The second is a consumer with 'starttls=critical'.
>
> I have no problem after 'yum update' of the master
> (openldap2.4-servers-2.4.22-1.el5 is installed and replication is OK).
>
> But after 'yum update' of the slave, syncrepl won't work anymore
> because of TLS failures.
>
> Here are the logs on the master :
> Oct 20 16:51:15 vcos-castor slapd2.4[20097]: @(#) $OpenLDAP: slapd
> 2.4.22 (Apr 27 2010 12:04:27) $
> bgmilne@centos5-32.ranger.dnsalias.com:/home/bgmilne/rpm/BUILD/
> openldap-2.4.22/servers/slapd
> Oct 20 16:51:15 vcos-castor slapd2.4[20098]: slapd starting
> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 fd=16 ACCEPT
> from IP=IP.OF.THE.SLAVE:46212 (IP=0.0.0.0:389)
> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 EXT
> oid=1.3.6.1.4.1.1466.20037
> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 STARTTLS
> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 RESULT
> oid= err=0 text=
> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 fd=16 closed
> (TLS negotiation failure)
>
> Here are the logs on the slave :
> Oct 20 16:51:45 vcos-pollux slapd2.4[1808]: @(#) $OpenLDAP: slapd
> 2.4.22 (Apr 27 2010 12:04:27) $
> bgmilne@centos5-32.ranger.dnsalias.com:/home/bgmilne/rpm/BUILD/
> openldap-2.4.22/servers/slapd
> Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: slapd starting
> Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: slap_client_connect:
> URI=ldap://NAME_OF_THE_MASTER Error, ldap_start_tls failed (-11)
> Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: do_syncrepl: rid=000 rc
> -11 retrying (4 retries left)
>
> ldapsearch from the slave can do TLS :
> $ ldapsearch -ZZ -x -h NAME_OF_THE_MASTER
> This is ldapsearch from openldap-clients-2.3.43-12.el5_5.2 as packaged
> by CentOS
>
> Any ideas on how to troubleshoot the problem?
Note that the syncrepl statement now has its own tls configuration, see the
options tls_cert, tls_key, tls_cacert, tls_cacertdir, tls_reqcert,
tls_ciphersuite, tls_crlcheck to the syncrepl statement.
Regards,
Buchan
14 years
Re: [Q] can I replicate several branches to the same slave from one master?
by Zeus Panchenko
Andrew Findlay <andrew.findlay(a)skills-1st.co.uk> wrote:
>
> Try fixing the RIDs - use small numbers, all different. The exact values are not important.
> Also try commenting out the second syncrepl clause until you have the others working properly.
> You should be able to merge the first and second clauses as they share a search-base.
I did both of them, now slave configuration looks this way:
---[ slave configuration quotation start ]----------------------------
syncrepl rid=0
provider=ldap://master.example:389
starttls=critical
searchbase="ou=ABC,ou=Sendmail,dc=example"
bindmethod=simple
binddn="uid=replABC,ou=repl,dc=example"
credentials="***"
tls_cacert=/usr/local/etc/openldap/ssl/ca.crt
tls_cert=/usr/local/etc/openldap/ssl/ABC.crt
tls_key=/usr/local/etc/openldap/ssl/ABC.key
tls_reqcert=try
type=refreshAndPersist
retry="60 +"
logbase="cn=example-accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
syncrepl rid=1
provider=ldap://master.example:389
starttls=critical
searchbase="ou=People,dc=example"
bindmethod=simple
binddn="uid=replABC,ou=repl,dc=example"
credentials="***"
filter="(&(objectClass=authorizedServiceObject)(|(authorizedService=mail@foo.bar)(authorizedService=xmpp@foo.bar)))"
attrs="cn,entry,entryCSN,entryUUID,o,uid,uidNumber,gidNumber,gecos,homeDirectory,loginShell,userPassword,creatorsName,createTimestamp,modifiersName,modifyTimestamp,mail,rfc822MailMember,sn,authorizedService,mu-mailBox"
tls_cacert=/usr/local/etc/openldap/ssl/ca.crt
tls_cert=/usr/local/etc/openldap/ssl/ABC.crt
tls_key=/usr/local/etc/openldap/ssl/ABC.key
tls_reqcert=try
type=refreshAndPersist
retry="60 +"
logbase="cn=example-accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
---[ slave configuration quotation end ]----------------------------
I separated rid-s and even searchbases, but I still can see complains in
slapd.log file, though now it is only rid=0 which is complained on, not
both of them ...
---[ slave slapd.log quotation start ]--------------------------------
Jun 29 22:45:30 ABC slapd[12593]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform
Jun 29 22:45:30 ABC slapd[12593]: do_syncrep2: rid=000 (53) Server is unwilling to perform
Jun 29 22:45:30 ABC slapd[12593]: do_syncrepl: rid=000 rc -2 retrying
---[ slave slapd.log quotation end ]--------------------------------
>
> You may also need to put ACLs on the accesslog database.
>
is it something like this?
access to dn.children="cn=example-accesslog"
by dn.children="ou=repl,dc=example" read
by * break
but is not the fact that one replica working confirms, that replication is allowed
and I can see the changes for the objects of rid=1
--
Zeus V. Panchenko jid:zeus@im.ibs.dn.ua
IT Dpt., I.B.S. LLC GMT+2 (EET)
7 years, 4 months
Re: ssf Security Question
by William Brown
On Thu, 2017-11-16 at 21:25 -0800, Quanah Gibson-Mount wrote:
> --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.ht
> > ml
> >
> > 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.
Absolutely. I think it's just better to say look, expect leakage. Do it
right, once, and guarantee your behaviours. It's not just simple bind
though,
An example here though, is because of how minssf works, we have to
accept anonymous binds on ssf=0, because we expect starttls next - even
then, you can leak things like "search mail=secret@secret". If they
don't want to leak phone numbers, mail etc. So we have a dataleak in
the form of the query, before the ssf check can reject our request.
Sure, we aren't leaking entries, but we shouldn't leak *anything* if we
are in this kind of environment,
Again coming back to LDAPS is the only way to really guarantee this
connection is truly encrypted from the first byte to the last :)
>
> 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. ;)
Yeah, the krb devs told me about this change recently, I should go and
update this :) I've just been busy lately :)
Thanks mate,
>
> Warm regards,
> Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by
> OpenLDAP:
> <http://www.symas.com>
>
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
6 years, 12 months
RE: Openldap server with TLS not working
by Axel Grosse
Hi Ben, Dieter
can we focus on LDAPS because TLS1 is not an option and even if LDAPS is deprecated I should be able to configure it ..
TLSCACertificateFile /etc/openldap/ssl/VordelCA.crt
TLSCertificateFile /etc/openldap/ssl/VordelDev.crt
TLSCertificateKeyFile /etc/openldap/ssl/VordelDev.key
TLSVerifyClient never
are this entries in the slapd.conf sutable for LDAPS ?
if not whats missing ?
start the server with
/usr/sbin/slapd -h ldap://192.168.30.169:636 -u ldap
thanks a lot
Axel
AXEL GROSSE
Principal Solution Architect, Sales Solution Center, Axway
P: +61-405-995-768
828 Pacific Highway
Gordon, 2072 NSW
agrosse(a)axway.com
http://www.axway.com
-----Original Message-----
From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter Klünter
Sent: Thursday, 3 October 2013 6:46 PM
To: openldap-technical(a)openldap.org
Subject: Re: Openldap server with TLS not working
Am Thu, 3 Oct 2013 00:16:28 +0000
schrieb Axel Grosse <agrosse(a)axway.com>:
> Hi ben,
> thanks for the comment.
> agree with you on TLS usage should be perferred
> but the client that is connecting is only capable of LDAPS ... he has
> not implemented TLS Client jet .
>
> But can you please take a look to the error I am facing
>
> openssl s_client -connect 192.168.30.169:389 -showcerts
> -CAfile ./ssl/VordelCA.crt CONNECTED(00000003)
> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:s23_lib.c:188:
>
> any idea what can cause this ?
>
>
> AXEL GROSSE
> Principal Solution Architect, Sales Solution Center, Axway
> P: +61-405-995-768
> 828 Pacific Highway
> Gordon, 2072 NSW
> agrosse(a)axway.com
> http://www.axway.com
>
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org
> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb
> Sent: Wednesday, 2 October 2013 10:57 PM To:
> openldap-technical(a)openldap.org Subject: Re: Openldap server with TLS
> not working
>
> On 2013.10.02 07.29, Axel Grosse wrote:
>
> > when I test on the server itself ..
> > openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile
> > ./ssl/VordelCA.crt
> > CONNECTED(00000003)
> > 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> > failure:s23_lib.c:188:
>
> ldaps [port 636] is deprecated. use starttls with the standard port
> [389]. to test, just use ldapsearch [see the reference to -Z in the
> man page]
You are connnecting to port 389, but s_client is not able to initiate a
LDAP startTLS session (only SMTP and IMAP), so you have to connect
ldaps and port 636.
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
11 years, 1 month