openldap-technical June 2023

openldap-technical@openldap.org

30 participants
40 discussions

Multiple memberOf overlays
by John C. Pfeifer 05 Aug '25

05 Aug '25

I am in the process of converting an existing LDAP infrastructure to OpenLDAP. I have a case where it would be convenient for two different objectClasses to map into the memberOf attribute. Is it possible to define two overlay configs or will they end up fighting each other over the memberOf attribute? For instance: dn: olcOverlay={5}memberofA,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {5}memberofA olcMemberOfDangling: error olcMemberOfRefInt: FALSE olcMemberOfGroupOC: objectClassA olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf dn: olcOverlay={6}memberofB,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {6}memberofB olcMemberOfDangling: error olcMemberOfRefInt: FALSE olcMemberOfGroupOC: objectClassB olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf // John Pfeifer Division of Information Technology University of Maryland, College Park

4 3

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

Problem with "force user to password reset at first login
by Rajagopal Rc 30 Oct '23

30 Oct '23

Hi, I am trying to force users to change their password at first login or after password reset by administrator. Tried following: 1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non of the users get prompt to change their password at first login. 2) used the 'pwdReset TRUE' attribute in users attributes, and it won't prompt to change the password and didn't allow to login i observe below messages in log "slapd[12684]: connection restricted to password changing only slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password" Please help me configure the option to force all users to change their password at first login or after pwd reset by administrator. Thanks & Regards Raj Tata Consultancy Services Mailto: rajagopal.rc(a)tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

5 9

Re: [EXT] Re: Proposal to strengthen slapd EXTERNAL authentication
by Jordan Brown 30 Jun '23

30 Jun '23

On 6/29/2023 11:29 PM, Windl, Ulrich wrote: > I think there's something missing: When *creating* the certificate "It proves that the bearer owns the DN" (done by RA/CA), but when *using* the certificate (by a client) the server should still check whether the certificate matches the client. Otherwise any stolen certificate could be used to gain access from everywhere. MHO. When you say "matches the client", what do you mean? That the client's IP address maps to a name on the certificate? Remember that in DNS the mapping from IP address to name is under the control of the person who owns the IP address, not the person who owns the name. Remember also that the client may be behind a NAT that hides their IP address. Finally, remember that the client may legitimately change its IP address and DNS name (if any) from time to time as it is moved from one location to another (think phone, or laptop, or desktop moving from one office to another) or networks are reconfigured around it. This is asymmetric from the more common server authentication. For server authentication, the server has a stable name, and that name was supplied by the human and so can be trusted (more or less) and checked against the certificate. In fact, that human-supplied name serves exactly the same purpose as an "authorized DN" list: it says which certificates are acceptable. Net... you're absolutely right, if somebody steals your certificate - more precisely, your private key - they can use it to gain access. It is exactly as for a password: a username and password authenticates the user, but if somebody steals your password, they can masquerade as you. Depending on your particular scenario, it might be appropriate to have *additional* checks - acceptable networks, et cetera - or require multiple factors (e.g. certificate plus password). Those additional checks are not part of the certificate-based authentication process. Somebody stealing your private key may well be Game Over. Don't let people steal it. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

1 0

Re: What drives CPU usage spikes?
by David Hawes 30 Jun '23

30 Jun '23

On Fri, 23 Jun 2023 at 12:04, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > In our 2.6.4 deployment, we had a significant spike in CPU usage one day > last week that lasted approximately 2 hours (8 AM UTC to 10 AM UTC). > During this time, some clients started timing out when talking to the LDAP > service, and search response times spiked as well, up to 9.5 seconds on > searches that normally take < 3 seconds (they do have large result sets). > This happened on all 6 of the read nodes that we have in our load balance > pool, so whatever the issue was hit all of them at the same time. It did > not happen to 2 specialized read nodes that only serve one specific > service, so it was something about the traffic going to those 6 nodes. The > number of ops/second during that time frame was actually lower than usual > across the cluster, with a peak of 200 ops/second. We often have higher > peaks than that without this type of CPU usage spiking. I've noticed similar behavior on large accesslog purges. High CPU, poor response times, sometimes slapd even becomes unresponsive. Do these systems have an accesslog that gets purged?

