Re: What drives CPU usage spikes?

[Paul Jackson]

Many things can cause a CPU usage spike.

If you don't already know, then the first step is finding out
what process is spiking.

When I ran an active website for several years, I developed
a very efficient monitoring program, that watched the system
and recorded when a program was consuming more CPU or
memory than was normal.

This monitoring program consumes almost no resources when
the system is not overloaded, and very few resources even when
it is overloaded.  You can set command line options to specify
what details you want to see of processes causing an overload,
and what constitutes an overload worth reporting.

I just now uploaded this program to:

https://github.com/ThePythonicCow/batch_top

I left this program running all the time, in the background,
on the webserver I managed, and referred to the output
when some unexpected overload started causing a problem.

-- 
Paul Jackson
p...@usa.net

Re: What drives CPU usage spikes?

[David Hawes]

On Fri, 23 Jun 2023 at 12:04, Quanah Gibson-Mount  wrote:
>
> In our 2.6.4 deployment, we had a significant spike in CPU usage one day
> last week that lasted approximately 2 hours (8 AM UTC to 10 AM UTC).
> During this time, some clients started timing out when talking to the LDAP
> service, and search response times spiked as well, up to 9.5 seconds on
> searches that normally take < 3 seconds (they do have large result sets).
> This happened on all 6 of the read nodes that we have in our load balance
> pool, so whatever the issue was hit all of them at the same time.  It did
> not happen to 2 specialized read nodes that only serve one specific
> service, so it was something about the traffic going to those 6 nodes.  The
> number of ops/second during that time frame was actually lower than usual
> across the cluster, with a peak of 200 ops/second.  We often have higher
> peaks than that without this type of CPU usage spiking.

I've noticed similar behavior on large accesslog purges. High CPU,
poor response times, sometimes slapd even becomes unresponsive. Do
these systems have an accesslog that gets purged?

Re: problem, and solution | database monitor

[cYuSeDfZfb cYuSeDfZfb]

I created https://bugs.openldap.org/show_bug.cgi?id=10073

Thanks for making available a great product.

On Mon, 26 Jun 2023 at 18:41, Quanah Gibson-Mount 
wrote:

>
>
> --On Thursday, June 22, 2023 10:46 AM +0200 cYuSeDfZfb cYuSeDfZfb
>  wrote:
>
> >
> >
> > Hi,
> >
> >
> > I'm posting this mostly for the archives, so that a search for the error
> > below will help a next person.
>
> Hi,
>
> Please open a bug on this issue at https://bugs.openldap.org
>
> Thanks!
>
> Regards,
> Quanah
>
>
>
>

observation on serverID / URI match

[cYuSeDfZfb cYuSeDfZfb]

Hi,

In an attempt to standardize our config as much as possible, we included in
our slapd.conf:

serverID 1 ldaps://my.ldapserver1.com
serverID 2 ldaps://my.ldapserver2.com
serverID 3 ldaps://my.ldapserver3.com
serverID 4 ldaps://my.ldapserver4.com

The hostname of the RHEL9 servers is set to ldapserver1 & ldapserver2, but
on the hosts slapd is configured to run like:

/opt/symas/lib/slapd -d 0 -h ldap:/// ldaps:/// ldapi:/// -u ldap -g ldap
(so... NO uri specified, also not in /etc/default/symas-openldap)

We expected to receive an error like: no match between serverID and URI
found, but much to our surprise we don't. :-)

Now we wonder if the serverID is determined and set correctly or not
and even with loglevel -1 the auto-determined "local serverID" is not
logged on start.

Does anyone know?

Can the serverID also be determined from the local hostname? Or is there
any other magic going on?
And otherwise... why is everything starting regularly, and are we not
getting the error message?

(we are running a 4 server multi-master replication setup, and replication
with the above setting in place is still working normally)

Re: RE25 testing call (2.5.15) #1

[Shawn McKinney]

Tested installation and smoke tested on RH7,8,9, D10, 11, U18, 20, 22 and SLES 
15.4.

Also, stress tested on U22. 

Tests all ran OK.

—
Shawn

