openldap-technical February 2024

openldap-technical@openldap.org

20 participants
21 discussions

olcLimits and groupOfURLs dynlist
by Norman Gray 12 Feb '24

12 Feb '24

Greetings. I have another puzzle with my OpenLDAP configuration, where I'm not sure if what I'm seeing is unexpected. Short version: should I expect a group in an olcLimits spec to work when the group is dynamic? I have a dynamic group set up, using the dynlist overlay, which expands to a set of DNs which should be allowed slightly privileged access to a directory. That group seems to be working OK: % ldapsearch -x -H ldap://localhost:8389 -b o=example -LLL '(cn=ldap-operators)' dn: cn=ldap-operators,ou=groups,o=example cn: ldap-operators objectClass: groupOfURLs description: Members of all of the LDAP admin and tech groups memberURL: ldap:///ou=groups,o=example?member?sub?(|(cn=ldap-admins-*)(cn=ldap-techs)) member: uid=norman,ou=staff,o=example [...] One goal here is to remove query limits for this group. I can test that by adding an artificially low limit: olcLimits: group/groupOfURLs/member="cn=ldap-operators,ou=groups,o=example" size=2 If I then make a query which has a few results, I do not get this limit imposed, and instead see in the logs 65c3ce83.0f52bea8 0x16e9d3000 => mdb_entry_get: found entry: "cn=ldap-operators,ou=groups,o=example" 65c3ce83.0f533f90 0x16e9d3000 <= mdb_entry_get: failed to find attribute member (If, instead of this, I define an ldap-operators group of class groupOfNames, with the above 'member' included explicitly, and make the corresponding change to the olcLimits line, I get what I expect -- ie, a restricted-size response to the query -- which reassures me I'm not doing something stupid elsewhere.) The slapo-dynlist(5) page says: > Any time an entry with a specific objectClass is being returned, the > LDAP URI-valued occurrences of a specific attribute are expanded into > the corresponding entries, and the values of the attributes listed in > the URI are added to the original entry. I note the ‘any time’. My configuration appears to be working for the ldapsearch lookup; I don't see any text in that manpage that suggests this won't work for the (somehow internal?) lookup being done when processing the olcLimits expression. The page slapd-config(5) says, under olcLimits: > The term group, with the optional objectClass oc and attributeType at > fields, followed by pattern, sets the limits for any DN listed in the > values of the at attribute (default member) of the oc group > objectClass (default groupOfNames) whose DN exactly matches pattern. That text doesn't seem to me to exclude this entry lookup from the ‘any time’ in the slapo-dynlist text above. This is OpenLDAP 2.6.7. I am of course open to a frame-challenge about the best way of achieving the underlying goal. Best wishes, Norman -- Norman Gray : https://nxg.me.uk

2 9

Openldap 2.4 -> Openldap 2.6.3 replication hurdles
by Viktor Keremedchiev 08 Feb '24

08 Feb '24

