openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

Q: sync provider: "additional info: <olcUpdateRef> must appear after syncrepl or updatedn"
by Windl, Ulrich 04 Jul '25

04 Jul '25

Hi! I tried to set up a sync provider to have a UpdateRef pointing to itself, while not pulling any changes from anywhere. The idea was that the sync consumers will copy that UpdateRef and direct updates to the provider that way. This is a MMR scenario during migration where config is synced, too. So the current scenario is like this: P1 (provider, OpenLDAP 2.4) | | V v C1 <--> C2 (consumer, OpenLDAP 2.5) I could ldapmodify the change, but when doing a" slapcat -n0" now, I get the error: 68679fc8 olcUpdateRef: value #0: <olcUpdateRef> must appear after syncrepl or updatedn 68679fc8 config error processing olcDatabase={0}config,cn=config: <olcUpdateRef> must appear after syncrepl or updatedn slapcat: bad configuration file! Adding up to three "-c" options did not help (in old OpenLDAP 2.4) Should there be an exception if UpdateRef is pointing to the local server? Kind regards, Ulrich Windl

1 0

Q: "monitor_back_register_entry("cn=Consumer 112,cn=Database 1,cn=Databases,cn=Monitor"): entry exists"
by Windl, Ulrich 04 Jul '25

04 Jul '25

Hi! For openldap-2.5 and an MMR configuration I see the message monitor_back_register_entry("cn=Consumer 112,cn=Database 1,cn=Databases,cn=Monitor"): entry exists during startup. I'm wondering what the messages actually says, and what causes it. Could it be some bug in OpenLDAP? The machine in question is real hardware (no VM) and it has a *lot* of RAM (500G) and CPUs (64). If I query the monitoring database, I see no such connection. Kind regards, Ulrich Windl

2 5

many connections in proxy setup
by Bergmann, Clemens 04 Jul '25

04 Jul '25

Hi, we have two openLDAP Servers configured with back_ldap. Each server has one non-OpenLDAP-Server as “target”. I passed a redacted copy of my configuration below. At any given time we have around 100 connections from clients to the openLDAP Server. I noticed that there are a lot more connections open from the ldap Server to the “target” Servers. Sometimes close to 1000. As this is a temporary setup I did not investigate any more. In the last days we sometimes see the following errors in log: “daemon: accept(10) failed errno=24 (Too many open files)” “connection_input: conn=1799 deferring operation: too many executing” “connection_read(446): no connection!” I suspect that this is because there are more than 1024 connections open and the OS is preventing opening more FDs. I am not sure why we have so many open connections to the “target” servers. Maybe someone can spot my config error. Thanks in advance. dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/lib/openldap/slapd.args olcIdleTimeout: 15 olcLocalSSF: 256 olcLogLevel: none olcPidFile: /var/lib/openldap/slapd.pid olcRootDSE: /etc/openldap/rootDSE.ldif olcSaslSecProps: noplain,noanonymous olcSecurity: simple_bind=256 ssf=256 tls=0 olcTLSCACertificateFile: /etc/ssl/certs/ca-bundle.crt olcTLSCertificateFile: /etc/openldap/certs/server.pem olcTLSCertificateKeyFile: /etc/openldap/certs/server.key olcTLSCipherSuite: DEFAULT:-SHA1:-CBC olcTLSDHParamFile: /etc/openldap/dhparam.pem olcTLSProtocolMin: 3.3 dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcAccess: redacted olcDbACLBind: bindmethod=simple binddn=cn=proxy,ou=admin,o=tu-darmstadt credentials=redacted tls_cacert=/etc/ssl/certs/ca-bundle.crt olcDbStartTLS: ldaps tls_cacert=/etc/ssl/certs/ca-bundle.crt olcDbURI: ldaps://backend-server01.example.com/ olcRootDN: cn=admin,ou=admin,o=tu-darmstadt olcSizeLimit: unlimited olcSuffix: o=tu-darmstadt olcTimeLimit: 90 Kind regards Clemens (Bergmann) -- Clemens Bergmann [er/ihm; he/him] Gruppe Nutzermanagement und Entwicklung Technische Universität Darmstadt Hochschulrechenzentrum, Alexanderstraße 2, 64283 Darmstadt Tel. +49 6151 16 71184 <http://www.hrz.tu-darmstadt.de/> http://www.hrz.tu-darmstadt.de/

