[EdLUG] OpenLDAP slap client and/or syncrepl error
Mark Cairney
Mark.Cairney at ed.ac.uk
Tue May 24 08:26:11 UTC 2022
Hi,
OK good to see the syncrepl directives are the same/consistent. Note
you're specifying a cert, key and cacert file specifically for syncrepl
in your config.
RE: /etc/ldap/ldap.conf this is used by the client utilities e.g.
openldap so what I think is happening is that as the certs presented by
your LDAP servers isn't trusted on at least one of your servers (when
acting as a client/performing queries) the client commands e.g.
ldapsearch are failing to negotiate a TLS connection.
There will also be global TLS settings which will determine which cert
your servers will present to clients e.g.
olcTLSCACertificateFile: /opt/openldap/certs/quovadis.bundle
olcTLSCertificateFile:
/opt/openldap/certs/authorise-test.is.ed.ac.uk-QUOVADIS.crt
olcTLSCertificateKeyFile:
/opt/openldap/certs/authorise-test.is.ed.ac.uk-QUOVADIS.key
The ca-certificates.crt is a client-managed bundle file (usually managed
by a ca-certificates package on the system?)
Hope this explains/describes the situation and setup a bit better?
I can supply a reference config for comparison if that's useful off-list
although our config has a lot of custom attributes/schema entries and
multiple databases as we use delta-syncrepl rather than standard syncrepl.
On 21/05/2022 12:24, Tahir Hafiz wrote:
> This email was sent to you by someone outside the University.
> You should only click on links or attachments if you are certain that
> the email is genuine and the content is safe.
> Hmmm....Thanks Mark
>
> On sso1 ldap and on sso2 ldap
> (/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif) I see this:
> olcSyncrepl: {0}rid=004 provider=ldaps://sso1.redacted.net/
> <http://sso1.redacted.net/> binddn="cn=admin
> ,dc=redacted,dc=net" bindmethod=simple credentials=REDACTED searchb
> ase="dc=redacted,dc=net" type=refreshOnly
> tls_cacert=/etc/ssl/certs/GandiSt
> andardSSLCA2.pem tls_cert=/etc/ssl/certs/redacted-2018.crt
> tls_key=/etc/ssl
> /private/redacted.net.key interval=00:00:00:10 retry="5 5 300 5"
> timeout=1
> olcSyncrepl: {1}rid=005 provider=ldaps://sso2.redacted.net/
> <http://sso2.redacted.net/> binddn="cn=admin
> ,dc=redacted,dc=net" bindmethod=simple credentials=REDACTED searchb
> ase="dc=redacted,dc=net" type=refreshOnly
> *tls_cacert=/etc/ssl/certs/GandiSt
> andardSSLCA2.pem* tls_cert=/etc/ssl/certs/redacted-2018.crt
> tls_key=/etc/ssl
> /private/redacted.net.key interval=00:00:00:10 retry="5 5 300 5"
> timeout=1
>
> So those entries do look the same on both sso1 ldap and sso2 ldap for
> the file olcDatabase={1}hdb.ldif but on sso1 ldap for
> /etc/ldap/ldap.conf I see:
> *TLS_CACERT /etc/ssl/certs/ca-certificates.crt *
> *
> *
> And on sso2 ldap for /etc/ldap/ldap.conf I see*:
> *
> *TLS_CACERT /etc/ssl/certs/RapidSSLIntermediate.pem*
>
>
> From what I can tell *ca-certificates* (on sso1 ldap from
> /etc/ldap/ldap.conf) is a bundle of different certificates,
> *RapidSSLIntermediate.pem* (on sso2 ldap from /etc/ldap/ldap.conf) is
> a single certificate and the *GandiSt
> andardSSLCA2.pem* (listed on both sso1 ldap and sso2 ldap, from file
> olcDatabase={1}hdb.ldif) is a single certificate (Intermediate
> certificate from the registrar Gandi). I'm not sure why the entries
> are all different - should they all be the same cert ideally?
>
> I also don't understand how synch between the two ldap servers is
> working if the TLS is broken.
>
>
> On Fri, May 20, 2022 at 10:41 PM CAIRNEY Mark <Mark.Cairney at ed.ac.uk>
> wrote:
>
> Hi,
> It’s been a while since I looked at OpenLDAPs certs (and it’s
> behavior differs slightly depending on which SSL lib it was linked
> against). I think Debian linked against openssl though. The
> TLSCACert should point to a bundle containing all the roots and
> intermediates of any certs in okay (it’s not fussy about order but
> needs the full set. It’s more of a trust store than a cert chain
> in that respect). The other thing is ensuring that the server cert
> has the correct FQDNs in it. We have a common cert with all the
> server CNs as Subject AltNames to ensure consistency.
> This is all dredged from memory, as you can guess from the sig I’m
> not currently sitting in front of an LDAP Server to confirm! ;)
>
> Sent from my iPhone
>
>> On 20 May 2022, at 20:50, Tahir Hafiz <tahir.hafiz at gmail.com> wrote:
>>
>>
>> This email was sent to you by someone outside the University.
>> You should only click on links or attachments if you are certain
>> that the email is genuine and the content is safe.
>> Thanks Mark, I realised I never restarted slapd on the sso2 ldap
>> box when I renewed the certs there and this what I see upon
>> restarting the slapd service:
>>
>> May 20 19:35:36 sso2 slapd[17605]: slapd starting
>> May 20 19:35:36 sso2 slapd[17605]: slap_client_connect:
>> URI=ldaps://sso1.redacted.net/ <http://sso1.redacted.net/> TLS
>> context initialization failed (-1)
>> May 20 19:35:36 sso2 slapd[17605]: do_syncrepl: rid=001 rc -1
>> retrying (4 retries left)
>> May 20 19:35:36 sso2 slapd[17605]: slap_client_connect:
>> URI=ldaps://sso1.redacted.net/ <http://sso1.redacted.net/>
>> DN="cn=admin,dc=redacted,dc=net" ldap_sasl_bind_s failed (-1)
>> May 20 19:35:36 sso2 slapd[17605]: do_syncrepl: rid=004 rc -1
>> retrying (4 retries left)
>>
>> And on the sso1 ldap box I still see this upon restarting slapd
>> there:
>>
>> May 20 19:36:26 sso1 slapd[16803]: slapd starting
>> May 20 19:36:26 sso1 slapd[16803]: slap_client_connect:
>> URI=ldaps://sso2.redacted.net/ <http://sso2.redacted.net/> TLS
>> context initialization failed (-1)
>> May 20 19:36:26 sso1 slapd[16803]: do_syncrepl: rid=002 rc -1
>> retrying (4 retries left)
>> May 20 19:36:32 sso1 slapd[16803]: SASL [conn=1001] Failure: no
>> secret in database
>>
>> So sso2 ldap box seems to be doing a bit better (one less error).
>> Is there a way I can troubleshoot which certificates in the chain
>> are causing the issue - like some interesting commands?
>> I will try and look at the SASL config too to see where the
>> secret is missing.
>>
>> Unfortunately, these seem to be quite dated Ubuntu 14 boxes.
>>
>> Thank you!
>>
>> On Fri, May 20, 2022 at 7:49 PM CAIRNEY Mark
>> <Mark.Cairney at ed.ac.uk> wrote:
>>
>> Hi,
>> I think there are 2 issues at play
>> 1. The certs/CA isn’t right on one of the servers (hence the
>> TLS errors) do the syncrepl bind is failing.
>> 2. It looks like SASL can’t find a password entry for the
>> user in the bind attempt. Might be worth checking your SASL
>> config to ensure the mechanisms you expect are available and
>> your authzregexp is set up correctly.
>>
>> Sent from my iPhone
>>
>>> On 20 May 2022, at 18:56, Tahir Hafiz
>>> <tahir.hafiz at gmail.com> wrote:
>>>
>>>
>>> This email was sent to you by someone outside the University.
>>> You should only click on links or attachments if you are
>>> certain that the email is genuine and the content is safe.
>>> Hi,
>>>
>>> We have two OpenLDAP servers (sso1 and sso2, ignore alpha -
>>> that one I think they decommissioned it years ago).
>>> sso1 and sso2 are meant to be in mirror mode (sometimes
>>> called multi-master mode).
>>> I had to switch sso1 off a while ago because it was no
>>> longer responding and didn't have much time to look at it
>>> back then.
>>>
>>> I have now had some spare time to look at it, updated the
>>> web certs which had to be renewed and restarted the openldap
>>> server in question.
>>> But I see the following error (and Google has not helped
>>> much on this one):
>>>
>>> May 20 16:11:44 sso1 slapd[9008]: slapd starting
>>> May 20 16:11:44 sso1 slapd[9008]: slap_client_connect:
>>> URI=ldaps://alpha.redacted.net/ <http://alpha.redacted.net/>
>>> TLS context initialization failed (-1)
>>> May 20 16:11:44 sso1 slapd[9008]: do_syncrepl: rid=003 rc -1
>>> retrying (4 retries left)
>>> May 20 16:11:44 sso1 slapd[9008]: slap_client_connect:
>>> URI=ldaps://sso2.redacted.net/ <http://sso2.redacted.net/>
>>> TLS context initialization failed (-1)
>>> May 20 16:11:44 sso1 slapd[9008]: do_syncrepl: rid=002 rc -1
>>> retrying (4 retries left)
>>> May 20 16:12:13 sso1 slapd[9008]: SASL [conn=1001] Failure:
>>> no secret in database
>>>
>>> The weird thing is the OpenLDAP sso1 box is synching to sso2
>>> ldap box, and I can connect to it with an ldap client on my
>>> home desktop and it now has the latest records so it is
>>> working as an ldap server but I'm not sure what the errors
>>> really mean.
>>> Are there any avenues I can explore on this or has anyone
>>> seen something like this before (N.B. I am no ldap expert) ?
>>>
>>> Thanking you in advance,
>>> Tahir
>>> --
>>> EdLUG mailing list
>>> EdLUG at mailman.lug.org.uk
>>> https://lists.edlug.org.uk/mailman/listinfo/edlug
>> The University of Edinburgh is a charitable body, registered
>> in Scotland, with registration number SC005336. Is e
>> buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann,
>> clàraichte an Alba, àireamh clàraidh SC005336.
>> --
>> EdLUG mailing list
>> EdLUG at mailman.lug.org.uk
>> https://lists.edlug.org.uk/mailman/listinfo/edlug
>>
>> --
>> EdLUG mailing list
>> EdLUG at mailman.lug.org.uk
>> https://lists.edlug.org.uk/mailman/listinfo/edlug
> --
> EdLUG mailing list
> EdLUG at mailman.lug.org.uk
> https://lists.edlug.org.uk/mailman/listinfo/edlug
>
>
--
/****************************
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email:Mark.Cairney at ed.ac.uk
*******************************/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.edlug.org.uk/pipermail/edlug/attachments/20220524/de24b1b4/attachment-0001.htm>
More information about the EdLUG
mailing list