Hello, I'm somewhat not experienced with LDAP on the server side of things I’m importing openldap 2.4. into 2.6.3. (rockylinux 9). My goal is to 2 have 2 N-way (or multi-master*) ldap nodes. I’ve changed hdb to mdb, created accesslog folder, fixed permissions, SSL etc The import doesn’t throw any errors. My understanding is that I need to have cn=config replication, as well as my small dc=domain,dc=com, replication as well The cn=config replication I call via this on both nodes followed by restarts dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=002 provider=ldaps://prod-ldap2.domain.com:636 bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=N… searchbase="cn=config" schemachecking=on type=refreshAndPersist retry="10 10 60 +" tls_reqcert=allow keepalive=240:10:30 olcSyncRepl: rid=001 provider=ldaps://prod-ldap1.domain.com:636 bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=N…… searchbase="cn=config" schemachecking=on type=refreshAndPersist retry="10 10 60 +" tls_reqcert=allow keepalive=240:10:30 - add: olcMirrorMode olcMirrorMode: TRUE Now once I do that I’ve experimented with changing the olcLogLevel and it seems to work. The rid’s on each node are different server2 has rid=002, server 1 has rid=001 as well as different olcServerID The part I run into issues is when I enable replication to the dc=domain,dc=com via dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {2}syncprov olcSpCheckpoint: 20 10 olcSpSessionlog: 10000000 dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=021 provider=ldaps://prod-ldap1.domain.com:636 bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=N…. searchbase="dc=domain,dc=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="5 10 60 +" tls_reqcert=allow keepalive=240:10:30 olcSyncRepl: rid=022 provider=ldaps://prod-ldap2.domain.com:636 bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=N…. searchbase="dc=domain,dc=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="5 10 60 +" tls_reqcert=allow keepalive=240:10:30 - add: olcMirrorMode olcMirrorMode: TRUE I have 2 sets rids 001/002 and 021/022 and I have olcMirrorMode set to true on both cn=config and domain replication I’m pasting the relevant code around accesslog and syncprov that I think I’m getting wrong dn: olcOverlay={3}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {3}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig dn: olcOverlay={4}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {4}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=adaptavist,dc=com olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart structuralObjectClass: olcMdbConfig dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig Replication works from node1 to node2, and in reverse. But it stops after 20 minutes or so After replication stops I see the on accesslog on one node has 4 records, on the other it has 3 and it never catches up even if I restart although at first it all works regardless of which node I update (change a random password) What am I doing wrong? Perhaps more than one thing Thank you

3 5

Re: LastBind feature
by Abdelkader Chelouah 08 Feb '24

08 Feb '24

The attribute *olcLastBindPrecisio**n* is not available for OpenLDAP 2.5, *pwdLastSuccess* is updated whenever a BIND operation is successful. Regards On 2/8/24 14:57, Jean-Luc Bourguignon wrote: > Hello, > > Thx for your answer. > > I did not pay attention it was for 2.6x but why it’s working in 2.5.16 as I’ve the new attribut and it’s updated as I wanted, only the precision is not set !! There should be a default value or it’s at each login by default?? > > I was using the old overlay in 2.5.7 but I decided to move from it to source one during upgrade to 2.5.16 as attributes aren’t the same and on my production systems it was not enabled yet then it will be ready to move to 2.6x without having to do actions on old attribut to new one. > > Brgds, > J-L. > > > >> On 8 Feb 2024, at 14:44, Abdelkader Chelouah<a.chelouah(a)gmail.com> wrote: >> >> On 2/8/24 14:39,bourguijl@gmail.com wrote: >>> Dears, >>> >>> I'm running openldap 2.5.16 in which I'm using lastbind feature included in source. >>> To enable it, I read that 2 attributs should be inserted in DB config file side, in which I added : >>> >>> olcLastBind: TRUE >>> olcLastBindPrecision: 3600 >>> >>> But it seems that olcLastBindPrecision isn't supported because when I did a slapcat of the configuration of the ldap instance in which both are added, I get following error message : >>> >>> UNKNOWN attributeDescription "OLCLASTBINDPRECISION" inserted. >>> >>> I removed it from my configuration and restarted the slapd then I discovered that attribut "pwdLastSuccess" is well updated but I don't know with which precision (default ??). >>> >>> So, my question is why this parameter isn't supported ? Is there something else to enable ? >>> >>> Thx in advance, >>> Jean-Luc. >> Hello, >> >> >> It is only supported starting from OpenLDAP 2.6. If you want to used this attribute with OpenLDAP 2.5, you have to switch to lastbind overlay. >> >> >> Regards >>

1 0

LastBind feature
by bourguijl＠gmail.com 08 Feb '24

08 Feb '24

Dears, I'm running openldap 2.5.16 in which I'm using lastbind feature included in source. To enable it, I read that 2 attributs should be inserted in DB config file side, in which I added : olcLastBind: TRUE olcLastBindPrecision: 3600 But it seems that olcLastBindPrecision isn't supported because when I did a slapcat of the configuration of the ldap instance in which both are added, I get following error message : UNKNOWN attributeDescription "OLCLASTBINDPRECISION" inserted. I removed it from my configuration and restarted the slapd then I discovered that attribut "pwdLastSuccess" is well updated but I don't know with which precision (default ??). So, my question is why this parameter isn't supported ? Is there something else to enable ? Thx in advance, Jean-Luc.