3 4

Re: slapadd: could not add entry dn="cn=config" (line=1):
by Nick 03 Jul '25

03 Jul '25

I figured it out. I needed to only include the slapd.conf file in the directory, not slapd.ldif. Also generated rfc2307bis files and populated the database. Very cool! Thanks to the developers here! On Tue, Jul 1, 2025 at 7:10 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Sunday, June 29, 2025 2:49 AM -0400 Nick <atod101101(a)gmail.com> > wrote: > > > > Import the configuration database > > su root -c /usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l > > /usr/local/etc/openldap/slapd.ldif > > What is the contents of slapd.ldif? And I assume the > /usr/local/etc/slapd.d/ directory exists and has no contents. > > --Quanah > > > >

1 0

slapadd: could not add entry dn="cn=config" (line=1):
by Nick 01 Jul '25

01 Jul '25

Does anyone know the source and resolution to this installation error? Interestingly, if I use an alternate command I'm able to bring up the server, in which I can see via debug it's responding to the client. I'm following: https://www.openldap.org/doc/admin24/quickstart.html Import the configuration database su root -c /usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l /usr/local/etc/openldap/slapd.ldif and encounter this error. I see many posts on it with no resolution. I'm using MacPorts openldap 2.6.10. Interestingly, if I invoke this suggested command: /opt/local/libexec/slapd -f /opt/local/etc/openldap/slapd.conf -F /opt/local/etc/slapd.d I can invoke slapd and my LDAP server comes up. It responds back to: /opt/local/bin/ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts but without dc=site,dc=com only blank dn: dn: # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 There is nothing in my etc/slapd.d directory. I try: ldapadd -d 3 -x -D "cn=Manager,dc=p0,dc=mac" -W -f file.txt Enter LDAP Password: ldap_bind: Invalid DN syntax (34) additional info: invalid DN Not sure how to approach this and any guidance appreciated.

3 2

Translucent proxy with posix attributes and sssd
by Howard, Christopher 30 Jun '25

30 Jun '25

I currently manage ldap for a subset of users at our organization for some separate systems. The organization also uses ldap for all of its users. My separate ldap server uses different usernames for its users. I've been tasked with getting rid of this separate ldap, migrating all of our systems over to the central ldap and having users use their normal organizational credentials. To that end, I've created a new ldap server as a translucent proxy. The central ldap does not contain posix attributes. I'm not being permitted to create them and they are not willing to add them. I've tested with my new proxy that I can search for a user, retrieve all of their back end ldap attributes and all of my local overlay attributes. The translucent proxy is working. Now I'm to the step of setting up sssd to authenticate users on linux hosts. This is not working because sssd searches using a filter that contains objectclass=posixAccount and uidNumber. I've ensured that those values are in my overlay, but they do not exist in the back end ldap. As a result, I get no user returned from the search. I've changed sssd config to make objectclass=person in the search filter, but that still leaves the uidNumber issue. Is there any way around this? I've exhausted the documentation for sssd and don't see it. Is there a way in the ldap proxy to handle this? Do I need to set olcTranslucentLocal to define the local only attributes? My guess is I'll have the same issue with groups and gidNumber when I get to that step of the process as well. If this is a dead end, are there any other options to do what I need to do? Thank you, -Christopher

2 1

Odd "<= str2entry NULL (smr_normalize createTimestamp 21)" when trying slapadd to cn=config
by Windl, Ulrich 30 Jun '25

30 Jun '25

