openldap-technical October 2025

openldap-technical@openldap.org

15 participants
7 discussions

Question about OpenLDAP modules
by Dino Edwards 28 Oct '25

28 Oct '25

Hello, Hoping someone can help me with this issue I'm having. I'm building OpenLDAP from source using the following command: ./configure --prefix=/usr/local \ --with-tls \ --with-cyrus-sasl \ --enable-overlays \ --enable-modules \ --enable-argon2 \ --enable-remoteauth && \ make depend && make -j$(nproc) && make install && \ ldconfig It looks like it builds correctly, however I'm not seeing the remoteauth.la or remoteauth.so module under /usr/local/libexec/openldap directory. I'm only seeing the argon2.so and argon2.la. When I bootstrap the server with the following it doesn't throw any errors: modulepath /usr/local/libexec/openldap moduleload back_mdb.la moduleload argon2.la moduleload remoteauth.la The weird thing is that when I run this command it shows the installed modules with remoteauth being one of them: ldapsearch -Y EXTERNAL -H "$LDAPI_URI" -b "cn=module{0},cn=config" olcModuleLoad SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <cn=module{0},cn=config> with scope subtree # filter: (objectclass=*) # requesting: olcModuleLoad # # module{0}, config dn: cn=module{0},cn=config olcModuleLoad: {0}back_mdb.la olcModuleLoad: {1}argon2.la olcModuleLoad: {2}remoteauth.la # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 So, I'm not sure how it's loading remoteauth.la since it's not present under the /usr/local/libexec/openldap directory. As a matter of fact, it doesn't seem to be anywhere on the file system. I tried authenticating a user using remoteauth to a remote AD directory and it didn't seem to work. In all fairness, I'm not sure if I was doing it correctly. Thanks in advance

2 1

admin can bind, normal user cannot, err=49
by hamzaahmed12328＠gmail.com 26 Oct '25

26 Oct '25