3 3

SASL for OAuth
by Pascal Jakobi 30 Jun '23

30 Jun '23

Hi there I am reading at the moment RFC 7628 (SASL for OAuth). The idea is to extend usage of OAuth outside of the HTTP world. It has obviously been written with SMTP & IAMP in mind. It seems that it could be a very nice solution for authenticating web frontends accessing dir. servers (typically web based directory browsers). Correct if I am missing a point here, pls. As far as I understand, OL does not support it (again, feel free to correct). Are there any plans to look into it ? Best, P

2 1

RSfd in top, memory, etc.
by Sam Dave 29 Jun '23

29 Jun '23

While I write to an LMDB database, while it gets bigger and bigger, I can see %MEM in top rising steadily. This is because %MEM is composed of three things, including "RSfd". From the top manpage: RSfd -- Resident File-Backed Memory Size (KiB) A subset of resident memory (RES) representing the implicitly shared pages supporting program images and shared libraries. It also includes explicit file mappings, both private and shared. Is it memory mapping that's resulting in the higher RSfd? RSfd increases do not seem to have an effect on "buff/cache" or "avail Mem", i.e. what most people think as "RAM" is not being used up. I still want to ask, could too high RSfd use result in less efficient use of memory for other programs? I'm essentially wondering how efficient common OSes (e.g. MacOS, Linux) are in this area. - Sam

2 1

Proposal to strengthen slapd EXTERNAL authentication
by Sean Gallagher 28 Jun '23

28 Jun '23

I'd like to propose a new feature to substantially strengthen the existing access controls in slapd. This follows on from comments made in the discussion around Issue 10065. In particular Comment 17 and Comment 19. The objective here is to validate the credentials supplied by external security mechanisms BEFORE the main server loop starts, and terminate the connection if the client is not "known". It was noted that the olcAuthzRegexp configuration option already deals with externally supplied Authentication ID. My idea is to build on that. I propose a new flag for "olcDisallows" that is "unmatched_external_authid". Setting this flag would instruct slapd to drop the connection if the externally supplied authid did not match any of the olcAuthzRegexp rules. Currently the olcAuthzRegexp rules are only applied after a command arrives. My proposal does not change that, instead I propose that olcAuthzRegexp be evaluated at "connection time" as well as at "execution time". This would reduce the chance of any unexpected side effects. The only real issue I can think of is - is it possible for olcAuthzRegexp to match an AuthID without changing it. Is there any recursion in the application of these rules? Any thoughts? -- This email has been checked for viruses by AVG antivirus software. www.avg.com

3 5

Re: Proposal to strengthen slapd EXTERNAL authentication
by Howard Chu 28 Jun '23

28 Jun '23

Sean Gallagher wrote: > On 26/06/2023 7:40 pm, Howard Chu wrote: >> That feature is already available using TLSVerifyClient in the slapd config. > > Not really. Using the TLSVerifyClient mechanism could be made to work and would be a nice solution but it isn't there yet. To make this this work, you would > need to pass to libldap, some type of specification of the names of legitimate clients. Then in the tls_o.c:tlso_verify_cb() function, compare the name on the > client cert with the specification and return the pass/fail status back to the TLS layer. Then it would all "just work". > > The average user might be surprised to learn that TLSVerifyClient does not currently involve checking the client's name. You would intuitively think that was > pretty important. The point of a certificate-based authentication system is not to have to implement authentication rules for each and every individual user. An LDAP server should only trust certificates issued by a single CA; that CA should only be issuing certs to valid users. Ideally, the LDAP server should be the CA, which is what slapo-autoca is designed for. An LDAP server is not a web server or a client. There is no reason for it to trust certs from multiple CAs. > >> Pure nonsense. > > Pure hubris. > > It's sad when it takes a disaster to affect real change. Pure ignorance. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

6 12

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2023