Hi! Trying to create the initial config from LDIF using "slapadd -v -F /etc/openldap/slapd.d -w -S 3 -n0 -l 0.ldif" inSLES15 I get this: added: "cn=config" (00000001) added: "cn=module{0},cn=config" (00000001) added: "cn=schema,cn=config" (00000001) added: "cn={0}core,cn=schema,cn=config" (00000001) added: "cn={1}cosine,cn=schema,cn=config" (00000001) added: "cn={2}inetorgperson,cn=schema,cn=config" (00000001) added: "cn={3}rfc2307bis,cn=schema,cn=config" (00000001) added: "cn={4}yast,cn=schema,cn=config" (00000001) added: "cn={5}sudo,cn=schema,cn=config" (00000001) added: "olcDatabase={-1}frontend,cn=config" (00000001) <= str2entry NULL (smr_normalize createTimestamp 21) slapadd: could not parse entry (line=2360) Closing DB... I've done that on a different machine without any errors so far. The LDIF entry after "olcDatabase={-1}frontend,cn=config" is "dn: olcDatabase={0}config,cn=config". The timestamps are: creatorsName: cn=config createTimestamp: 20130712083810Z entryCSN: 20160222141054.581517Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20160222141054Z An "interesting" fact I found in /etc/openldap/slapd.d/cn=config/cn=schema.ldif was the end of the file; it reads: ... anslucentNoGlue $ olcTranslucentLocal $ olcTranslucentRemote $ olcTranslucent BindLocal $ olcTranslucentPwModLocal ) )lucent target database configuration' AUXILIARY )lue uniqueness configuration' SUP olcOverlayConfig STRUCTURAL MAY ( olcUniqueBase $ olcUniqueIgnore $ olcUniqueAttribute $ olcUniqueStrict $ o lcUniqueURI ) )g configuration' SUP olcOverlayConfig STRUCTURAL MUST olcValSo rtAttr )LIARY MAY ( olmBDBEntryCache $ olmBDBDNCache $ olmBDBIDLCache $ olmDb Directory ) )NSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )MAN-READABLE 'TRUE' )tion' )DABLE 'TRUE' )ADABLE 'TRUE' )TRANSFER-REQUIRED 'TRUE' X-NOT-HU MAN-READABLE 'TRUE' )NARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE ' )INARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )ficate' X-BINA RY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )ription' )scription' )umber' )ABLE 'TRUE' )DABLE 'TRUE' )ess Points' )tion' )cription' )' )' )ion ' ) ) ) )X-BINARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )tifie r' )on' )n' )on' )) Exact Assertion' ) Assertion' ) ) That doesn't look right for me. CPU here is an "AMD EPYC 9354P 32-Core Processor", while the other machine without problems ran with VMware and "Intel(R) Xeon(R) Gold 6238R CPU @ 2.20GHz"; Looks like the last write to the config database is nor correct in case of errors. Neither option "-c" (continue), nor "-o value-check=no", nor "-o schema-check=no" did help. After some experiments I get a different error like "<= str2entry NULL (smr_normalize creatorsName 21)" Any insights? Kind regards, Ulrich Windl

1 1

Assert failed in ldap_do_free_request()
by radiatejava 29 Jun '25

29 Jun '25

