On 6/29/2023 11:29 PM, Windl, Ulrich wrote:
> I think there's something missing: When *creating* the certificate "It proves that the bearer owns the DN" (done by RA/CA), but when *using* the certificate (by a client) the server should still check whether the certificate matches the client. Otherwise any stolen certificate could be used to gain access from everywhere. MHO.
When you say "matches the client", what do you mean? That the client's
IP address maps to a name on the certificate? Remember that in DNS the
mapping from IP address to name is under the control of the person who
owns the IP address, not the person who owns the name. Remember also
that the client may be behind a NAT that hides their IP address.
Finally, remember that the client may legitimately change its IP address
and DNS name (if any) from time to time as it is moved from one location
to another (think phone, or laptop, or desktop moving from one office to
another) or networks are reconfigured around it.
This is asymmetric from the more common server authentication. For
server authentication, the server has a stable name, and that name was
supplied by the human and so can be trusted (more or less) and checked
against the certificate. In fact, that human-supplied name serves
exactly the same purpose as an "authorized DN" list: it says which
certificates are acceptable.
Net... you're absolutely right, if somebody steals your certificate -
more precisely, your private key - they can use it to gain access. It
is exactly as for a password: a username and password authenticates the
user, but if somebody steals your password, they can masquerade as you.
Depending on your particular scenario, it might be appropriate to have
*additional* checks - acceptable networks, et cetera - or require
multiple factors (e.g. certificate plus password). Those additional
checks are not part of the certificate-based authentication process.
Somebody stealing your private key may well be Game Over. Don't let
people steal it.
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris
On Fri, 23 Jun 2023 at 12:04, Quanah Gibson-Mount <quanah(a)fast-mail.org> 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?
I am reading at the moment RFC 7628 (SASL for OAuth). The idea is to
extend usage of OAuth outside of the HTTP world. It has obviously been
written with SMTP & IAMP in mind. It seems that it could be a very nice
solution for authenticating web frontends accessing dir. servers
(typically web based directory browsers). Correct if I am missing a
point here, pls.
As far as I understand, OL does not support it (again, feel free to
correct). Are there any plans to look into it ?
While I write to an LMDB database, while it gets bigger and bigger, I can see %MEM in top rising steadily.
This is because %MEM is composed of three things, including "RSfd". From the top manpage:
RSfd -- Resident File-Backed Memory Size (KiB)
A subset of resident memory (RES) representing the implicitly shared pages supporting program images and shared libraries. It also includes explicit file mappings, both private and shared.
Is it memory mapping that's resulting in the higher RSfd?
RSfd increases do not seem to have an effect on "buff/cache" or "avail Mem", i.e. what most people think as "RAM" is not being used up. I still want to ask, could too high RSfd use result in less efficient use of memory for other programs? I'm essentially wondering how efficient common OSes (e.g. MacOS, Linux) are in this area.
I'd like to propose a new feature to substantially strengthen the
existing access controls in slapd. This follows on from comments made in
the discussion around Issue 10065. In particular Comment 17 and Comment 19.
The objective here is to validate the credentials supplied by external
security mechanisms BEFORE the main server loop starts, and terminate
the connection if the client is not "known".
It was noted that the olcAuthzRegexp configuration option already deals
with externally supplied Authentication ID. My idea is to build on that.
I propose a new flag for "olcDisallows" that is "unmatched_external_authid".
Setting this flag would instruct slapd to drop the connection if the
externally supplied authid did not match any of the olcAuthzRegexp rules.
Currently the olcAuthzRegexp rules are only applied after a command
arrives. My proposal does not change that, instead I propose that
olcAuthzRegexp be evaluated at "connection time" as well as at
"execution time". This would reduce the chance of any unexpected side
The only real issue I can think of is - is it possible for
olcAuthzRegexp to match an AuthID without changing it. Is there any
recursion in the application of these rules?
This email has been checked for viruses by AVG antivirus software.
Sean Gallagher wrote:
> On 26/06/2023 7:40 pm, Howard Chu wrote:
>> That feature is already available using TLSVerifyClient in the slapd config.
> Not really. Using the TLSVerifyClient mechanism could be made to work and would be a nice solution but it isn't there yet. To make this this work, you would
> need to pass to libldap, some type of specification of the names of legitimate clients. Then in the tls_o.c:tlso_verify_cb() function, compare the name on the
> client cert with the specification and return the pass/fail status back to the TLS layer. Then it would all "just work".
> The average user might be surprised to learn that TLSVerifyClient does not currently involve checking the client's name. You would intuitively think that was
> pretty important.
The point of a certificate-based authentication system is not to have to implement authentication rules
for each and every individual user. An LDAP server should only trust certificates issued by a single CA;
that CA should only be issuing certs to valid users. Ideally, the LDAP server should be the CA, which is
what slapo-autoca is designed for.
An LDAP server is not a web server or a client. There is no reason for it to trust certs from multiple CAs.
>> Pure nonsense.
> Pure hubris.
> It's sad when it takes a disaster to affect real change.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Thanks Quanah. Just to follow-up:
Yes, with an ldap listener on 0.0.0.0, openldap is *still* able to
determine it's own serverID when multiple are configured, based on the
In my config I do:
serverID 1 ldaps://my.ldapserver1.com
serverID 2 ldaps://my.ldapserver2.com
(nota bene FQDN)
and the local hostname is obviously NOT a FQDN but just a (short) hostname.
But it is still matched correctly, which is phenomenal, and not something I
could read / understand from the docs! :-)
I also tested, by changing the config to a non-existing "serverID 2 ldaps://
my.ldapserver5.com <http://my.ldapserver2.com>", and then we do get the
"read_config: no serverID / URL match found. Check slapd -h arguments."
Impressed by openldap's cleverness. :-)
On Tue, 27 Jun 2023 at 17:40, Quanah Gibson-Mount <quanah(a)fast-mail.org>
> --On Monday, June 26, 2023 10:18 PM +0200 cYuSeDfZfb cYuSeDfZfb
> <cyusedfzfb(a)gmail.com> wrote:
> > 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?
> This is determined in the following code block in servers/slapd/config.c:
> So that's the magic you are looking for.
In an attempt to standardize our config as much as possible, we included in
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)
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'm curious what with modern slapd + LMDB should be looked for that would
drive such a spike. I thought perhaps there were a significant number of
write operations at the same time, but this was not the case, there was no
unusual level of write activity. There were also much lower than usual
number of concurrent connections across the cluster during this time
(~800), we usually have closer to 2k-3k concurrent connections. The total
number of initiated operations during the time frame was also within normal
range. There was also nothing unusual about amount of network traffic, it
fit right in with normal traffic levels.
One thing that I did see is that there was an unusually high number of
'deferring operation: binding' messages. We normally average about
400/day, but on this specific day we hit > 1500 such messages.
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 <quanah(a)fast-mail.org>
> --On Thursday, June 22, 2023 10:46 AM +0200 cYuSeDfZfb cYuSeDfZfb
> <cyusedfzfb(a)gmail.com> wrote:
> > Hi,
> > I'm posting this mostly for the archives, so that a search for the error
> > below will help a next person.
> Please open a bug on this issue at https://bugs.openldap.org