> On May 25, 2023, at 3:41 PM, Quanah Gibson-Mount  wrote:
> 
> This is the first testing call for OpenLDAP 2.5.15.  Depending on the 
> results, this may be the only testing call.
> 
> NOTE: This release adds support for OpenSSL 3.0 to the 2.5 release series.
> 
> Generally, get the code for RE25:
> 
> 
> 
> Extract, configure, and build.
> 
> Execute the test suite (via make test) after it is built.  Optionally, cd 
> tests && make its to run through the regression suite.
> 
> Thanks!
> 
> OpenLDAP 2.5.15 Engineering
>   Added libldap openssl3 support (ITS#9436, ITS#10030)
>   Fixed libldap handling of TCP KEEPALIVE options (ITS#10015)
>   Fixed libldap with async connections (ITS#10023)
>   Fixed libldap openssl TLSv1.3 cipher suite handling (ITS#10035)
>   Fixed slapd callback handling with overlays that do extended operations 
> (ITS#9990)
>   Fixed slapd conversion of pcache configurations (ITS#10031)
>   Fixed slapd cn=config modification handling with abandon (ITS#10045)
>   Fixed slapo-constraint handling of push replication (ITS#9953)
>   Fixed slapo-dynlist filter evaluation efficiency (ITS#10041)
>   Fixed slapo-pcache handling of invalid schema (ITS#10032)
>   Fixed slapo-ppolicy handling of push replication (ITS#9953)
>   Fixed slapo-ppolicy handling of pwdMinDelay (ITS#10028)
>   Fixed slapo-syncprov abandon handling (ITS#10016)
>   Fixed slapo-translucent handling of invalid schema (ITS#10032)
>   Fixed slapo-unique handling of push replication (ITS#9953)
>   Fixed slapo-variant to improve regex handling (ITS#10048)
>   Build Environment
>   Fixed compatibility with stricter C99 compilers (ITS#10011)
>   Keep .pc files during make clean (ITS#9989)
>   Contrib
>   Fixed slapo-variant handling of push replication (ITS#9953)
>   Minor Cleanup
>   ITS#9855
>   ITS#9995
>   ITS#9996
>   ITS#9997
>   ITS#9998
>   ITS#
>   ITS#1
>   ITS#10003
>   ITS#10004
>   ITS#10033
>   ITS#10037
>   ITS#10039
>   ITS#10046
> 
> Regards,
> Quanah

Re: RE26 testing call (2.6.5) #1

[Shawn McKinney]

Tested installation and smoke tested on RH7,8,9, D10, 11, U18, 20, 22 and SLES 
15.4.

Also, stress tested on RHEL8. 

Tests all ran OK.

—
Shawn

> On May 25, 2023, at 3:39 PM, Quanah Gibson-Mount  wrote:
> 
> This is the first testing call for OpenLDAP 2.6.5.  Depending on the results, 
> this may be the only testing call.
> 
> Generally, get the code for RE26:
> 
> 
> 
> Extract, configure, and build.
> 
> Execute the test suite (via make test) after it is built.  Optionally, cd 
> tests && make its to run through the regression suite.
> 
> Thanks!
> 
> OpenLDAP 2.6.5 Engineering
>   Fixed libldap handling of TCP KEEPALIVE options (ITS#10015)
>   Fixed libldap with async connections (ITS#10023)
>   Fixed libldap openssl TLSv1.3 cipher suite handling (ITS#10035)
>   Fixed slapd callback handling with overlays that do extended operations 
> (ITS#9990)
>   Fixed slapd conversion of pcache configurations (ITS#10031)
>   Fixed slapd cn=config modification handling with abandon (ITS#10045)
>   Fixed slapd-mdb online indexer termination and cleanup (ITS#9993)
>   Fixed slapd-mdb online indexer when interrupted (ITS#10047)
>   Fixed slapd-monitor connection cleanup (ITS#10042)
>   Fixed slapo-constraint handling of push replication (ITS#9953)
>   Fixed slapo-dynlist filter evaluation efficiency (ITS#10041)
>   Fixed slapo-pcache handling of invalid schema (ITS#10032)
>   Fixed slapo-ppolicy handling of push replication (ITS#9953)
>   Fixed slapo-ppolicy handling of pwdMinDelay (ITS#10028)
>   Fixed slapo-syncprov abandon handling (ITS#10016)
>   Fixed slapo-translucent handling of invalid schema (ITS#10032)
>   Fixed slapo-unique handling of push replication (ITS#9953)
>   Fixed slapo-variant to improve regex handling (ITS#10048)
>   Build Environment
>   Fixed compatibility with stricter C99 compilers (ITS#10011)
>   Keep .pc files during make clean (ITS#9989)
>   Contrib
>   Fixed slapo-variant handling of push replication (ITS#9953)
>   Minor Cleanup
>   ITS#9855
>   ITS#9995
>   ITS#9996
>   ITS#9997
>   ITS#9998
>   ITS#
>   ITS#1
>   ITS#10003
>   ITS#10004
>   ITS#10033
>   ITS#10037
>   ITS#10039
>   ITS#10046
> 
> Regards,
> Quanah

Re: problem, and solution | database monitor

[Quanah Gibson-Mount]

--On Thursday, June 22, 2023 10:46 AM +0200 cYuSeDfZfb cYuSeDfZfb 
 wrote:





Hi,


I'm posting this mostly for the archives, so that a search for the error
below will help a next person.


Hi,

Please open a bug on this issue at https://bugs.openldap.org

Thanks!

Regards,
Quanah

Re: slapacl issue

[Quanah Gibson-Mount]

--On Friday, June 16, 2023 12:39 PM + Carsten Jäckel 
 wrote:



Dear experts,

in a testing environment (SLES 15 SP5, OpenLDAP 2.5.14) I use the
following ACLs in olcAccess:

Am I doing something wrong?



Hi Carsten,

Please open a ticket on this at https://bugs.openldap.org

Regards,
Quanah

Re: What drives CPU usage spikes?

[Quanah Gibson-Mount]

--On Friday, June 23, 2023 7:59 PM +0200 Erik de Waard 
 wrote:




I see this on our consumers when waiting on writes to be accepted by the
provider/ or when it's unreachable.



Thanks.  Not the issue in my case though. :/

--Quanah

Re: unable to authenticate, ldaps

[Quanah Gibson-Mount]

--On Monday, June 26, 2023 6:06 PM +0200 cYuSeDfZfb cYuSeDfZfb 
 wrote:




That's probably our issue! But I can't find that line olcAccess: {0} in
our slapd.conf and the included files.


Yes, that would be the issue! :)

--Quanah

Re: unable to authenticate, ldaps

[cYuSeDfZfb cYuSeDfZfb]

I found something in the ACL that looks like it is the problem:

#  grep -R -i olcaccess ./*
  ./cn=config/olcDatabase={0}config.ldif:olcAccess: {0}to *  by * none
  ./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {0}to *  by * none
  ./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {1}to attrs=userpassword
 by anonymous auth  by * none break
  ./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {2}to dn.base=""  by * read
  ./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {3}to attrs=entry  by *
read
  ./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {4}to
dn.subtree="o=ldap,c=com"  attrs=objectclass,mail,givenName,sn
  ./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {5}to *  by
dn.base="cn=mirrormode,ou=system,o=ldap,c=com"
followed by more of the same.

We are actually running slapd.conf with included files, but output above
was taken from the slapd.d directory, generated using slaptest -f
slapd.conf -F /tmp/slapd.d

The slapd.d generated dir contains olcDatabase={1}mdb.ldif:olcAccess: {0}to
*  by * none *ABOVE * olcAccess: {1}to attrs=userpassword  by anonymous
auth  by * none break

That's probably our issue! But I can't find that line olcAccess: {0} in our
slapd.conf and the included files.

Wondering now how it got there. But... locating that is something for
another day.

You helped us again. (unless you disagree that this is most likely our
issue?)

Thanks, I will post the result after I manage to get that ACL {0} out of my
config.

On Mon, 26 Jun 2023 at 16:44, cYuSeDfZfb cYuSeDfZfb 
wrote:

> Hi,
>
> I was preparing some more logging to show. You were *really* quick in your
> reply! :-)
>
> Below more logging, and I will reply to your ACL question next.
>
> Replication after setting the password:
>
> Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 ACCEPT from IP=
> 192.168.16.36:45316 (IP=0.0.0.0:636)
> Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 TLS established
> tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384
> Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 closed
> (connection lost)
> Jun 26 16:36:09 ldapserver1 slapd[409642]: do_syncrep2: rid=234
> cookie=rid=234,sid=0dd,csn=20230626143609.891703Z#00#0dd#00
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_message_to_entry:
> rid=234 DN: uid=testuser,ou=Users,o=ldap,c=com, UUID:
> a8ccf30a-88d0-103d-8b70-5f35ddf1cc44
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
> csn=20230626143609.891703Z#00#0dd#00 tid 0x7f68a6afd640
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
> be_search (0)
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
> uid=testuser,ou=Users,o=ldap,c=com
> Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing
> 0x7f689c10e190 20230626143609.891703Z#00#0dd#00
> Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=-1 op=0 syncprov_matchops:
> recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com on
> opc=0x7f689c008f90
> Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1
> syncprov_matchops: skipping original sid 0dd
> Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1
> syncprov_matchops: skipping original sid 0dd
> Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
> removing 0x7f689c10e190 20230626143609.891703Z#00#0dd#00
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
> be_modify uid=testuser,ou=Users,o=ldap,c=com (0)
> Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing
> 0x7f689c10a010 20230626143609.891703Z#00#0dd#00
> Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
> removing 0x7f689c10a010 20230626143609.891703Z#00#0dd#00
>
> Failed authentication using the correct password:
>
> Jun 26 16:36:26 ldapserver1 slapd[409642]: conn=1164 fd=17 ACCEPT from IP=
> 192.168.16.36:46196 (IP=0.0.0.0:636)
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 TLS established
> tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 BIND
> dn="uid=testuser,ou=Users,o=ldap,c=com" method=128
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0
> syncprov_matchops: recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com
> on opc=0x7f689c008ed0
> Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_get_csn: conn=1164 op=0
> generated new csn=20230626143627.270437Z#00#0de#00 manage=1
> Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_queue_csn: queueing
> 0x7f689c110220 20230626143627.270437Z#00#0de#00
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_qresp:
> set up a new syncres mode=2 csn=20230626143627.270437Z#00#0de#00
> Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
> removing 0x7f689c110220 20230626143627.270437Z#00#0de#00
> Jun 26 16:36:27 ldapserver1 slapd[409642]: co

Re: unable to authenticate, ldaps

[cYuSeDfZfb cYuSeDfZfb]

Hi,

I was preparing some more logging to show. You were *really* quick in your
reply! :-)

Below more logging, and I will reply to your ACL question next.

Replication after setting the password:

Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 ACCEPT from IP=
192.168.16.36:45316 (IP=0.0.0.0:636)
Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 TLS established
tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384
Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 closed
(connection lost)
Jun 26 16:36:09 ldapserver1 slapd[409642]: do_syncrep2: rid=234
cookie=rid=234,sid=0dd,csn=20230626143609.891703Z#00#0dd#00
Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_message_to_entry:
rid=234 DN: uid=testuser,ou=Users,o=ldap,c=com, UUID:
a8ccf30a-88d0-103d-8b70-5f35ddf1cc44
Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
csn=20230626143609.891703Z#00#0dd#00 tid 0x7f68a6afd640
Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
be_search (0)
Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
uid=testuser,ou=Users,o=ldap,c=com
Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing
0x7f689c10e190 20230626143609.891703Z#00#0dd#00
Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=-1 op=0 syncprov_matchops:
recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com on
opc=0x7f689c008f90
Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1
syncprov_matchops: skipping original sid 0dd
Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1
syncprov_matchops: skipping original sid 0dd
Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
removing 0x7f689c10e190 20230626143609.891703Z#00#0dd#00
Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
be_modify uid=testuser,ou=Users,o=ldap,c=com (0)
Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing
0x7f689c10a010 20230626143609.891703Z#00#0dd#00
Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
removing 0x7f689c10a010 20230626143609.891703Z#00#0dd#00

Failed authentication using the correct password:

Jun 26 16:36:26 ldapserver1 slapd[409642]: conn=1164 fd=17 ACCEPT from IP=
192.168.16.36:46196 (IP=0.0.0.0:636)
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 TLS established
tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 BIND
dn="uid=testuser,ou=Users,o=ldap,c=com" method=128
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0
syncprov_matchops: recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com
on opc=0x7f689c008ed0
Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_get_csn: conn=1164 op=0
generated new csn=20230626143627.270437Z#00#0de#00 manage=1
Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_queue_csn: queueing
0x7f689c110220 20230626143627.270437Z#00#0de#00
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_qresp:
set up a new syncres mode=2 csn=20230626143627.270437Z#00#0de#00
Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
removing 0x7f689c110220 20230626143627.270437Z#00#0de#00
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1
syncprov_sendresp: to=0dd,
cookie=rid=243,sid=0de,csn=20230626143627.270437Z#00#0de#00
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1
syncprov_sendresp: sending LDAP_SYNC_MODIFY,
dn=uid=testuser,ou=Users,o=ldap,c=com
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 RESULT tag=97
err=49 qtime=0.15 etime=0.001002 text=
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=1 UNBIND
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 closed

On Mon, 26 Jun 2023 at 16:36, Quanah Gibson-Mount 
wrote:

>
>
> --On Monday, June 26, 2023 5:28 PM +0200 cYuSeDfZfb cYuSeDfZfb
>  wrote:
>
> >
> >
> > Hi all!
> >
> >
> > We have this in place:olcAccess: {1}to attrs=userpassword  by anonymous
> > auth  by * none break
>
> It's impossible to answer this question without knowing the rest of your
> ACLs.  For example the acl in slot {0} could mean that the acl in slot {1}
> is never evaluated.
>
> --Quanah
>
>
>
>

Re: unable to authenticate, ldaps

[Quanah Gibson-Mount]

--On Monday, June 26, 2023 5:28 PM +0200 cYuSeDfZfb cYuSeDfZfb 
 wrote:





Hi all!


We have this in place:olcAccess: {1}to attrs=userpassword  by anonymous
auth  by * none break


It's impossible to answer this question without knowing the rest of your 
ACLs.  For example the acl in slot {0} could mean that the acl in slot {1} 
is never evaluated.


--Quanah

unable to authenticate, ldaps

[cYuSeDfZfb cYuSeDfZfb]

Hi all!

We have this in place:
olcAccess: {1}to attrs=userpassword  by anonymous auth  by * none break

Using the RootDN to set a user password:

# ldappasswd -H ldaps://my.ldapserver1.com -D "cn=admin,o=ldap,c=com" -W
 -S "uid=testuser,ou=Users,o=ldap,c=com" -v
  New password: 
  Re-enter new password: 
  Enter LDAP Password: 
  ldap_initialize( ldaps://my.ldapserver1.com:636/??base )
  Enter LDAP Password:
  Result: Success (0)

We observe the password change replicate (master-master) to our other
server.

Then to test access:

# ldapsearch -H ldaps://my.ldapserver1.com -s base -b o=ldap,c=com -D
"uid=testuser,ou=Users,o=ldap,c=com" -w  -v
  ldap_initialize( ldaps://my.ldapserver1.com:636/??base )
  ldap_bind: Invalid credentials (49)

More background: this is fresh a master-master setup, replication works
with the root DN, and all other user authentications fails with the same
Invalid credentials (49)

The server ldaps://my.ldapserver1.com is an actual single (master) server,
no load balancers, no firewalling. Configured an with actual (and valid)
certificate, ldapsearch uses the correct CA, and ldapsearch with the root
DN works fine. This is latest symas openldap 2.5 on RHEL9.

Anyone with an idea why we can only authenticate as the RootDN, and all
other authentications give Invalid credentials (49)?

We have double checked whatever we can think of, and are *really* unsure
what is going on

Hoping for some clues from the experts here :-)

Re: Proposal to strengthen slapd EXTERNAL authentication

[Howard Chu]

Sean Gallagher wrote:
> It seems there is no interest in this. That's disappointing but not 
> unexpected. Personally, I find it reckless that slapd would accept and 
> process packets from
> parties that would happily take a flame thrower to your server if it got them 
> any advantage.
> 
> I would strongly encourage the OpenLDAP team to properly validate PKI client 
> certificates and CLOSE THE CONNECTION if the client fails authentication.

That feature is already available using TLSVerifyClient in the slapd config.
> 
> I have made one proposal about how to add this functionality but I'm sure 
> there are many ways to approach it.
> 
> In the mean time, I will continue using the proxy in front of slapd and would 
> strongly recommend anyone using client certs for authentication without a
> dedicated CA to do the same.

Pure nonsense.
> 
> In all other repects,
> 
>   thanks for a great product.
> 
>     Sean.
> 
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/