OS: Debian 13 Running in an LXC on Proxmox VE 9.0.10 OpenLDAP Ver: @(#) $OpenLDAP: slapd 2.6.10+dfsg-1 (May 29 2025 23:41:48) $ Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Current mdb ACL (Playing around with ACLS to get this to work) # {1}mdb, config dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=externa l,cn=auth" manage olcAccess: {1}to * by dn.exact="cn=admin,dc=ahmza,dc=com" manage olcAccess: {2}to attrs=userPassword by anonymous auth by self auth olcAccess: {3}to * by * none Oct 25 02:30:35 ldap slapd[460]: >>> slap_listener(ldaps:///) Oct 25 02:30:35 ldap slapd[460]: conn=1011 fd=15 ACCEPT from IP=10.10.100.12:19604 (IP=0.0.0.0:636) Oct 25 02:30:35 ldap slapd[460]: connection_get(15): got connid=1011 Oct 25 02:30:35 ldap slapd[460]: connection_read(15): checking for input on id=1011 Oct 25 02:30:35 ldap slapd[460]: connection_get(15): got connid=1011 Oct 25 02:30:35 ldap slapd[460]: connection_read(15): checking for input on id=1011 Oct 25 02:30:35 ldap slapd[460]: connection_read(15): unable to get TLS client DN, error=49 id=1011 Oct 25 02:30:35 ldap slapd[460]: conn=1011 fd=15 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 Oct 25 02:30:35 ldap slapd[460]: connection_get(15): got connid=1011 Oct 25 02:30:35 ldap slapd[460]: connection_read(15): checking for input on id=1011 Oct 25 02:30:35 ldap slapd[460]: op tag 0x60, time 1761359435 Oct 25 02:30:35 ldap slapd[460]: conn=1011 op=0 do_bind Oct 25 02:30:35 ldap slapd[460]: >>> dnPrettyNormal: <uid=jellyfin,ou=service-accounts,dc=ahmza,dc=com> Oct 25 02:30:35 ldap slapd[460]: <<< dnPrettyNormal: <uid=jellyfin,ou=service-accounts,dc=ahmza,dc=com>, <uid=jellyfin,ou=service-accounts,dc=ahmza,dc=com> Oct 25 02:30:35 ldap slapd[460]: conn=1011 op=0 BIND dn="uid=jellyfin,ou=service-accounts,dc=ahmza,dc=com" method=128 Oct 25 02:30:35 ldap slapd[460]: do_bind: version=3 dn="uid=jellyfin,ou=service-accounts,dc=ahmza,dc=com" method=128 Oct 25 02:30:35 ldap slapd[460]: mdb_dn2entry("uid=jellyfin,ou=service-accounts,dc=ahmza,dc=com") Oct 25 02:30:35 ldap slapd[460]: => mdb_dn2id("uid=jellyfin,ou=service-accounts,dc=ahmza,dc=com") Oct 25 02:30:35 ldap slapd[460]: <= mdb_dn2id: got id=0xa Oct 25 02:30:35 ldap slapd[460]: => mdb_entry_decode: Oct 25 02:30:35 ldap slapd[460]: <= mdb_entry_decode Oct 25 02:30:35 ldap slapd[460]: => access_allowed: result not in cache (userPassword) Oct 25 02:30:35 ldap slapd[460]: => access_allowed: auth access to "uid=jellyfin,ou=service-accounts,dc=ahmza,dc=com" "userPassword" requested Oct 25 02:30:35 ldap slapd[460]: => acl_get: [1] attr userPassword Oct 25 02:30:35 ldap slapd[460]: => acl_mask: access to entry "uid=jellyfin,ou=service-accounts,dc=ahmza,dc=com", attr "userPassword" requested Oct 25 02:30:35 ldap slapd[460]: => acl_mask: to value by "", (=0) Oct 25 02:30:35 ldap slapd[460]: <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth Oct 25 02:30:35 ldap slapd[460]: <= acl_mask: no more <who> clauses, returning =0 (stop) Oct 25 02:30:35 ldap slapd[460]: => slap_access_allowed: auth access denied by =0 Oct 25 02:30:35 ldap slapd[460]: => access_allowed: no more rules Oct 25 02:30:35 ldap slapd[460]: send_ldap_result: conn=1011 op=0 p=3 Oct 25 02:30:35 ldap slapd[460]: send_ldap_response: msgid=1 tag=97 err=49 Oct 25 02:30:35 ldap slapd[460]: conn=1011 op=0 RESULT tag=97 err=49 qtime=0.000029 etime=0.000148 text= Oct 25 02:30:35 ldap slapd[460]: connection_get(15): got connid=1011 Oct 25 02:30:35 ldap slapd[460]: connection_read(15): checking for input on id=1011 Oct 25 02:30:35 ldap slapd[460]: op tag 0x42, time 1761359435 Oct 25 02:30:35 ldap slapd[460]: ber_get_next on fd 15 failed errno=0 (Success) Oct 25 02:30:35 ldap slapd[460]: conn=1011 op=1 do_unbind Oct 25 02:30:35 ldap slapd[460]: conn=1011 op=1 UNBIND Oct 25 02:30:35 ldap slapd[460]: connection_close: conn=1011 sd=15 Oct 25 02:30:35 ldap slapd[460]: conn=1011 fd=15 closed Im happy to share my config too but this is already getting long

2 1

ldap search is failing with error "Bad search filter (-7)" for complex search filter having spaces in OpenLDAP 2.6.7
by venugopal chinnakotla 24 Oct '25

24 Oct '25

Hi Team, We are working on migration of nsldap C sdk to OpenLDAP C sdk for our application client code. We are using OpenLDAP 2.6.7. As part of this migration, we are facing one issue with a search filter that we are using to get content from LDAP servers. search filter: (| (uid=user1) (| (mail=user1(a)test.com) (! (mail= user100(a)test.com) ) ) ) We are using this search filter for user lookup from LDAP servers in our application for one of our cases. We are using OpenLDAP C API: ldap_search_ext_s (and/or ldap_search_ext) in our application. When we make a search call from our application to LDAP server using the above search filter, we are getting "Bad search filter (-7)" error instead of the users list. Due to this, our migration is blocked. Tried using the same search filter with *ldapsearch *utility provided by OpenLDAP, but getting the same error message. Below is the snippet of error with search filter. *>ldapsearch.exe -H ldap://ldapserver1.com:389 <http://ldapserver1.com:389> -D "cn=admin,o=test.com <http://test.com>" -b o=test.com <http://test.com> "(| (uid=user1) (| (mail=user1(a)test.com <user1(a)test.com>) (! (mail=user100(a)test.com <user100(a)test.com>) ) ) )"# extended LDIF## LDAPv3# base <o=test.com <http://test.com>> with scope subtree# filter: (| (uid=user1) (| (mail=user1(a)test.com <user1(a)test.com>) (! (mail=user2(a)test.com <user2(a)test.com>) ) ) )# requesting: ALL#ldap_search_ext: Bad search filter (-7)* But the same search filter is working fine with our existing nsldap provider. We are able to get the users list from the LDAP server using the same search filter without any changes. To maintain backward compatibility in our application, we should be able to get the content from the LDAP server using the same search filter. Could you please look into this problem and provide a solution for this? -- Thanks, *c.venugopal*

7 8

Future of slapd.conf(5)
by christopher.schenk＠uni-paderborn.de 14 Oct '25

14 Oct '25

Hi, We are currently redesigning our OpenLDAP server setup. Until now we used one primary server with four replicas, which gets synced with syncrepl. Each server is using a slapd.conf (Which is deployed via a central config management). Using this setup, we can define one ACL entry set for our primary server and another set for our replicas. Also, this makes viewing and understanding these ACLs quite easy. As part of our redesign, I've looked up the documentation, which states: "slapd.conf(5) has been deprecated and should only be used if your site requires one of the backends that hasn't yet been updated to work with the newer slapd-config(5) system." Now my question is, is the slapd.conf going to be removed in future OpenLDAP versions, or will it remain in OpenLDAP? Should we move our configuration to the new slapd-config system? Kind regards, Christopher Schenk

3 2

Calling external hook for changes
by Greg Veldman 13 Oct '25

13 Oct '25

Are there any good options for calling an external hook function upon specific events such as updates to an entry? Specifically in this case I'm looking to hook password changes for user entries and perform some additional processing with the updated password. I found https://github.com/ether42/slapo-lua_hook but that looks like it's been abandoned for a couple years now. I also considered using slapo-auditlog and continuously watching the audit log file, but this raises concerns about log file management and security, and also requires another out-of-band process to monitor the log file. Not that those are super high bars to clear, but I'm hoping there may be a cleaner approach that someone is aware of. I did also check the docs for the other existing slapd overlays, both core and contrib, and unless I'm missing something the audit log overlay looked the most promising of those. Thanks. -- Greg Veldman

1 0

Migrating to Proxy Protocol / PLDAP
by Brendan Kearney 09 Oct '25

09 Oct '25

List members, i am running 3 OpenLDAP servers in a multi-provider replication setup, with HAProxy load balancing access to the service. i want to implement proxy-protocol, in order to see the client IP, not just the load balancers Source NAT. there are some hang ups i found when i tried this and i'm wondering if there is an easier way, or if i have all the places where config changes are needed. to start, i modified the startup configs so the "-h" parameter was "pldap://host.domain.tld". then i changed the olcServerID entries in cn=config to match. next i changed the olcSyncRepl entries to include "provider=pldap://host.domain.tld". then i made the changes to the HAProxy service and restarted everything. what i found was the replication failed, as the ldap instances were not sending the proxy-protocol headers to each other when attempting to initiate connections for replication. they replicate directly between each other and do not talk to the load balancer for replication. i may or may not have to change the "provider" string in the olcSyncRepl configs (i would like to confirm if this is needed or not), but ultimately the instances don't send the proxy-protocol headers so replication connections do not establish, and replication does not occur. as the servers stand, they only listen on one interface and all communication happens on this interface. the client connections coming from HAProxy, as well as replication connections all go in/out this one interface. is there a hack that can allow pldap:// and ldap:// listeners to exist on the same interface? if not, would i need to add some different interface for replication? the startup configs would then have "-h pldap://host.domain.tld ldap://host-repl.domain.tld". the olcServerID entries would be "ldap://host-repl.domain.tld", and the olcSyncRepl entries would be "provider=ldap://host-repl-domain.tld". are there any tips or tricks about doing this a different way? if not, do i have all the places that config changes are needed, to get this working correctly? thanks in advance, brendan kearney

2 2

Symas OpenLDAP 2.6.10-1 on EL8/EL9: SASL library version mismatch (expects 2.1.29, repos provide 2.1.28)
by anilkumar.pathuri7＠gmail.com 03 Oct '25

03 Oct '25

Hello Symas Support Team, We’re attempting to standardize on Symas OpenLDAP 2.6.10-1 across our fleet (RHEL/Rocky 8.10 and 9.6, x86_64). After upgrading, the binaries emit a SASL ABI error: ldap_int_sasl_init: SASL library version mismatch: expected 2.1.29, got 2.1.28 Environment OS: Rocky Linux 8.10, Rocky Linux 9.6, RHEL 8.10, RHEL 9.6 (x86_64) Symas repo: soldap-release26 (EL8 and EL9) Packages we installed (EL8/EL9): symas-openldap-servers-2.6.10-1.el8/.el9 symas-openldap-clients-2.6.10-1.el8/.el9 symas-openldap-libs-2.6.10-1.el8/.el9 symas-openldap-devel-2.6.10-1.el8/.el9 SASL packages visible in the repos: symas-cyrus-sasl-libs 2.1.28 (and variants like 2.1.28+20230721-1), no 2.1.29 listing on EL8 or EL9 dnf list --showduplicates symas-cyrus-sasl-libs on EL8 and EL9 shows only 2.1.28 builds in soldap-release26; no 2.1.29. Could you please advise us on how we can resolve this issue? Regards, Anil

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical October 2025