openldap-technical March 2021

openldap-technical@openldap.org

31 participants
41 discussions

opinions on schema-checking
by A. Schulze 08 Mar '21

08 Mar '21

Hello, I'm running a LDAP provider and multiple LDAP consumer and like to ask for your opinions to such a setup: While writing data to the LDAP provider, schema-checking is enforced. Currently also the LDAP consumer enforce schema checking. Q: does it make sense to enforce schema checking on a LDAP consumer, too? What pros and cons do you see? Thanks! Andreas

5 10

ldap_modify: Other (e.g., implementation specific) error (80)
by Stefan Bauer 06 Mar '21

06 Mar '21

Hi, the internet is full of "tips" to solve the above problem. I'm pulling my hairs and can not find the real issue since days. any help is greatly appreciated. --------- enable_ssl.ldiff --------------- dn: cn=config changetype: modify add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ldap/key.key dn: cn=config changetype: modify add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ldap/cert.pem --------- enable_ssl.ldiff --------------- # ls -alh /etc/ldap/cert.pem /etc/ldap/key.key -rwxrwxrwx 1 root root 1,1K Mär 1 21:43 /etc/ldap/cert.pem -rwxrwxrwx 1 root root 1,7K Mär 1 21:21 /etc/ldap/key.key # openssl rsa -noout -modulus -in /etc/ldap/key.key | openssl md5 (stdin)= 45b4165df200817a20857fb453acd33e # openssl x509 -noout -modulus -in /etc/ldap/cert.pem | openssl md5 (stdin)= 45b4165df200817a20857fb453acd33e # head -n2 /etc/ldap/cert.pem -----BEGIN CERTIFICATE----- MIIFmDCCBICgAwIBAgIQBFMR6HMGTGjQIjSj4sQX+TANBgkqhkiG9w0BAQsFADBu # head -n2 /etc/ldap/key.key -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAvrDddMwXoy10diqDpqd45jaC8HiGKz7KC5X3W0ZLvCshylu0 ldapmodify -Y EXTERNAL -H ldapi:/// -f enable_ssl.ldif -v # ldapmodify -Y EXTERNAL -H ldapi:/// -f enable_ssl.ldif -v ldap_initialize( ldapi:///??base ) SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 add olcTLSCertificateKeyFile: /etc/ldap/key.key modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) I can however modify other values like *olcLogLevel* without problems. Debian 10 latest: 2.4.47+dfsg-3+deb10u6 # slapd -VVV @(#) $OpenLDAP: slapd (Feb 14 2021 18:32:34) $ Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Included static backends: config ldif Stefan.

2 2

ACL for sync reader
by Frédéric Goudal 06 Mar '21

06 Mar '21

Hello, I have a production ldap with some acl set. For historical reason the synchronizationn is done with the root dn which is bad. I want to add a user to perform synchronization it must have the right to read everytthing. is the acl : access to * by dn.exact=<somedn> break added in first position be enough to read everything (even attributs that have been limited on some other acl) AND not break the current configuration ? Thanks in advance. f.g.

3 6

Re: Is there any easy way to decode openldap logs
by chandan jain 04 Mar '21

04 Mar '21

It is openldap-2.4.32, i don't see any mdb support option while compiling . It is compiled with below options: tar -xzf db-5.3.21.tar.gz tar -zxf openldap-2.4.32.tgz cd db-5.3.21 cd build_unix/ ../dist/configure --enable-compat185 --enable-dbm --disable-static --enable-cxx && make && make install db_verify -V cd ../.. cd openldap-2.4.32 ./configure --prefix=/usr/local/OpenLDAP --with-tls=no --enable-modules=yes --enable-overlays=yes --enable-ppolicy=yes && make depend && make && make install Regards Chandan On Thu, 4 Mar 2021 at 22:48, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Thursday, March 4, 2021 10:40 PM +0530 chandan jain > <chandandevops(a)gmail.com> wrote: > > > > > > > Thanks quanah, I will change log level to 256 to see the results. > > > > > > Also, is it possible to migrate from bdb to mdb, the ldap is mirror mode > > sync with 2 nodes and it is compiled version not a rpm one. > > Assuming it was built with back-mdb support, yes. I have no idea what > release you're running, but you'll want a current one. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Re: Is there any easy way to decode openldap logs
by chandan jain 04 Mar '21

04 Mar '21

Thanks quanah, I will change log level to 256 to see the results. Also, is it possible to migrate from bdb to mdb, the ldap is mirror mode sync with 2 nodes and it is compiled version not a rpm one. Regards Chandan On Thu, Mar 4, 2021, 21:49 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Thursday, March 4, 2021 12:00 PM +0530 chandan jain > <chandandevops(a)gmail.com> wrote: > > > > > Hi Techies, > > > > > > I am new to openLDAP, i am reading its log file. Is their any easy way to > > decode the logs to identify what is going on? > > I would suggest simply setting a loglevel of "stats". You're currently > going to suffer from information overload. > > I'd also note that the BDB backend is deprecated and is generally not > recommended for use. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Is there any easy way to decode openldap logs
by chandan jain 04 Mar '21

04 Mar '21

Hi Techies, I am new to openLDAP, i am reading its log file. Is their any easy way to decode the logs to identify what is going on? Please see below logs: Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on: Mar 3 03:22:01 myserver OpenLDAP[53304]: Mar 3 03:22:01 myserver OpenLDAP[53304]: slap_listener_activate(7): Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7 busy Mar 3 03:22:01 myserver OpenLDAP[53304]: >>> slap_listener(ldap:// 0.0.0.0:389) Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: listen=7, new connection on 19 Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on: Mar 3 03:22:01 myserver OpenLDAP[53304]: Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: added 19r (active) listener=(nil) Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 fd=19 ACCEPT from IP= 10.101.21.156:60358 (IP=0.0.0.0:389) Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 2 descriptors Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on: Mar 3 03:22:01 myserver OpenLDAP[53304]: 19r Mar 3 03:22:01 myserver OpenLDAP[53304]: Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: read active on 19 Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_get(19) Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_get(19): got connid=103380 Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_read(19): checking for input on id=103380 Mar 3 03:22:01 myserver OpenLDAP[53304]: op tag 0x60, time 1614759721 Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=0 do_bind Mar 3 03:22:01 myserver OpenLDAP[53304]: >>> dnPrettyNormal: <cn=Manager,dc=icma-web,dc=com> Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on: Mar 3 03:22:01 myserver OpenLDAP[53304]: <<< dnPrettyNormal: <cn=Manager,dc=icma-web,dc=com>, <cn=manager,dc=icma-web,dc=com> Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=0 BIND dn="cn=Manager,dc=icma-web,dc=com" method=128 Mar 3 03:22:01 myserver OpenLDAP[53304]: do_bind: version=3 dn="cn=Manager,dc=icma-web,dc=com" method=128 Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 3 03:22:01 myserver OpenLDAP[53304]: ==> bdb_bind: dn: cn=Manager,dc=icma-web,dc=com Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=0 BIND dn="cn=Manager,dc=icma-web,dc=com" mech=SIMPLE ssf=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: do_bind: v3 bind: "cn=Manager,dc=icma-web,dc=com" to "cn=Manager,dc=icma-web,dc=com" Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_result: conn=103380 op=0 p=3 Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_result: err=0 matched="" text="" Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_response: msgid=1 tag=97 err=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=0 RESULT tag=97 err=0 text= Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on: Mar 3 03:22:01 myserver OpenLDAP[53304]: 19r Mar 3 03:22:01 myserver OpenLDAP[53304]: Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: read active on 19 Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_get(19) Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_get(19): got connid=103380 Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_read(19): checking for input on id=103380 Mar 3 03:22:01 myserver OpenLDAP[53304]: op tag 0x63, time 1614759721 Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=1 do_search Mar 3 03:22:01 myserver OpenLDAP[53304]: >>> dnPrettyNormal: <dc=icma-web,dc=com> Mar 3 03:22:01 myserver OpenLDAP[53304]: <<< dnPrettyNormal: <dc=icma-web,dc=com>, <dc=icma-web,dc=com> Mar 3 03:22:01 myserver OpenLDAP[53304]: SRCH "dc=icma-web,dc=com" 2 0 Mar 3 03:22:01 myserver OpenLDAP[53304]: 0 0 0 Mar 3 03:22:01 myserver OpenLDAP[53304]: begin get_filter Mar 3 03:22:01 myserver OpenLDAP[53304]: EQUALITY Mar 3 03:22:01 myserver OpenLDAP[53304]: end get_filter 0 Mar 3 03:22:01 myserver OpenLDAP[53304]: filter: (uid=icma_emp_1emp113) Mar 3 03:22:01 myserver OpenLDAP[53304]: attrs: Mar 3 03:22:01 myserver OpenLDAP[53304]: Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=1 SRCH base="dc=icma-web,dc=com" scope=2 deref=0 filter="(uid=icma_emp_1emp113)" Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_search Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_dn2entry("dc=icma-web,dc=com") Mar 3 03:22:01 myserver OpenLDAP[53304]: => access_allowed: search access to "dc=icma-web,dc=com" "entry" requested Mar 3 03:22:01 myserver OpenLDAP[53304]: <= root access granted Mar 3 03:22:01 myserver OpenLDAP[53304]: => access_allowed: search access granted by manage(=mwrscxd) Mar 3 03:22:01 myserver OpenLDAP[53304]: search_candidates: base="dc=icma-web,dc=com" (0x00000001) scope=2 Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_dn2idl("dc=icma-web,dc=com") Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_filter_candidates Mar 3 03:22:01 myserver OpenLDAP[53304]: #011AND Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_list_candidates 0xa0 Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_filter_candidates Mar 3 03:22:01 myserver OpenLDAP[53304]: #011OR Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_list_candidates 0xa1 Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_filter_candidates Mar 3 03:22:01 myserver OpenLDAP[53304]: #011EQUALITY Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_equality_candidates (objectClass) Mar 3 03:22:01 myserver OpenLDAP[53304]: => key_read Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_idl_fetch_key: [b49d1940] Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_index_read: failed (-30988) Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_equality_candidates: id=0, first=0, last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_filter_candidates: id=0 first=0 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_filter_candidates Mar 3 03:22:01 myserver OpenLDAP[53304]: #011EQUALITY Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_equality_candidates (uid) Mar 3 03:22:01 myserver OpenLDAP[53304]: => key_read Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_idl_fetch_key: [9a14f458] Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_index_read: failed (-30988) Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_equality_candidates: id=0, first=0, last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_filter_candidates: id=0 first=0 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_list_candidates: id=0 first=0 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_filter_candidates: id=0 first=0 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_list_candidates: id=0 first=1 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_filter_candidates: id=0 first=1 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_search_candidates: id=0 first=1 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_search: no candidates Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_result: conn=103380 op=1 p=3 Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_result: err=0 matched="" text="" Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_response: msgid=2 tag=101 err=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on:

2 1

openldap client library connection caching?
by Rallavagu Kon 04 Mar '21

04 Mar '21

All, Deployed OpenLDAP 2.4 in production (with replication) mainly serving saslauthd and sendmail on Linux with client library 2.4.49. We are experiencing sporadic errors "ldap_simple_bind() failed -1 (Can't contact LDAP server).”. This issue happens on both saslauthd and on openldap when replicating to other service. However, upon investigation we have found that this error is not disruptive as both services (saslauthd and openldap server) have “retry” options built-in and subsequent request (immediately after a failure) receives successful response. Also, noticed that this issue manifests when communication occurs via ELB (AWS) and no connect issues were manifested when clients are directly pointed to openldap server (all connections are TLS). This makes me infer (suspect) that openldap client library might be caching (or tcp alive etc.) the connection which is not working well with ELB (Elastic Load Balancer). Wondering if the connection is really cached and is there a configuration parameter that I can try and tune the behavior (tried to chase this down looking into the source code of client library but could not locate it, perhaps I need to look more but wondering if someone else in the community has any experience in this regard). Thank You.

3 3

difference in multi-master replication since 2.4.57
by Emmanuel Seyman 04 Mar '21

04 Mar '21

Hello, all. I have two OpenLDAP servers in production that were running 2.4.44 . Both of these servers host 5 directories, each with their own backends. This is a bog-standard 2-node RHEL7 multi-master configuration that has worked for years. The binaries are the LTB-Project rpms. I updated my OpenLDAP servers to 2.4.57 last week. A few minutes after the upgrade, I started to see syncrepl alerts in Nagios and I'm having a hard time convincing myself that the upgrade isn't responsible for the errors. The problem is that I don't see any messages in the log that stand out as being errors (granted, I'm not sure what I'm looking for). In fact, the alert flaps every once in a while as the two nodes come back in sync and drift away from each other again. Here's what the output of the syncrepl nagios plugin looks like: 2021-03-03 09:54:01: CRITICAL - directories are not in sync - 199 seconds late (W:10 - C:5) 2021-03-03 09:56:01: CRITICAL - directories are not in sync - 197 seconds late (W:10 - C:5) 2021-03-03 09:58:01: CRITICAL - directories are not in sync - 42 seconds late (W:10 - C:5) 2021-03-03 10:00:01: CRITICAL - directories are not in sync - 4200 seconds late (W:10 - C:5) 2021-03-03 10:02:01: CRITICAL - directories are not in sync - 81 seconds late (W:10 - C:5) 2021-03-03 10:04:01: CRITICAL - directories are not in sync - 201 seconds late (W:10 - C:5) 2021-03-03 10:06:01: CRITICAL - directories are not in sync - 196 seconds late (W:10 - C:5) 2021-03-03 10:08:01: CRITICAL - directories are not in sync - 42 seconds late (W:10 - C:5) 2021-03-03 10:10:01: CRITICAL - directories are not in sync - 200 seconds late (W:10 - C:5) 2021-03-03 10:12:01: CRITICAL - directories are not in sync - 81 seconds late (W:10 - C:5) I find these values surprising considering I've never seen a syncrepl error in the 2 years before the upgrade. Is there a known issue with replication in 2.4.57 that would explain these sync differences? Regards, Emmanuel

4 5

Issue on backup on Open LDAP 2.4.38
by pascal.foulon＠orange.com 03 Mar '21

03 Mar '21

Hi all Since several weeks , we met an issue on our test and UA Open LDAP main master servers version 2.4.38 hosted on Linux Red Hat 6.4 : slapd: [INFO] Using /etc/default/slapd for configuration slapd: [INFO] Launching OpenLDAP database backup... slapd: [OK] data saved in /var/opt/data/flat/openldap/backups/data-20210303154336.ldif 603fa0ac bdb(cn=changelog): Logging region out of memory; you may need to increase its size 603fa0ac hdb_db_open: database "cn=changelog": db_open(/var/opt/data/db/openldap/changelog/id2entry.bdb) failed: Cannot allocate memory (12). 603fa0ac backend_startup_one (type=hdb, suffix="cn=changelog"): bi_db_open failed! (12) slap_startup failed slapd: [ALERT] OpenLDAP database backup failed Once a week, this servers is completely updated using a backup sent from our production server On the backup master server, backup process runs well. Any idea to fix this issue ? Regards [logo Orange]<http://www.orange.com/> Pascal Foulon Concepteur Développeur Responsable Technique / MOE portail Intranet France Mobile Expert technique VMPAL-E / Quartz / Web Admin / IFM / Annuaire Groupe Orange/TGI/OLS/SOFT/IDF-NANCY/DPI mobile : +33 6 82 57 28 73 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.…> pascal.foulon(a)orange.com<mailto:pascal.foulon@orange.com> EDS Océane 58H « Annuaire Groupe » : BJC031 EDS Océane IFM « Intranet France Mobile » : BJC038 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

2 1

openldap meta to active directory bind err=49 most explicit return information ?
by Nicolas Renault 01 Mar '21

01 Mar '21

Hi, I have a meta that proxify bind requests to 3 AD. A CAS server use the meta backend to authenticate users. if I connect into the cas ui with a user and good password , all is fine. if I connect into the cas ui with the same user and a bad password , it's fail , all is fine if I connect into the cas ui with a another user (password expired on the AD) using the good expired password, it's fail , all is fine But I want to have a information windows that says : "bad password " or "password expired" , I cannot because return code is always ' RESULT tag=97 err=49 text= ' Did someone knows a way to get the information ? ( same question with "locked account" and all the existing case ) Regards Nicolas

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2021