I'm programming some automated changes to our LDAP database, and I have an
# Error: Invalid DN syntax (34), additional info: invalid new RDN
So is the new RDN "subntbcst-tftp@247/tcp" really invalid? If so it seems an
older version of OpenLDAP accepted that as we have such an entry:
I saw this exaple in RFC 2849 (so I thought my LDIF shuld be OK):
# Modify an entry’s relative distinguished name
dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
newrdn: cn=Paula Jensen
with OpenLDAP 2.4.47 (running on Debian 10) but also with 2.5.13 from ltb-project.org (running on same Debian
10) I can observe the following:
given following rough idea of a tree
| - handful of entries
| - millions of entries
| |- bn=sub-subtree1
| |- bn=sub-subtree2
| |- some entries
ou is an indexed attribute with pres,eq,sub. When now searching with the filter bn=<value> then there is a
significant difference when searching for either subtree1 and subtree2 as values in the range of seconds. This
means on command line ldapsearch with subtree1 it is around 0.007 seconds and with subtree2 4.5 seconds before
the fully finishes.
When I change the search filter to "(&(objectClass=bnClass)(bn=<value>))" then this has no real impact to the
time needed searching for subtree1 but improves searching subtree2, still it more than 2 times slower than
searching for subtree1. Only entries with objectClass=bnClass have the bn attribute but no other entries.
Changing the scope to one, yields similar times when searching for subtree1 and subtree2 but the search itself
also to cover searching for sub-subtree1 or sub-subtree2 with the same search task as it is not known where
such sub-subtree could be found.
The only pattern I've found so far is that if there are millions of entries in a subtree then finishing the
search takes much longer.
The LDAP is using MDB, and has been completely rebuilt (means slapcat/slapadd) several times with always
showing the same results. There was no difference between 2.4 and 2.5.13.
Is there something which can be improved by changing the configuration?
when trying to use the pcache overlay for an MDB database instance, it seems to work, at least some first test
search seem to be significantly improved but then the slapd process without anything in the logs (no segfault
at least). Unfortunately it is not possible to restart the slapd process either, as it also soon dies after
The config used looks something like the following:
olcPcache: mdb 1000 1 1000 100
olcPcacheAttrset: 0 bn attribute1 attribute2 objectClass
olcPcacheTemplate: "(&(|(objectClass=)(objectClass=))(bn=))" 0 120
olcPcacheTemplate: "(bn=)" 0 120
olcDbIndex: objectClass eq
olcDbIndex: bn pres,eq,sub
Is pcache supposed to work as an overlay for mdb database? Or does it only work with an ldap backend db?
Several years ago I added ipService to our LDAP Database, then I thought it's time to update it.
Now I have a conceptual problem:
Some services have multiple protocols and port numbers. For example "compressnet".
While it's possible to assign unique names like
I wonder how a standard query for "compressnet" should look like.
Basically I'd like to leave out the port (@n), but the IANA registry is not unique.
I identified these:
It seems ipService can have multiple values for ipServiceProtocol, cn, and ipServiceProtocol, but wouldn't that silently assume that all port numbers are valid for all listed protocols? For the example it would be any combination of (UDP,TCP) and (2,3).
To me the only solution seems to force IANA to clean up the mess.
RFC-6335/BCP-165 claims: "Service names are the unique key in the Service Name and Transport Protocol Port Number registry." (page 8)
I am trying to set up OpenLDAP on Arch Linux on my server, following
instruction on Arch Wiki. I prepared the config.ldif file, replacing
every $BASEDN and $PASSWD in the example configuration:
# The root config entry
# TODO: Include further schemas as necessary
# The config database
# The database for our entries
# TODO: Create further indexes
olcDbIndex: objectClass eq
Then I executed the following command:
sudo -u ldap slapadd -n 0 -F /etc/openldap/slapd.d/ -l ./config.ldif
This gave me the following error:
invalid config directory /etc/openldap/slapd.d/, error 2
slapadd: bad configuration directory!
I checked that the directory did not exist, so I created it and changed
owner to `ldap`. The wiki page did not mention that the directory should
be created earlier, so maybe it should have been created by a post
installation script. If that's the case, I will report it to package
After I created the directory, I ran the command again, this time having
a different error message:
slapadd: could not add entry dn="cn=config" (line=1):
I have no idea what is wrong now and I cannot find anything useful on
the internet. Does anyone have an idea what I may be doing wrong here?
I have the need to search a whole sub-tree for something like collective
attributes which AFAIK slapo-collect does not support.
Now I'm wondering whether it's possible to search for the virtual
attributes generated by slapo-variant. And probably I'd like to use the
I've read the section LIMITATIONS in slapo-variant(5) which says that
regex variants only support reading the virtual attributes with scope
base. It also implies that searching for these virtual attributes is not
possible at all.
Is that correct?
For a matter of studying OpenLDAP, I decided to create a CLI in Golang
that is based on the migrationtools
(https://gitlab.com/future-ad-laboratory/migrationtools), which is
written in Bash and (very old) Perl code.
All the Golang module is available here:
After learning about the memberof overlay, I've being wondering if it is
possible to use it to maintain the UNIX groups at /etc/group instead of
just replicating the same information over an over.
I've tried to find references in the documentation of using PAM and NSCD
in the Linux clients for authenticating from a OpenLDAP server, but
found nothing regarding those requirements, neither a detailed
explanation (without resorting looking into the source code) of how
those requests from a Linux client would be sent to OpenLDAP in order to
If any has any pointers on the subject, I would be glad to receive them.
Thanks in advance,
I have a case where I got access to a read-only LDAP that has no
authentication (everything is public). It is located in a secure and
Now I want to expose the directory to another network and like to add
authentication but can not add it to the source (proprietary
I need to proxy this server and authenticate the users using active directory.
I know how to proxy AD including passthrough authentication but can I
proxy another directory and authenticate using another? If yes, how?
Thank you very much.
On Wed, Aug 17, 2022 at 12:16 PM Quanah Gibson-Mount
> --On Wednesday, August 17, 2022 2:11 PM +0530 Vijay Maidarkar
> <vmaidarkar(a)gmail.com> wrote:
> Hi, please keep replies on the list.
> > Find below answers.
> > Where is it installed?
> > $ which openssl
> > /usr/local/bin/openssl
> > $ ldd /usr/local/bin/openssl
> > linux-vdso.so.1 => (0x00007fff931e6000)
> > libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f7f7a570000)
> > libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f7f7a087000)
> > libdl.so.2 => /lib64/libdl.so.2 (0x00007f7f79e83000)
> > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7f79c67000)
> > libc.so.6 => /lib64/libc.so.6 (0x00007f7f79899000)
> > /lib64/ld-linux-x86-64.so.2 (0x00007f7f7a802000)
> > How was it installed?
> > I've downloaded the archive & done compilation from below cmds.
> > $ ./config
> > $ make
> > $ make install
There are other options you should be using for OpenSSL. At minimum,
you probably want enable-ec_nistp_64_gcc_128 on x86_64. Also see
> So, you built it yourself so there will be no development package. I'm not
> sure why you built such an ancient version of OpenSSL (you listed OpenSSL
> 1.1.1g when 1.1.1q is the most recent), since it's vulnerable to multiple
> critical CVEs.
> I'd strongly advise using the packages from EPEL if you insist on staying
> on CentOS7 (which is near end of life).
> If you are going to use your own OpenSSL build, I can't emphasize enough
> the importance of using a current release. Since you're doing this in an
> unpackaged way, maintenance is going to be a nightmare.
> Since you've built it yourself into its own location, you have to tell the
> configure script where to find the development headers, like:
> CPPFLAGS="/usr/local/include" LDFLAGS="-L/usr/local/lib
> -Wl,-rpath,/usr/local/lib" ./configure ...
+1 for the RPATH.
Linux (and other OSes) have a (mis)feature of building against one
version of a library, and runtime linking against another version of
the library. Be sure to specify the RPATH to avoid the bug.
(If you want to see the effects of linking against the wrong library
at runtime, see
Nowadays on Linux you should specify a RUNPATH, not a RPATH. The
RUNPATH allows LD_LIBRARY overrides to search paths. It is recommended
by the folks who write the runtime loaders. The options you need are:
* -Wl,-rpath,<lib path> (enables RPATH)
* -Wl,--enable-new-dtags (enables RUNPATH)