On Wed, 24 Jul 2013 07:59:21 -0700 Quanah Gibson-Mount <quanah(a)zimbra.com>
wrote
> --On Wednesday, July 24, 2013 4:08 PM +0200 Ulrich Windl
> <Ulrich.Windl(a)rz.uni-regensburg.de> wrote:
>
> > Hi!
> >
> > When trying to require integrity for LDAP connections by specifying
> > "ssf=1" in Security, I have a problem with Perl where the cat bites its
> > tail:
> >
> > It's recommended to query the root DSE for TLS extension before trying to
> > use TLS like this:
> >
> > my $dse = $ldap->root_dse();
> >
> > if ($dse->supported_extension(LDAP_EXTENSION_START_TLS)) {
> > my $msg = $ldap->start_tls('verify' => 'require',
> > 'capath' => '/etc/ssl/certs');
> > ...
>
> Personally, I just always try to startTLS regardless. Then you can decide
> whether or not you wish to continue after that point based on whether or
> not it succeeds or fails.
>From RFC 2830, section 6 "Security Considerations":
Additionally, an active-intermediary
attacker can remove the Start TLS extended operation from the
supportedExtension attribute of the root DSE.
=> Always try startTLS at the client side if set in local configuration.
Furthermore from this section:
Therefore, both parties
SHOULD independently ascertain and consent to the security level
achieved once TLS is established and before beginning use of the TLS
connection. For example, the security level of the TLS connection
might have been negotiated down to plaintext.
So your client has to query the effective security level from the LDAP API and
make a decision based on comparison to local config. Not sure which option to
use in case of TLS though.
Ciao, Michael.
Cheap advice inline.
On Fri, Oct 28, 2011 at 11:44:25AM -0400, John Tobin wrote:
> Folks,
>
> I have openldap up, it supports vsftpd, sshd, and 5 client linux machines
> for remote login.
>
> I would like to get tls working. I would support either ldaps [port 636],
> or the tls available on port 389, I am aware of the differences in
> implementation, and the fact that an administrator effectively has to make
> a decision to support one or the other in most cases.
>
> Currently:
> I have slapd running configured for tls under ldap [std port 389].
> I am testing it on the slapd machine, with a client on the same machine.
> I am pointing to the same cacertificate in slapd.d [cn=config.ldif] and
> ldap.conf.
>
> With that in place, and the ldap.conf below:
> nightmare:/etc # cat ldap.conf
>
> base dc=dark,dc=net
> uri ldap://nightmare.dark.net
> # scope sub
> # binddn "cn=admin,dc=dark,dc=net"
> # bindpw jackie
> bind_policy soft
> # The user ID attribute (defaults to uid)
> pam_login_attribute uid
> pam_lookup_policy yes
> pam_password exop
> nss_schema rfc2307bis
> tls_reqcert never
> pam_filter objectClass=posixAccount
> ldap_version 3
> nss_map_attribute uniqueMember uniqueMember
> ssl start_tls
> tls_cacert /var/lib/ldap/cacert.pem
> tls_cert /var/lib/server.crt
> tls_key /var/lib/ldap/server.key
>
> I have run ldapsearch:
> nightmare:/media # ldapsearch -v -x -H ldap://nightmare.dark.net:389/ -b
> "dc=dark,dc=net" -Z
Always test starttls with -ZZ, so if your starttls isn't working the connection will fail.
> ldap_initialize( ldap://nightmare.dark.net:389/??base )
> filter: (objectclass=*)
> requesting: All userApplication attributes
> # extended LDIF
> #
> # LDAPv3
> # base <dc=dark,dc=net> with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # dark.net
> dn: dc=dark,dc=net
> dc: dark
> o: dark
> objectClass: organization
> objectClass: dcObject
>
> # admin, dark.net
> dn: cn=admin,dc=dark,dc=net
> objectClass: organizationalRole
> cn: admin
>
> # Default Policy, dark.net
> dn: cn=Default Policy,dc=dark,dc=net
> objectClass: namedObject
> objectClass: pwdPolicy
> cn: Default Policy
>
> # People, dark.net
> dn: ou=People,dc=dark,dc=net
> objectClass: organizationalUnit
> ou: People
> description: People is used in mapping the /etc/passwd entries
>
> # jtobin, People, dark.net
> dn: uid=jtobin,ou=People,dc=dark,dc=net
> uid: jtobin
> cn: John C. Tobin
> objectClass: account
> objectClass: posixAccount
> objectClass: top
> objectClass: shadowAccount
> loginShell: /bin/ksh
> uidNumber: 5000
> gidNumber: 100
> homeDirectory: /home/jtobin
> gecos: John C. Tobin
>
> # defaultDNS, dark.net
> dn: cn=defaultDNS,dc=dark,dc=net
> cn: defaultDNS
> objectClass: top
> objectClass: suseDnsConfiguration
> suseDefaultBase: ou=DNS,dc=dark,dc=net
>
> # DNS, dark.net
> dn: ou=DNS,dc=dark,dc=net
> objectClass: top
> objectClass: organizationalUnit
> ou: DNS
>
> # search result
> search: 3
> result: 0 Success
>
> # numResponses: 8
> # numEntries: 7
>
> nightmare:~ #
> #####
>
> So I am assuming the ldapserver on ldap://nightmare.dark.net:389/ with tls
> works.
> [I looked through the message output in /var/log/message and see the
> “STARTTLS” and “TLS established tls_ssf=256”]
> I have done a number of similar ldapsearches. This appears to work
> correctly.
>
> On the client machine I now do :
>
> nightmare:/media # su - jtobin
> su: user jtobin does not exist
> nightmare:/media #
>
> /var/log/message - output......
>
> nightmare:/var/log # tail –f |grep –I tls
>
> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 op=0 STARTTLS
> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls
> failed:stat=-1
> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept
> failure error=-1 id=1217, closing
> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 fd=14 closed (TLS
> negotiation failure)
> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 op=0 STARTTLS
> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls
> failed:stat=-1
Augh. If you can stop using nscd all this will be much easier for you. I personally like nslcd rather than nss-ldap, but each to their own.
If not, restart nscd before you start every troubleshooting round.
> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept
> failure error=-1 id=1218, closing
> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 fd=14 closed (TLS
> negotiation failure)
First I would test that all the CA certs and server certs in use are understandable by each other. Does the server cert on the machine running slapd validate against the CA cert on the machine running ldapsearch? Does the server cert on the machine running slapd validate against the CA cert on the client machine?
openssl verify -CAfile cacert.pem servercert.pem
If the output says "ok" then the actual cert part is fine.
At this point I would crank up the slapd debug level (run it in the foreground) and match it again your ldap client debug logs. See if you can reproduce the error above using a client like ldapsearch, using the same search parameters as the nss-ldap client would use.
> [if you want more of the log, I can obviously get it, but these appear to
> be the important parts.]
>
> This is probably a configuration error, or a logical / architecture
> misunderstanding, ok, I ‘m a newbie.
> Do I have certificates incorrectly generated? [certificates were generated
> via [1]http://www.openldap.org/faq/data/cache/185.html].
> What did I do wrong?
>
> This is running openldap 2.4.26 off of Suse 12.1 milestone 5.
I'm getting a puppetized starttls working with 2.4.26/openssl on debian, but much the same thing.
> Thanks in advance.
> tob
>
> References
>
> Visible links
> 1. http://www.openldap.org/faq/data/cache/185.html
Asimananda Mohanty wrote:
>
> The first command works fine (ldapsearch -x -H ldap://ldap-company.com
> <http://ldap-company.com/> -ZZ) but the second one (ldapsearch -x -H
> ldaps://ldap-company.com:636 <http://ldap-company.com:636/> -ZZ) is
> showing error :
>
> *ldap_start_tls: Operations error (1)*
Sorry, stupid copy&paste by me. Should have another coffee. Omit the -ZZ
in the second command since LDAPS and StartTLS ext.op. cannot be used
together.
See also:
http://www.openldap.org/faq/data/cache/605.html
Ciao, Michael.
--
Michael Ströder
E-Mail: michael(a)stroeder.com
http://www.stroeder.com
On 06/05/2018 04:36 AM, web(a)tomjay.co.uk wrote:
> I'm under the impression that LDAPS (and not StartTLS) has been
> depreciated in OpenLDAP, but I can't find anything on the OpenLDAP
> website that says this. Is this the case, and is there a reference for it?
The "LDAPS is deprecated" is rather obsolete.
It was caused by lack of formal specification for LDAPS.
Personally I was always against this position. It simply works anyway.
And any directory server vendor dropping support for LDAPS would be
seriously punished by its customer base.
See also the discussion I've started a couple of months ago:
https://www.openldap.org/lists/openldap-technical/201802/msg00004.html
Ciao, Michael.
Am Tue, 05 Jun 2018 03:36:11 +0100
schrieb web(a)tomjay.co.uk:
> Hello,
>
> I'm under the impression that LDAPS (and not StartTLS) has been
> depreciated in OpenLDAP, but I can't find anything on the OpenLDAP
> website that says this. Is this the case, and is there a reference
> for it?
RFC 4511 and 4513 are quite clear about this. While start TLS is defined
in RFC 2830, there is no formal specification for ldaps, furthermore
read on ldaps in /etc/services.
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
Emmanuel Dreyfus wrote:
> Dieter Kluenter <dieter(a)dkluenter.de> wrote:
>
>> No, ldapi:/// doesn't present a certificate, but you may establish a
>> startTLS session to ldapi:///, in this case the client requests a
>> server certificate.
>
> Let me rephrase: I would like to specify two LDAP servers in ldaprc
> - one ldapi:/// with anonymous bind
> - one ldaps:// with SASL EXTERNAL for and required server certificate
>
> It seems to me it is not possible.
Why not use SASL/EXTERNAL in both cases and let slapd map SASL authc-DN to the
same authz-DN?
Ciao, Michael.
Thanks, Quanah
Not sure what you meant by " Well, it may not have been this issue, but it definite would become an issue then."
Was what I did a good thing or not? Curious minds want to know. <lol>
MM Server1:
# ldapsearch -H ldap://mm-server1.example.ldap -d 256 -x -D cn=admin,cn=config -W -ZZ -b olcDatabase=\{1\}bdb,cn=config olcSyncrepl
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <olcDatabase={1}bdb,cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: olcSyncrepl
#
# {1}bdb, config
dn: olcDatabase={1}bdb,cn=config
olcSyncrepl: {0}rid=002 provider=ldap://mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,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=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem
olcSyncrepl: {1}rid=001 provider=ldap://mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,dc=ldap" credentials=<password> interva
l=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=
"*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem
# {0}syncprov, {1}bdb, config
dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config
# {1}accesslog, {1}bdb, config
dn: olcOverlay={1}accesslog,olcDatabase={1}bdb,cn=config
# search result
search: 3
result: 0 Success
# numResponses: 4
# numEntries: 3
MM Server2:
# ldapsearch -H ldap://mm-server2.example.ldap -d 256 -x -D cn=admin,cn=config -W -ZZ -b olcDatabase=\{1\}bdb,cn=config olcSyncrepl
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <olcDatabase={1}bdb,cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: olcSyncrepl
#
# {1}bdb, config
dn: olcDatabase={1}bdb,cn=config
olcSyncrepl: {0}rid=001 provider=ldap://mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,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=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem
olcSyncrepl: {1}rid=002 provider=ldap://mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,dc=ldap" credentials=<password> interva
l=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=
"*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem
# {0}accesslog, {1}bdb, config
dn: olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config
# {1}syncprov, {1}bdb, config
dn: olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config
# search result
search: 3
result: 0 Success
# numResponses: 4
# numEntries: 3
I modified, the "starttls" statement (just to test) to no. and now receiving the following
>From MM-Server2:
Jan 31 12:39:15 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc 13 retrying
Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 fd=101 ACCEPT from IP=<mm-server1-ip>:48899 (IP=0.0.0.0:389)
Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 op=0 BIND dn="cn=ldapadmin,dc=example,dc=ldap" method=128
Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 op=0 RESULT tag=97 err=13 text=TLS confidentiality required
Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 op=1 UNBIND
Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 fd=101 closed
Jan 31 12:40:15 gp42-admin4 slapd[26000]: conn=8616 fd=106 ACCEPT from IP=<mm-server2-ip>:43431 (IP=0.0.0.0:389)
Jan 31 12:40:15 gp42-admin4 slapd[26000]: conn=8616 op=0 BIND dn="cn=ldapadmin,dc=example,dc=ldap" method=128
Jan 31 12:40:15 gp42-admin4 slapd[26000]: conn=8616 op=0 RESULT tag=97 err=13 text=TLS confidentiality required
Jan 31 12:40:15 gp42-admin4 slapd[26000]: slap_client_connect: URI=ldap://mm-server2.example.ldap DN="cn=ldapadmin,dc=example,dc=ldap" ldap_sasl_bind_s failed (13)
Very similar on MM-Server1.
I am at a loss. The TLS configuration, files, are exactly as they are in the standard client configuration...as far as I can tell. Three other SysAdmins, for sanity sake, have checked that the paths are identical between the various files.
I turned on a flood of debugging (-1) and on "mm-server1 and 2", seeing:
tls_write: want=810 error=Broken pipe
ldap_write: want=732 error=Broken pipe
52ebe8e0 ber_flush2 failed errno=32 reason="Broken pipe"
and
TLS trace: SSL3 alert write:warning:close notify
ldap_free_connection: actually freed
tls_read: want=5 error=Bad file descriptor
Thanks in advance
-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
Sent: Friday, January 31, 2014 12:07 PM
To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
Subject: RE: Syncrepl and mmr
--On Friday, January 31, 2014 8:54 AM -0500 "Borresen, John - 0442 - MITLL"
<John.Borresen(a)ll.mit.edu> wrote:
> Thanks Quanah
>
> I'm sure it isn't 100% correct, but I added the following ACL to my
> accesslog DB on both MM servers:
>
> olcAccess: to * by dn="cn=ldapadmin,dc=group42,dc=ldap" read by * none
Well, it may not have been this issue, but it definite would become an issue then. ;)
> I'm still seeing
> gp42-admin3 (MM server1)
> Jan 31 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH
> base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 31
> 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH attr=reqDN
> reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan
> 31 08:25:17
> gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with
> LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:17 gp42-admin3 slapd[3599]:
> do_syncrepl: rid=001 rc -1 retrying Jan 31 08:25:17 gp42-admin3
> slapd[3599]: send_search_entry: conn 5551 ber write failed. Jan 31
> 08:25:17 gp42-admin3 slapd[3599]: conn=5551 fd=32 closed (connection
> lost on write) Jan 31 08:25:17 gp42-admin3 slapd[3599]: do_syncrep2:
> rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 31
> 08:25:17
> gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying
Your masters are unable to talk to each other. You need to determine why.
This will take debugging on your part, as I've never seen anything like this before.
> gp42-admin4 (MM server2)
> Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 fd=101 ACCEPT from
> IP=155.34.133.73:10446 (IP=0.0.0.0:389) Jan 31 08:25:19 gp42-admin4
> slapd[26000]: conn=8050 op=0 BIND dn="dc=group42,dc=ldap" method=163
> Jan
> 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=0 RESULT tag=97
> err=13 text=TLS confidentiality required Jan 31 08:25:19 gp42-admin4
> slapd[26000]: conn=8050 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap"
> method=128 Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=1
> RESULT tag=97 err=13 text=TLS confidentiality required Jan 31 08:25:19
> gp42-admin4 slapd[26000]: conn=8050 op=2 UNBIND Jan 31 08:25:19
> gp42-admin4 slapd[26000]: conn=8050 fd=101 closed Jan 31 08:25:51
> gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with
> LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:51 gp42-admin4
> slapd[26000]: do_syncrepl: rid=001 rc -1 retrying
This says that your consumer is connecting without sending a startTLS, while you've configured the master to require startTLS. Clearly you need to either enable startTLS in the syncrepl statement, or not require starttls on your master.
--Quanah
> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
> Sent: Thursday, January 30, 2014 5:10 PM
> To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
> Subject: RE: Syncrepl and mmr
>
> --On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 -
> MITLL" <John.Borresen(a)ll.mit.edu> wrote:
>
>> Well, that was helpful -- lol
>
>
> Looking at your previously supplied configuration, it is clearly
> apparent that you provided your replication user no ACLs to read the
> accesslog DB, so the error you see makes sense. It can't read the
> data out of accesslog, so it throws an error stating that fact.
>
> --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
Still haven't been able to get this working. And can't find any way to turn on any debugging for ldap backend.
If anyone has done this if they could provide some feed back.
A
-----Original Message-----
From: Alex Samad - Yieldbroker
Sent: Friday, 4 May 2012 2:32 PM
To: 'openldap-technical(a)openldap.org'
Subject: openldap to AD proxy
Hi
I am still struggling with the my openldap to AD proxy connection.
I have successfully connected such that I can do search when I bind to openldap with an AD dn, but I want to be able to do anon search and I want anon to map through to a dn I have created in AD which has read only rights.
dn: olcDatabase={3}ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {3}ldap
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * read
olcReadOnly: TRUE
olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
olcSizeLimit: 500
olcSuffix: dc=xyz,dc=com
olcDburi: "ldap://ldap. xyz.com "
olcDbRebindAsUser: TRUE
olcDbChaseReferrals: TRUE
olcdbaclbind: bindmethod=simple binddn="CN=ad readonly,OU=YB Services,OU= xyz,DC= xyz,DC=com" credentials=":)" starttls=no
olcDbIDAssertBind: bindmethod=none binddn="CN=ad readonly,OU=YB Services,OU= xyz,DC= xyz,DC=com" credentials=":)" starttls=no
I have a subordinate db at ou=external, DC= xyz,DC=com
I can do a
ldapsearch -x -D " CN=ad readonly,OU=YB Services,OU= xyz,DC= xyz,DC=com" -b " DC= xyz,DC=com" -w :)
what I can't do is
ldapsearch -x -b " DC= xyz,DC=com"
I am thinking I want to map anon request through to the readonly DN. But still leave it such that when people bind to openldap as themselves they bind to AD as themselves How would I do that ?
Thanks
Alex
Hello,
On the provider I have the following settings :
TLSCACertificateFile /etc/ssl/certs/ldap-cert.pem
TLSCertificateFile /etc/ssl/certs/ldap-cert.pem
TLSCertificateKeyFile /etc/ldap/ssl/ldap-key.pem
but no TLSCipherSuite defined.
I added the starttls=yes on the consumer :
Syncrepl rid=003
provider=ldaps://ldap.mydomain.fr:1024/
type=refreshOnly
retry="60 10 600 +"
interval=00:00:00:10
searchbase="dc=mydomain,dc=fr"
scope=sub
schemachecking=on
bindmethod=simple
starttls=yes
tls_cert=/etc/ssl/certs/ldap-cert.pem
tls_cacert=/etc/ssl/certs/ldap-cert-ca.pem
binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
credentials=my_password
But still the same error.
Any idea ?
Hugo
On 14 October 2011 13:52, Olivier Guillard <olivier(a)guillard.nom.fr> wrote:
> Hi,
>
> Have you set up the follwing appropriately :
>
> TLSCertificateFile
> TLSCertificateKeyFile
> TLSCipherSuite
>
> On the provider ?
>
> You probably also want to set this up correctly in
> your syncrepl section :
>
> starttls=yes
> tls_cacert=/path/to/certificate
>
> I suspect better if TLS_CACERT is also properly
> set up in both ldap server slapd config.
>
> ---
> Olivier
>
> On Thu, Oct 13, 2011 at 6:38 PM, Hugo Deprez <hugo.deprez(a)gmail.com> wrote:
>> Dear community,
>>
>> I setup a syncrepl between my master openldap server and a consumer.
>>
>> I am trying to use SSL for this syncrepl
>> I got the following error in the log when I start slapd on the consumer :
>>
>> Oct 13 17:04:59 server slapd[16905]: slapd starting
>> Oct 13 17:04:59 server slapd[16905]: slap_client_connect:
>> URI=ldaps://ldap.mydomain.fr:1024/
>> DN="cn=syncrepluser,o=others,dc=mydomain,dc=fr" ldap_sasl_bind_s
>> failed (-1)
>> Oct 13 17:04:59 server slapd[16905]: do_syncrepl: rid=003 rc -1
>> retrying (9 retries left)
>>
>>
>> I don't understand why it is failing as a single ldapsearch from the
>> same server with the syncrepl user is working.
>>
>> here is my syncrepl configuration :
>>
>> Syncrepl rid=003
>> provider=ldaps://ldap.mydomain.fr:1024/
>> type=refreshOnly
>> retry="60 10 600 +"
>> interval=00:00:00:10
>> searchbase="dc=mydomain,dc=fr"
>> scope=sub
>> schemachecking=on
>> bindmethod=simple
>> binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
>> credentials=my_password
>>
>>
>> Any idea ?
>>
>> Regards,
>>
>> Hugo
>>
>>
>
Yeah, that's actually how I started and where the starttls=no setting came from.
This .conf section
overlay chain
chain-uri "ldaps://ds2-q.global.aep.com"
chain-rebind-as-user TRUE
chain-idassert-bind bindmethod=simple binddn="cn=syncuser,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" credentials=<redacted> mode="self"
chain-tls ldaps tls_cacert=/appl/openldap/etc/openldap/tls/cacerts.cer
chain-return-error TRUE
becomes this ldap backend when using slaptest
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 bdc4cf96
dn: olcDatabase={1}ldap
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {1}ldap
olcDbURI: "ldaps://ds2-q.global.aep.com"
olcDbStartTLS: ldaps starttls=no tls_cacert="/appl/openldap/etc/openldap/tl
s/cacerts.cer" tls_reqcert=demand tls_crlcheck=none
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bin
dmethod=simple timeout=0 network-timeout=0 binddn="cn=syncuser,ou=automaton
s,ou=users,dc=global,dc=aep,dc=com" credentials=<redacted> keepalive=0:0:0
olcDbRebindAsUser: TRUE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
structuralObjectClass: olcLDAPConfig
entryUUID: 7b1cc741-120e-4ce2-b539-17791a361cb1
creatorsName: cn=config
createTimestamp: 20170707202053Z
entryCSN: 20170707202053.340477Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20170707202053Z
I guess it's time to start diving into the source.
-Jon
-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@symas.com]
Sent: Friday, July 07, 2017 3:45 PM
To: Jon C Kidder; openldap-technical(a)OpenLDAP.org
Subject: RE: [EXTERNAL] Re: back-ldap and ldaps not working
--On Friday, July 07, 2017 8:10 PM +0000 Jon C Kidder <jckidder(a)aep.com>
wrote:
> I've removed the starttls=no syntax and the line now reads.
>
> olcDbStartTLS: ldaps
> tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer "
> tls_reqcert=demand tls_crlcheck=none
>
> I have verified the change propagated to the configuration directory and
> restarted the instance. I saw no errors during configuration parsing in
> the log. I am still seeing this error when the chain overlay tries to
> follow the referral but no complaints when syncrepl connects.
I'm not sure how you do this with cn=config. With slapd.conf, it would be done via using "chain-tls" and not "tls", as per the man page:
There are very few chain overlay specific directives;
however,
directives related to the instances of the ldap backend that may be
implicitly instantiated by the overlay may assume a special meaning
when used in conjunction with this overlay. They are described
in
slapd-ldap(5), and they also need to be prefixed by chain-.
It may be worthwhile to set up a slapd.conf where "chain-tls" is specified, and see what happens with that on conversion.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.symas.com&d=DwICAg&… >