2 1

openldap.log file location on Windows environment
by mbalakri＠opentext.com 08 Feb '24

08 Feb '24

Could anyone assist in locating the openldap.log file within a Windows environment? In OpenLDAP version 2.4.58, the log file resided in the same directory as slapd.exe. However, following the upgrade to OpenLDAP 2.5.13, we no longer receive log messages in the openldap.log file. Has the log file's location changed in the recent version? Is there an option available to configure the log file location?

1 1

Upgrade from 2.4.x to 2.6.x
by Sajesh Singh 07 Feb '24

07 Feb '24

Good day OpenLDAP folks. I am looking to upgrade our current OpenLDAP to the latest 2.6 release from my current install of 2.4.44. I am wondering if: 1) Is it possible to have one master running 2.4.44 and another running the latest 2.6 replicating to each other? 2) Is replication possible between hosts that have a mixture of: a) slapd.conf & cn=config b) hdb and mdb Thank you, Saj

2 2

Accesslog requirement for sync replication
by Marc Franquesa 05 Feb '24

05 Feb '24

Hi I have been using replication since long time without any issues (and still without issues), but on recent versions I got this warning on the logs: syncprov_setup_accesslog: couldn't get definition for attribute reqType, is accesslog configured? The answer is no, I never configured accesslog (this why I'm a bit confused, as I never used/needed on my replication setup). After reviewing the documentation I understand that for syncrepl I should load and configure accesslog overlay. Although I have some questions/concerns I haven't been able to found/understand from the documentation and would like someone clarifies: * Is there any way to implement replication without accesslog? (currently I have it but I would like to not get that warning) * If I setup accesslog, do I need to setup a different accesslog DIT for each target DIT I replicate? Or can a single accesslog be shared with 2 different target DITs? I mean: I'm currently replicating both cn=config (dynamic configuration) and the main DIT (so 2 different contexts/DITs/trees) Do I need to use a different accesslog DIT for each one or can they share the same DIT as accesslog ? * Does this log DIT needs to be backup up or is simply a log which I could get rid of in case of recovery? Any comments, hints or simply answers are welcome Thanks

2 3

LMDB cursor position
by M Gurschi 03 Feb '24

03 Feb '24

Hello team, Can you please let me know, when using *mdb_cursor_get* with *MDB_SET* operation, in case the key is not present in the db, where is the cursor left pointing? My scenario is that i want to retrieve two adjacent keys. 1. first *mdb_cursor_get* with *MDB_SET* 2. after that, *mdb_cursor_get* with *MDB_NEXT* I'm wondering what can i expect the cursor to point at in case the key is not found in step 1. Kind Regards, Maxim Gurschi

2 7

otp vs totp
by Quanah Gibson-Mount 02 Feb '24

02 Feb '24

--On Thursday, February 1, 2024 10:55 AM +0100 Bastian Tweddell <b.tweddell(a)fz-juelich.de> wrote: > The reason was, that we use it as a TOTP-only solution. > I had a testsetup with slapo-otp as well, but this module required > userPassword + TOTP, IIRC; where we cannot not have userPassword. > > Our setup is to use TOTP as 2FA for ssh logins against the centralized > LDAP infrstructure. The ssh-login 1FA is ssh pubkey (also in LDAP) and > 2FA is TOTP. To achieve this we use a PAM module which does an ldapbind > against the user-DN which has the userPassword schema '{TOTP1}'. > > Maybe I wrong or outdated here and slapo-opt also supports TOTP-only > authentication now? After discussion in today's project team meeting, we've opened an issue to have this supported by slapo-otp in the future: <https://bugs.openldap.org/show_bug.cgi?id=10169> If you follow that bug, once a solution is in, we'd always welcome testing of it. :) Regards, Quanah

2 1

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical February 2024