Hello experts We are using OpenLDAP lib ver 2.6.7 on Ubuntu 24.04. When doing LDAP search using ldap_search_ext_s() we are getting assert failure. Any idea what could be going wrong? Appreciate your reply. Here is the stacktrace: #0 0x000071e8baceeb2c in pthread_kill () from /usr/lib/x86_64-linux-gnu/libc.so.6 #1 0x000071e8bac9527e in raise () from /usr/lib/x86_64-linux-gnu/libc.so.6 #2 0x000071e8bac788ff in abort () from /usr/lib/x86_64-linux-gnu/libc.so.6 #3 0x000071e8bac7881b in ?? () from /usr/lib/x86_64-linux-gnu/libc.so.6 #4 0x000071e8bac8b517 in __assert_fail () from /usr/lib/x86_64-linux-gnu/libc.so.6 #5 0x000071e8b9684409 in ldap_do_free_request () from /opt/ldap/lib/libldap.so.2 #6 0x000071e8b96b4bf9 in ldap_tavl_free () from /opt/ldap/lib/libldap.so.2 #7 0x000071e8b968359a in ldap_free_connection () from /opt/ldap/lib/libldap.so.2 #8 0x000071e8b9683e9c in ldap_new_connection () from /opt/ldap/lib/libldap.so.2 #9 0x000071e8b9682aa7 in ldap_send_server_request () from /opt/ldap/lib/libldap.so.2 #10 0x000071e8b9685619 in ldap_chase_v3referrals () from /opt/ldap/lib/libldap.so.2 #11 0x000071e8b9667640 in try_read1msg () from /opt/ldap/lib/libldap.so.2 #12 0x000071e8b9666515 in wait4msg () from /opt/ldap/lib/libldap.so.2 #13 0x000071e8b9665f09 in ldap_result () from /opt/ldap/lib/libldap.so.2 #14 0x000071e8b9672a95 in ldap_sasl_bind_s () from /opt/ldap/lib/libldap.so.2 #15 0x000071e8b96740b2 in ldap_simple_bind_s () from /opt/ldap/lib/libldap.so.2 #16 0x000071e8bb737e2a in myapp::getRebindCredentials(ldap*, char const*, unsigned long, int, void*) () from /mgmt/usr/lib/x86_64-linux-gnu/libsvc_myapp.so #17 0x000071e8b9683e0b in ldap_new_connection () from /opt/ldap/lib/libldap.so.2 #18 0x000071e8b9682aa7 in ldap_send_server_request () from /opt/ldap/lib/libldap.so.2 #19 0x000071e8b9685619 in ldap_chase_v3referrals () from /opt/ldap/lib/libldap.so.2 #20 0x000071e8b9667640 in try_read1msg () from /opt/ldap/lib/libldap.so.2 #21 0x000071e8b9666515 in wait4msg () from /opt/ldap/lib/libldap.so.2 #22 0x000071e8b9665f09 in ldap_result () from /opt/ldap/lib/libldap.so.2 #23 0x000071e8b966acf7 in ldap_pvt_search_s () from /opt/ldap/lib/libldap.so.2 #24 0x000071e8b966ac25 in ldap_search_ext_s () from /opt/ldap/lib/libldap.so.2 #25 0x000071e8bb732c15 in myapp::LdapAuthenticationBroker::doLdapAuthenticate() () from /mgmt/usr/lib/x86_64-linux-gnu/libsvc_myapp.so #26 0x000071e8bb732484 in myapp::LdapAuthenticationBroker::start(bool&, void (*)(myapp::ExternalAuthenticationBroker*)) () from /mgmt/usr/lib/x86_64-linux-gnu/libsvc_myapp.so

3 4

Configuring LDAP server and NFS client, login credentials and to mount NFS directories?
by Nick 29 Jun '25

29 Jun '25

Does anyone know the steps to configure a LDAP server to provide login credentials to a client (Linux) and NFS mount points? I think this is some industry standard for authenticating and automatically mounting NFS directories. So far, I have configured: - NFS server (MacOS) - QEMU for VM - DHCP/BootP server to provide NIS/LDAP options (IP of NIS and LDAP servers) - openldap server, tested installation However, I'm looking for the next steps to accomplish such a task. This could include any references to web pages on the topic.

1 0

Another request related to openldap backsock backend
by Gianluca Ramunno 26 Jun '25

26 Jun '25

Hello, I made quite some progress with developing an LDAP proxy using openldap + backsock backend + a python server. The backsock backend and the python server communicate via UNIX socket according to the protocol described here: https://linux.die.net/man/5/slapd-sock The python server at the moment implements the execution of the BIND and of the SEARCH operations against a remote LDAP server and returns back the results to the backsock backend. Using the command ldapsearch I perform some SEARCH operations and I see a weird behaviour when the output is printed out by ldapsearch; I request a number of attributes which are returned correctly by the remote LDAP server to the python server, then the latter prepares an LDIF chunk with the returned entry (with all requested attributes) and sends this chunk back to the openldap backsock backend via UNIX socket. Unfortunately, ldapsearch prints out the received entry with a lower number of attributes. The missing attributes are always the same (at a repeated execution of the same SEARCH), but non necessarily the last one(s). I don't receive back any error. In the python server I also print out the whole LDIF chunk just before sending it back to the backsock backend and all attributes are there. I also checked that the protocol between backsock backend and the python server is correct according to the specifications. Note that if I perform the same SEARCH operations with ldapsearch directly against the remote LDAP server (i.e. without the LDAP proxy in between), all requested attributes are returned and printed correctly. Any clue on what's happening or on how to debug this problem in openldap? Thank you in advance. Best regards Gianluca Ramunno

1 1

← Newer
1
2
3
4
5
6
7
8
...
994
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical