openldap-technical December 2023

openldap-technical@openldap.org

17 participants
14 discussions

olcPPolicyForwardUpdates not working
by Benjamin Renard 18 Jun '25

18 Jun '25

Hello, I have problem with the olcPPolicyForwardUpdates option that seem not working : On master and slave, I configured Ppolicy with pwdLockout. When I try to connect on master with a bad password, the pwdFailureTime attribute of the entry is successfully updated, but not if I do the same on the slave. On slave, my ppolicy configuration is exactly the same as on master but I add olcPPolicyForwardUpdates=TRUE. I also configured the chain overlay and the updateref parameter on the database. Extract of my slave configuration : olcDatabase={1}mdb,cn=config [...] olcSyncrepl: [...] olcUpdateRef: ldaps://ldap-master olcOverlay={0}chain,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig objectClass: top olcOverlay: {0}chain olcChainReturnError: TRUE olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}mdb,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase objectClass: top olcDatabase: {0}ldap olcDbURI: ldaps://ldap-master olcDbIDAssertBind: bindmethod=simple binddn="[same user used in olcSyncrepl of the database]" credentials="secret" mode=self olcDbRebindAsUser: TRUE olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig objectClass: top olcOverlay: {1}ppolicy olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: TRUE olcPPolicyForwardUpdates: TRUE Do you have any idea of what I doing wrong ? Thanks, -- Benjamin Renard - Easter-eggs 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - mailto:brenard@easter-eggs.com

3 20

openldap TLSv1.0 is enabled
by Andre Rodier 16 May '25

16 May '25

Hello, I have configured OpenLDAP using SSL certificate, but I have a few issues. Here the TLS configuration, especially "olcTLSProtocolMin: 3.3" > # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. > # CRC32 c70363a6 > dn: cn=config > objectClass: olcGlobal > cn: config > olcArgsFile: /var/run/slapd/slapd.args > olcLogLevel: none > olcPidFile: /var/run/slapd/slapd.pid > olcToolThreads: 1 > structuralObjectClass: olcGlobal > entryUUID: 40ee991a-0efe-103d-855a-11ff3a5638b4 > creatorsName: cn=config > createTimestamp: 20221213065102Z > olcPasswordCryptSaltFormat: $6$%.16s > olcTLSCACertificateFile: /etc/ldap/certs/ldap.homebox.world.issuer.crt > olcTLSCertificateKeyFile: /etc/ldap/certs/ldap.homebox.world.key > olcTLSCertificateFile: /etc/ldap/certs/ldap.homebox.world.crt > olcTLSProtocolMin: 3.3 > entryCSN: 20221214054517.926245Z#000000#000#000000 > modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > modifyTimestamp: 20221214054517Z But if I try sslscan: I see TLSv1.0, TLSv1.1 and TLSv1.2 enabled. Why ? > root@main:/etc/ldap/changes# sslscan ldap.homebox.world:636 > Version: 2.0.7 > OpenSSL 1.1.1n 15 Mar 2022 > > Connected to 2001:19f0:7402:86e:5400:4ff:fe38:b9b4 > > Testing SSL server ldap.homebox.world on port 636 using SNI name ldap.homebox.world > > SSL/TLS Protocols: > SSLv2 disabled > SSLv3 disabled > TLSv1.0 enabled > TLSv1.1 enabled > TLSv1.2 enabled > TLSv1.3 enabled > > TLS Fallback SCSV: > Server supports TLS Fallback SCSV > > TLS renegotiation: > Secure session renegotiation supported > > TLS Compression: > OpenSSL version does not support compression > Rebuild with zlib1g-dev package for zlib support > > Heartbleed: > TLSv1.3 not vulnerable to heartbleed > TLSv1.2 not vulnerable to heartbleed > TLSv1.1 not vulnerable to heartbleed > TLSv1.0 not vulnerable to heartbleed > > Supported Server Cipher(s): > Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253 > Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253 > Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253 > Accepted TLSv1.3 128 bits TLS_AES_128_CCM_SHA256 Curve 25519 DHE 253 > Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve 25519 DHE 253 > Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits AES256-GCM-SHA384 > Accepted TLSv1.2 256 bits AES256-CCM > Accepted TLSv1.2 128 bits AES128-GCM-SHA256 > Accepted TLSv1.2 128 bits AES128-CCM > Accepted TLSv1.2 256 bits AES256-SHA > Accepted TLSv1.2 128 bits AES128-SHA > Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.1 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.1 256 bits AES256-SHA > Accepted TLSv1.1 128 bits AES128-SHA > Preferred TLSv1.0 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.0 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.0 256 bits AES256-SHA > Accepted TLSv1.0 128 bits AES128-SHA > > Server Key Exchange Group(s): > TLSv1.3 128 bits secp256r1 (NIST P-256) > TLSv1.3 192 bits secp384r1 (NIST P-384) > TLSv1.3 260 bits secp521r1 (NIST P-521) > TLSv1.3 128 bits x25519 > TLSv1.3 224 bits x448 > TLSv1.3 112 bits ffdhe2048 > TLSv1.3 128 bits ffdhe3072 > TLSv1.3 150 bits ffdhe4096 > TLSv1.3 175 bits ffdhe6144 > TLSv1.3 192 bits ffdhe8192 > TLSv1.2 128 bits secp256r1 (NIST P-256) > TLSv1.2 192 bits secp384r1 (NIST P-384) > TLSv1.2 260 bits secp521r1 (NIST P-521) > TLSv1.2 128 bits x25519 > TLSv1.2 224 bits x448 > > SSL Certificate: > Signature Algorithm: sha256WithRSAEncryption > RSA Key Strength: 2048 > > Subject: ldap.homebox.world > Altnames: DNS:ldap.homebox.world > Issuer: (STAGING) Artificial Apricot R3 > > Not valid before: Dec 13 05:34:29 2022 GMT > Not valid after: Mar 13 05:34:28 2023 GMT Thanks for your insights. Andre

6 13

Re: Replication issue during performance test with MMR configuration and LastBind enabled
by Falgon 16 Oct '24

16 Oct '24

Hello, I'm working on the same project as Meheni. Thanks for your answer, we'll try version 2.6 OpenLDAP using the lastbind-precision. However we have several questions for the current version we're using. Is this a known problem and referenced somewhere? (we haven't found it) Is it normal to find no replication error logs even in stats + sync mode? We ran some tests in sequential mode (300,000 accounts one after the other) and managed to reproduce the problem. -Denis Le mer. 11 oct. 2023 à 14:11, Quanah Gibson-Mount <quanah(a)fast-mail.org> a écrit : > > > --On Tuesday, October 10, 2023 9:30 PM +0200 Ziani Meheni > <mehani06(a)gmail.com> wrote: > > > > > > > Hello, we are working on a project and we've come across a problem with > > the replication after performance testing : > > You need to use OpenLDAP 2.6 and then set the: > > lastbind-precision > > value. I use 5 minutes. > > --Quanah >

4 8

Plans for the next LTS release?
by Sergio Durigan Junior 01 Feb '24

01 Feb '24

Hi there, Two years ago I sent an announcement mentioning that the OpenLDAP 2.5.x series was accepted for a Micro Release Exception in Ubuntu Jammy (20.04). This meant that I'd be able to release any updates to the 2.5.x series on Jammy, which I have been doing since then. We are now getting ready to work on the next Ubuntu LTS release, which will come out next April. I seem to remember upstream discussions mentioning that the next OpenLDAP LTS release would likely be the 2.7.x series, but I don't remember seeing anything else about it. Are there any plans to start working on the OpenLDAP LTS major series? Thanks a lot, -- Sergio GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14

3 5

Scaling slapd nodes in Kubernetes with the MDB Backend
by Alejandro Imass 05 Jan '24

05 Jan '24

Hi there! We are working on a new installation and decided to try something new.. In the past I would have gone with multi-master with ldap balancer but after reading and researching more and more on MDB, we decided to try to integrate OpenLDAP into our current CI/CD pipelines using K8s. What we tried so far and it seems to work is initialize a common persistence storage and then an auto scaling group that shares that common drive. Ech pod has as many threads as virtual CPU it may have, and none of the pods can write, except a dedicated write pod (single instance) with multiple threads for writing. Is there anything else we are missing here? Any experience scaling OpenLDAP with Kubernetes or other container technology. Thank you in advance for any comments, pointers or recommendations! -- Alex

3 4

Enable multi master replication for OpenLDAP server running in standalone mode.
by Kaushal Shriyan 29 Dec '23

29 Dec '23

Hi, I am running OpenLdap server 2.4.59 on Red Hat Enterprise Linux release 8.8 (Ootpa) OS in standalone mode without any replication. # rpm -qa | grep openldap symas-openldap-servers-2.4.59-1.el8.x86_64 openldap-2.4.46-18.el8.x86_64 symas-openldap-2.4.59-1.el8.x86_64 symas-openldap-clients-2.4.59-1.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.8 (Ootpa) # Is there a way to enable multi master replication for OpenLDAP server, which is currently servicing clients in Production environment? Please guide me. Thanks in advance. Best Regards, Kaushal

2 2

Most efficient way to update multivalued attributes
by Frédéric Goudal 20 Dec '23

20 Dec '23

Hello, I have to update records with mutlivalued attributes, and I wonder what is the best (fastest, or lighter for the server) to do : - either just set the value with the new list - or calculate which values to add and which to delete and than do the add and remove operations. And to be a bit more precise, if we have a big number of values is one of the two way best ? Thanks in advance f.g. — Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11

2 2

Trying to get dynlist overlay to work
by Christoph Pleger 20 Dec '23

20 Dec '23

Hello, I am using OpenLDAP 2.5.13 from Debian and want to use the dynamic list overlay for replacing the memberOf overlay, but I cannot get it to work. As I read in several places, I first imported dyngroup.ldif, then created an ldif to load the dynlist module and the dynlist schema, like this: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: dynlist dn: olcOverlay=dynlist,olcDatabase={1}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {1}dynlist olcDlAttrSet: groupOfURLs memberURL member Then, I created a group with this ldif: dn: cn=Group1,ou=groups,dc=cs,dc=tu-dortmund,dc=de objectClass: groupOfURLs cn: Group1 memberURL: ldap:///dc=cs,dc=tu-dortmund,dc=de??sub?(employeeType=IT) But though some of the users have employeeType=IT, I cannot get a user attribute memberOf or alike that says that, for example ITuser1 is a member of Group1 . So, I tried another approach with dynlist that I read elsewhere: dn: olcOverlay=dynlist,olcDatabase={1}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {1}dynlist olcDlAttrSet: groupOfURLs memberURL member+memberOf@groupOfNames But with this, I got an error message that memberOf@groupOfNames is unknown. So, I have some questions: 1. Does dynlist work this way only in OpenLDAP 2.6? 2. If no, do I have to import additional overlay ldifs? 3. Do I have to load additional modules other than dynlist? 4. Do I have to set other overlay attributes for the dynlist overlay? Regards Christoph

2 6

SSL certificate install
by Jean-Luc Chandezon 15 Dec '23

15 Dec '23

Hello dear community, I'm trying to enable LDAPS. I don't understanrd what is cause error. Is anybody have an idea please? OpenLDAP is 2.5.13, on Debian 12. Here is our certificate chain definition: dn: cn=config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/LEXP_Infra_CA1.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/annuaire.lexp.fr.key - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/annuaire.lexp.fr.pem - Request is: root@bea-chicago:/etc# ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/01-SSL.ldif Result: SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) Here are slapd logs: cago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.094605+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.094773+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.094922+01:00 bea-chicago slapd[63531]: slap_listener_activate(10): 2023-12-13T08:30:42.095070+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.095216+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.095352+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 busy 2023-12-13T08:30:42.095489+01:00 bea-chicago slapd[63531]: >>> slap_listener(ldapi:///) 2023-12-13T08:30:42.095658+01:00 bea-chicago slapd[63531]: daemon: accept() = 12 2023-12-13T08:30:42.095790+01:00 bea-chicago slapd[63531]: daemon: listen=10, new connection on 12 2023-12-13T08:30:42.095927+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.096046+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.096165+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.096284+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.096424+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.096545+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 active_threads=0 tvp=zero 2023-12-13T08:30:42.096701+01:00 bea-chicago slapd[63531]: daemon: added 12r (active) listener=(nil) 2023-12-13T08:30:42.096832+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.096981+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.097099+01:00 bea-chicago slapd[63531]: 12r 2023-12-13T08:30:42.097227+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.097335+01:00 bea-chicago slapd[63531]: daemon: read active on 12 2023-12-13T08:30:42.097503+01:00 bea-chicago slapd[63531]: conn=1001 fd=12 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) 2023-12-13T08:30:42.097727+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.097845+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.098084+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 active_threads=0 tvp=zero 2023-12-13T08:30:42.098282+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.098501+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.098688+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.098848+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.099006+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.099205+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 active_threads=0 tvp=zero 2023-12-13T08:30:42.099396+01:00 bea-chicago slapd[63531]: connection_get(12) 2023-12-13T08:30:42.099620+01:00 bea-chicago slapd[63531]: connection_get(12): got connid=1001 2023-12-13T08:30:42.099824+01:00 bea-chicago slapd[63531]: connection_read(12): checking for input on id=1001 2023-12-13T08:30:42.100038+01:00 bea-chicago slapd[63531]: op tag 0x60, time 1702452642 2023-12-13T08:30:42.100268+01:00 bea-chicago slapd[63531]: conn=1001 op=0 do_bind 2023-12-13T08:30:42.100499+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.100687+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.100882+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.101076+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.101292+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.101503+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 active_threads=0 tvp=zero 2023-12-13T08:30:42.101781+01:00 bea-chicago slapd[63531]: >>> dnPrettyNormal: <> 2023-12-13T08:30:42.102002+01:00 bea-chicago slapd[63531]: <<< dnPrettyNormal: <>, <> 2023-12-13T08:30:42.102205+01:00 bea-chicago slapd[63531]: conn=1001 op=0 BIND dn="" method=163 2023-12-13T08:30:42.102431+01:00 bea-chicago slapd[63531]: do_bind: dn () SASL mech EXTERNAL 2023-12-13T08:30:42.102525+01:00 bea-chicago slapd[63531]: ==> sasl_bind: dn="" mech=EXTERNAL datalen=0 2023-12-13T08:30:42.102620+01:00 bea-chicago slapd[63531]: SASL Canonicalize [conn=1001]: authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 2023-12-13T08:30:42.102709+01:00 bea-chicago slapd[63531]: slap_sasl_getdn: conn 1001 id=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth [len=55] 2023-12-13T08:30:42.102817+01:00 bea-chicago slapd[63531]: ==>slap_sasl2dn: converting SASL name gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN 2023-12-13T08:30:42.102908+01:00 bea-chicago slapd[63531]: <==slap_sasl2dn: Converted SASL name to <nothing> 2023-12-13T08:30:42.103004+01:00 bea-chicago slapd[63531]: SASL Canonicalize [conn=1001]: slapAuthcDN="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 2023-12-13T08:30:42.103121+01:00 bea-chicago slapd[63531]: SASL proxy authorize [conn=1001]: authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 2023-12-13T08:30:42.103220+01:00 bea-chicago slapd[63531]: conn=1001 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 2023-12-13T08:30:42.103322+01:00 bea-chicago slapd[63531]: SASL Authorize [conn=1001]: proxy authorization allowed authzDN="" 2023-12-13T08:30:42.103421+01:00 bea-chicago slapd[63531]: send_ldap_sasl: err=0 len=-1 2023-12-13T08:30:42.103527+01:00 bea-chicago slapd[63531]: conn=1001 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL bind_ssf=0 ssf=71 2023-12-13T08:30:42.103619+01:00 bea-chicago slapd[63531]: do_bind: SASL/EXTERNAL bind: dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" bind_ssf=0 2023-12-13T08:30:42.103713+01:00 bea-chicago slapd[63531]: send_ldap_response: msgid=1 tag=97 err=0 2023-12-13T08:30:42.103804+01:00 bea-chicago slapd[63531]: conn=1001 op=0 RESULT tag=97 err=0 qtime=0.000061 etime=0.000517 text= 2023-12-13T08:30:42.103913+01:00 bea-chicago slapd[63531]: <== slap_sasl_bind: rc=0 2023-12-13T08:30:42.104010+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.104102+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.104185+01:00 bea-chicago slapd[63531]: 12r 2023-12-13T08:30:42.104268+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.104352+01:00 bea-chicago slapd[63531]: daemon: read active on 12 2023-12-13T08:30:42.104435+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.104518+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.104600+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 active_threads=0 tvp=zero 2023-12-13T08:30:42.104683+01:00 bea-chicago slapd[63531]: connection_get(12) 2023-12-13T08:30:42.104766+01:00 bea-chicago slapd[63531]: connection_get(12): got connid=1001 2023-12-13T08:30:42.104851+01:00 bea-chicago slapd[63531]: connection_read(12): checking for input on id=1001 2023-12-13T08:30:42.104941+01:00 bea-chicago slapd[63531]: op tag 0x66, time 1702452642 2023-12-13T08:30:42.105037+01:00 bea-chicago slapd[63531]: conn=1001 op=1 do_modify 2023-12-13T08:30:42.105129+01:00 bea-chicago slapd[63531]: conn=1001 op=1 do_modify: dn (cn=config) 2023-12-13T08:30:42.105223+01:00 bea-chicago slapd[63531]: >>> dnPrettyNormal: <cn=config> 2023-12-13T08:30:42.105316+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.105401+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.105486+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.105587+01:00 bea-chicago slapd[63531]: <<< dnPrettyNormal: <cn=config>, <cn=config> 2023-12-13T08:30:42.105675+01:00 bea-chicago slapd[63531]: conn=1001 op=1 modifications: 2023-12-13T08:30:42.105770+01:00 bea-chicago slapd[63531]: #011add: olcTLSCACertificateFile 2023-12-13T08:30:42.105862+01:00 bea-chicago slapd[63531]: #011#011one value, length 33 2023-12-13T08:30:42.105951+01:00 bea-chicago slapd[63531]: #011add: olcTLSCertificateKeyFile 2023-12-13T08:30:42.106034+01:00 bea-chicago slapd[63531]: #011#011one value, length 37 2023-12-13T08:30:42.106124+01:00 bea-chicago slapd[63531]: #011add: olcTLSCertificateFile 2023-12-13T08:30:42.106219+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.106303+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.106387+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 active_threads=0 tvp=zero 2023-12-13T08:30:42.106469+01:00 bea-chicago slapd[63531]: #011#011one value, length 35 2023-12-13T08:30:42.106557+01:00 bea-chicago slapd[63531]: conn=1001 op=1 MOD dn="cn=config" 2023-12-13T08:30:42.106644+01:00 bea-chicago slapd[63531]: conn=1001 op=1 MOD attr=olcTLSCACertificateFile olcTLSCertificateKeyFile olcTLSCertificateFile 2023-12-13T08:30:42.106737+01:00 bea-chicago slapd[63531]: => access_allowed: result not in cache (olcTLSCACertificateFile) 2023-12-13T08:30:42.106823+01:00 bea-chicago slapd[63531]: => access_allowed: add access to "cn=config" "olcTLSCACertificateFile" requested 2023-12-13T08:30:42.106918+01:00 bea-chicago slapd[63531]: => acl_get: [1] attr olcTLSCACertificateFile 2023-12-13T08:30:42.107007+01:00 bea-chicago slapd[63531]: => acl_mask: access to entry "cn=config", attr "olcTLSCACertificateFile" requested 2023-12-13T08:30:42.107095+01:00 bea-chicago slapd[63531]: => acl_mask: to value by "gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth", (=0) 2023-12-13T08:30:42.107182+01:00 bea-chicago slapd[63531]: <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth 2023-12-13T08:30:42.107283+01:00 bea-chicago slapd[63531]: <= acl_mask: [1] applying manage(=mwrscxd) (stop) 2023-12-13T08:30:42.107374+01:00 bea-chicago slapd[63531]: <= acl_mask: [1] mask: manage(=mwrscxd) 2023-12-13T08:30:42.107457+01:00 bea-chicago slapd[63531]: => slap_access_allowed: add access granted by manage(=mwrscxd) 2023-12-13T08:30:42.107543+01:00 bea-chicago slapd[63531]: => access_allowed: add access granted by manage(=mwrscxd) 2023-12-13T08:30:42.107636+01:00 bea-chicago slapd[63531]: => access_allowed: result not in cache (olcTLSCertificateKeyFile) 2023-12-13T08:30:42.107724+01:00 bea-chicago slapd[63531]: => access_allowed: add access to "cn=config" "olcTLSCertificateKeyFile" requested 2023-12-13T08:30:42.107812+01:00 bea-chicago slapd[63531]: => acl_get: [1] attr olcTLSCertificateKeyFile 2023-12-13T08:30:42.107898+01:00 bea-chicago slapd[63531]: => acl_mask: access to entry "cn=config", attr "olcTLSCertificateKeyFile" requested 2023-12-13T08:30:42.107992+01:00 bea-chicago slapd[63531]: => acl_mask: to value by "gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth", (=0) 2023-12-13T08:30:42.108074+01:00 bea-chicago slapd[63531]: <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth 2023-12-13T08:30:42.108157+01:00 bea-chicago slapd[63531]: <= acl_mask: [1] applying manage(=mwrscxd) (stop) 2023-12-13T08:30:42.108240+01:00 bea-chicago slapd[63531]: <= acl_mask: [1] mask: manage(=mwrscxd) 2023-12-13T08:30:42.108323+01:00 bea-chicago slapd[63531]: => slap_access_allowed: add access granted by manage(=mwrscxd) 2023-12-13T08:30:42.108398+01:00 bea-chicago slapd[63531]: => access_allowed: add access granted by manage(=mwrscxd) 2023-12-13T08:30:42.108494+01:00 bea-chicago slapd[63531]: => access_allowed: result not in cache (olcTLSCertificateFile) 2023-12-13T08:30:42.108589+01:00 bea-chicago slapd[63531]: => access_allowed: add access to "cn=config" "olcTLSCertificateFile" requested 2023-12-13T08:30:42.108678+01:00 bea-chicago slapd[63531]: => acl_get: [1] attr olcTLSCertificateFile 2023-12-13T08:30:42.108762+01:00 bea-chicago slapd[63531]: => acl_mask: access to entry "cn=config", attr "olcTLSCertificateFile" requested 2023-12-13T08:30:42.108852+01:00 bea-chicago slapd[63531]: => acl_mask: to value by "gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth", (=0) 2023-12-13T08:30:42.108936+01:00 bea-chicago slapd[63531]: <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth 2023-12-13T08:30:42.109014+01:00 bea-chicago slapd[63531]: <= acl_mask: [1] applying manage(=mwrscxd) (stop) 2023-12-13T08:30:42.109090+01:00 bea-chicago slapd[63531]: <= acl_mask: [1] mask: manage(=mwrscxd) 2023-12-13T08:30:42.109172+01:00 bea-chicago slapd[63531]: => slap_access_allowed: add access granted by manage(=mwrscxd) 2023-12-13T08:30:42.109253+01:00 bea-chicago slapd[63531]: => access_allowed: add access granted by manage(=mwrscxd) 2023-12-13T08:30:42.109337+01:00 bea-chicago slapd[63531]: slap_get_csn: conn=1001 op=1 generated new csn=20231213073042.095886Z#000000#000#000000 manage=1 2023-12-13T08:30:42.109424+01:00 bea-chicago slapd[63531]: slap_queue_csn: queueing 0x7f57dc000ce0 20231213073042.095886Z#000000#000#000000 2023-12-13T08:30:42.109535+01:00 bea-chicago slapd[63531]: oc_check_required entry (cn=config), objectClass "olcGlobal" 2023-12-13T08:30:42.109647+01:00 bea-chicago slapd[63531]: oc_check_allowed type "objectClass" 2023-12-13T08:30:42.109739+01:00 bea-chicago slapd[63531]: oc_check_allowed type "cn" 2023-12-13T08:30:42.109829+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcArgsFile" 2023-12-13T08:30:42.109917+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcLogLevel" 2023-12-13T08:30:42.110080+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcPidFile" 2023-12-13T08:30:42.110173+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcToolThreads" 2023-12-13T08:30:42.110266+01:00 bea-chicago slapd[63531]: oc_check_allowed type "structuralObjectClass" 2023-12-13T08:30:42.110367+01:00 bea-chicago slapd[63531]: oc_check_allowed type "entryUUID" 2023-12-13T08:30:42.110464+01:00 bea-chicago slapd[63531]: oc_check_allowed type "creatorsName" 2023-12-13T08:30:42.110541+01:00 bea-chicago slapd[63531]: oc_check_allowed type "createTimestamp" 2023-12-13T08:30:42.110617+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcTLSCACertificateFile" 2023-12-13T08:30:42.110707+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcTLSCertificateKeyFile" 2023-12-13T08:30:42.110793+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcTLSCertificateFile" 2023-12-13T08:30:42.110875+01:00 bea-chicago slapd[63531]: oc_check_allowed type "entryCSN" 2023-12-13T08:30:42.110972+01:00 bea-chicago slapd[63531]: oc_check_allowed type "modifiersName" 2023-12-13T08:30:42.111058+01:00 bea-chicago slapd[63531]: oc_check_allowed type "modifyTimestamp" 2023-12-13T08:30:42.111144+01:00 bea-chicago slapd[63531]: send_ldap_result: conn=1001 op=1 p=3 2023-12-13T08:30:42.111233+01:00 bea-chicago slapd[63531]: send_ldap_result: err=80 matched="" text="" 2023-12-13T08:30:42.111321+01:00 bea-chicago slapd[63531]: send_ldap_response: msgid=2 tag=103 err=80 2023-12-13T08:30:42.111407+01:00 bea-chicago slapd[63531]: conn=1001 op=1 RESULT tag=103 err=80 qtime=0.000070 etime=0.002380 text= 2023-12-13T08:30:42.111498+01:00 bea-chicago slapd[63531]: slap_graduate_commit_csn: removing 0x7f57dc000ce0 20231213073042.095886Z#000000#000#000000 2023-12-13T08:30:42.111590+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor Best regards, Jean-Luc

5 8

superuser and normal user in OpenLdap services
by Kaushal Shriyan 13 Dec '23

13 Dec '23

Hi, I am running the openldap server on Red Hat Enterprise Linux release 8.8 (Ootpa) # rpm -qa | grep -i ldap sssd-ldap-2.8.2-3.el8_8.x86_64 symas-openldap-servers-2.4.59-1.el8.x86_64 openldap-2.4.46-18.el8.x86_64 symas-openldap-2.4.59-1.el8.x86_64 symas-openldap-clients-2.4.59-1.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.8 (Ootpa) # Do we have root and normal user privileges in OpenLDAP service as similar to Linux OS? For example, if I have to reset cn=admin password, do we need to use root or something? I am a little confused. Are there superuser concept in OpenLDAP? Please guide me. Thanks in advance. Best Regards, Kaushal

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2023