openldap-technical

openldap-technical@openldap.org

1 participants
9989 discussions

ACL with filter memberOf
by Carsten Jäckel 06 Aug '23

06 Aug '23

Dear experts, an accessUser account used for application access has to be granted read access to member accounts of a group (groupOfNames). The list of attributes to be read by the accessUser is limited. The accessUser has to search in the limited attribute list (e. g. uid=abcd). Using OpenLDAP 2.4.49 (with configured overlay 'memberOf') we achieved this goal by configuring the following ACLs in olcAcces of olcDatabase={1}mdb,cn=config: {0}to * by self read by anonymous auth by * break {1}to dn.subtree="dc=example,dc=com" filter="(|(dc=example)(dc=users))" attrs="entry,Objectclass,dc" by dn.exact="cn=accessUser,dc=accessUsers,dc=example,dc=com" read by * break {2}to dn.subtree="dc=users,dc=example,dc=com" filter="(memberOf=cn=group1,dc=groups,dc=example,dc=com)" attrs="entry,objectclass,uid,cn,displayName,telephoneNumber,ou,mail,memberOf,entryDN" by dn.exact="cn=accessUser,dc=accessUsers,dc=example,dc=com" read by * break During migration to OpenLDAP 2.5 we eliminated the overlay 'memberOf' and replaced it's functionality by the overlay 'dynlist'. As a consequence we experienced that the filter statement in ACL {2} doesn't work any longer in OpenLDAP 2.5. Result of ldapsearch -x -W -D "cn=accessUser,dc=accessUsers,dc=example,dc=com" -b "dc=users,dc=example,dc=com" -s sub "(memberOf=cn=group1,dc=groups,dc=example,dc=com)" "entry objectclass uid cn displayName telephoneNumber ou mail memberOf entryDN" doesn't return any results alhough the group object contains members. We suppose that it has something to to with memberOf becoming some kind of 'virtual' attribute which may be only calculated when explicitly asked for. (Please correct this assumtion if it's incorrect.) These are the relevant parts of our configuration in OpenLDAP 2.5: Frontend: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=subschema" by * read mdb: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/symas/openldap-data olcAccess: {0}to * by self read by anonymous auth by * break olcAccess: {1}to dn.subtree="dc=example,dc=com" filter="(|(dc=example)(dc=us ers))" attrs="entry,Objectclass,dc" by dn.exact="cn=accessUser,dc=accessUse rs,dc=example,dc=com" read by * break olcAccess: {3}to dn.subtree="dc=users,dc=example,dc=com" filter="(|(dc=examp le)(dc=users))" attrs="entry,Objectclass,dc" by dn.exact="cn=accessUser,dc= accessUsers,dc=example,dc=com" read by * break" olcDbIndex: cn olcDbIndex: default eq,sub olcDbIndex: departmentNumber pres,eq,sub olcDbIndex: displayName olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: gidNumber eq olcDbIndex: givenName olcDbIndex: host eq olcDbIndex: inetUserStatus olcDbIndex: mail eq olcDbIndex: mailLocalAddress eq olcDbIndex: member eq olcDbIndex: memberOf eq olcDbIndex: memberUid eq olcDbIndex: objectclass eq olcDbIndex: sn olcDbIndex: sudoHost eq,sub olcDbIndex: sudoUser eq,sub olcDbIndex: uid olcDbIndex: uidNumber eq olcDbIndex: uniqueMember eq olcDbMaxReaders: 126 olcDbMaxSize: 10000000000 olcReadOnly: FALSE olcRootDN: cn=manager,dc=example,dc=com olcRootPW:: <abcd1234> olcSuffix: dc=example,dc=com dn: olcOverlay={0}refint,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcRefintConfig objectClass: top olcOverlay: {0}refint olcRefintAttribute: member olcRefintNothing: cn=someone,dc=example,dc=com dn: olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcPPolicyConfig objectClass: top olcOverlay: {1}ppolicy olcPPolicyDefault: cn=passwordDefault,ou=password_policies,ou=configurations ,dc=example,dc=com olcPPolicyHashCleartext: TRUE dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcDynListConfig objectClass: olcOverlayConfig objectClass: top olcOverlay: {2}dynlist olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames dn: olcOverlay={3}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig olcOverlay: {3}syncprov olcSpCheckpoint: 10 1 olcSpSessionlog: 20000 dn: olcOverlay={4}dds,olcDatabase={1}mdb,cn=config objectClass: olcDDSConfig objectClass: olcOverlayConfig olcOverlay: {4}dds olcDDSinterval: 1h olcDDSmaxTtl: 10d olcDDSminTtl: 10s olcDDSstate: TRUE olcDDStolerance: 5s dn: olcOverlay={5}otp,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: top olcOverlay: {5}otp My question now is: what is the correct ACL configuration/filter statement to ask for a user's group memberships to achieve our goal in OpenLDAP 2.5? Any help would be greatly appreciated! --Carsten

2 1

rhel8 OS rpm spec file
by Kaushal Shriyan 05 Aug '23

05 Aug '23

Hi, Is there a way to generate openldap-servers.x86_64 rpm spec file from https://www.openldap.org/software/download/OpenLDAP/openldap-release/openld… # ll total 900 -rw-r--r-- 1 1001 1001 11109 Jul 10 21:59 aclocal.m4 -rw-r--r-- 1 1001 1001 6100 Jul 10 21:59 ANNOUNCEMENT drwxr-xr-x 2 1001 1001 4096 Jul 10 21:59 build -rw-r--r-- 1 1001 1001 14120 Jul 10 21:59 CHANGES drwxr-xr-x 3 1001 1001 38 Jul 10 21:59 clients -rwxr-xr-x 1 1001 1001 753489 Jul 10 21:59 configure -rw-r--r-- 1 1001 1001 99724 Jul 10 21:59 configure.ac drwxr-xr-x 7 1001 1001 129 Jul 10 21:59 contrib -rw-r--r-- 1 1001 1001 2345 Jul 10 21:59 COPYRIGHT drwxr-xr-x 8 1001 1001 102 Jul 10 21:59 doc drwxr-xr-x 3 1001 1001 4096 Jul 10 21:59 include -rw-r--r-- 1 1001 1001 3793 Jul 10 21:59 INSTALL drwxr-xr-x 8 1001 1001 123 Jul 10 21:59 libraries -rw-r--r-- 1 1001 1001 2214 Jul 10 21:59 LICENSE -rw-r--r-- 1 1001 1001 1029 Jul 10 21:59 Makefile.in -rw-r--r-- 1 1001 1001 3594 Jul 10 21:59 README drwxr-xr-x 4 1001 1001 52 Jul 10 21:59 servers drwxr-xr-x 5 1001 1001 93 Jul 10 21:59 tests # ./configure --help | grep spec To assign environment variables (e.g., CC, CFLAGS...), specify them as Defaults for the options are specified in brackets. --help=short display options specific to this package `/usr/local/bin', `/usr/local/lib' etc. You can specify --with-odbc with specific ODBC support compiler's sysroot if not specified). # Please guide me. Thanks in Advance. Best Regards, Kaushal

2 1

requested some clean up / verification of my acls (paid)
by Marc 04 Aug '23

04 Aug '23

I have ~11 acl's that could use more attention, limiting access to what is required (to mta, system, cron). They are working, but I would to have an expert look at them. I think someone with experience could tune some things better. Anyone interested?

2 2

excluding attribute in acl
by Marc 03 Aug '23

03 Aug '23

Is it possible to specify something like allow access to all attributes - userPassword?

2 1

restricting acls more by adding a filter
by Marc 03 Aug '23

03 Aug '23

I have a ldapsearch that returns this object sendmailMTAClassName: w sendmailMTAClassValue: xxx sendmailMTAClassValue: yyy sendmailMTAClassValue: zzz objectClass: sendmailMTA objectClass: sendmailMTAClass I thought I could strengthen the acl by just appending to with a filter but if I add these below, the ldapsearch does not return anything err=32 filter=(objectClass=sendmailMTAClass) filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA)) filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA)) filter=(objectClass=sendmailMTA*) If I change the filter to this, I get the expected result again filter=(objectClass=*) Goal is to have ldapsearch only list the specific objectClasses. Or should I do this with listing only attributes.

3 6

Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
by Sean Gallagher 01 Aug '23

01 Aug '23

Hi All, This is loosely related to issue 10065 https://bugs.openldap.org/show_bug.cgi?id=10065, but can be read independently. I have devised a work-around to slapd's inability to check client names on Client certificates and am in the process of removing a proxy (haproxy) I had in front of my slapd server. I have however come across an annoying compromise and I'm offering here a suggestion on how to remove it. In particular, with the proxy, I could write rules targeting particular clients that worked, even before their initial "bind" operation by using the "sockname=" pattern in the access control rules. This does not seem possible when slapd talks directly to the clients. before the initial "bind" operation, only the IP address is available to tell clients apart, which are not very reliable. IP addresses are easily spoofed. It would be much better to use the client certificate to match against the particular client. Currently the client ID on the certificate is passed to the SASL layer with the sasl_setprop(...,SASL_AUTH_EXTERNAL,...) call. There it remains until the client performs a "bind" using the SASL EXTERNAL mechanism. At this point, the EXTERNAL client ID is used to derive a distinguished name by filtering it through the "olcAuthzRegexp". It should be noted that LDAP v3 does not require the client to perform such a bind operation. My Proposal is to expose the EXTERNAL identity to the ACL rules in a similar way to how the "real" prefix exposes the authentication identity - by creating an "external" prefix. As such, the matching rules externalanonymous externalusers externalself externaldn externaldnattr Could be used to restrict access to clients, even before or without a bind operation. To maintain naming consistency, The name passed to SASL could have the "olcAuthzRegexp" mapping applied before the ACL rule is applied. In this case, the "external" identity would be the same as the unprefixed identity, after a bind using SASL EXTERNAL mechanism had occured. This arrangement would have several advantages including: *) only exposing the userPassword to the particular client that needs it. *) enforcing client/IP address associations in a rigorous manner. *) general ACL rules for operations that do not need a "bind" operation. *) restricting SIMPLE binds to particular clients. Any Thoughts ? -- This email has been checked for viruses by AVG antivirus software. www.avg.com

6 27

updating from el7 to alpine openldap 2.6
by Marc 01 Aug '23

01 Aug '23

I am updating my ldap container and migrate from el7 to alpine. While running some test queries I noticed that the new 2.6 alpine has probably different defaults, I am getting "Size limit exceeded (4)". However this does not show in the ldap error log. What would be good loglevel config to see quickly if there is an issue with client queries? I am a little worried that if MTA's are getting incomplete results and dropping mail.

2 2

OpenLDAP with DANE
by John Scott 30 Jul '23

30 Jul '23

Hello, Thanks to the TLS callback support, I discovered that using DANE with libldap is actually really easy. OpenSSL has DANE support built-in, so all you have to do is turn it on and get the DNS records. As a proof-of-concept, I've written an example that disables the use of certificate authorities and uses DANE alone, in accordance with their preference in the TLSA record, to connect to Debian's LDAP instance. Note that Debian currently uses GnuTLS for OpenLDAP which has, in my opinion, not so good DANE support, so this code won't work. I'm offering my help to the Debian maintainers though to change that. Code is at https://salsa.debian.org/-/snippets/649

2 1

lmdb and alignment clarification
by bach＠bullno1.com 27 Jul '23

27 Jul '23

I have read a few threads on lmdb alignment but I am still not clear on what kind of padding should be done. Use case: I want to store aligned SIMD vectors in the value and operate on them directly with SIMD instructions without copying. As I understand it, lmdb guarantees 2-byte alignment. However, it can also move nodes around for tree rebalancing or page reclaiming. Thus, merely aligning the key and value might not be enough. Right now, based on my reading of the code, I'm assuming that the data layout in a leaf page is like this: [page_header][mp_ptrs]...[node_header][key][value][node_header][key][value] Basically, nodes are stored contiguously in memory with `node_header` and `key` always aligned to 2-byte. New nodes are allocated from the bottom of the page and offsets are stored/allocated into MDB_page.mp_ptrs from the top. Is this correct? If so, to ensure that `value` has a certain alignment, even when accounting for nodes being moved around, one would also have to ensure that `sizeof(node_header) + sizeof(key) + sizeof(value)` is a multiple of the alignment. Is this reasoning correct? For the overflow page, is the structure similar? Just that one single page header is used for a number of contiguous pages.

2 2

Slapd migrate from hdb to lmdb on 2.5.13
by Richard Rosner 24 Jul '23

24 Jul '23

Hi, I just upgraded our servers from Debian 11 to 12. I'm not sure if this is an upstream change, but slapd 2.5 on Debian 12 doesn't support the HDB and BDB backends, so the database needs to be migrated to LMDB. Unfortunately I neglected to check the backend in use for all instances. Our main slapd instance already used LMDB, but another instance, that's just getting a copy of that database through sync replication, was still using HDB. At first I only noticed an error during upgrade. I found a guide (https://sources.debian.org/src/openldap/2.5.13%2Bdfsg-5/debian/slapd.README… line 255 following) to do the upgrade to 2.5.x if it fails, which showed me the error. lt_dlopenext failed: (back_hdb) file not foundslapadd: could not add entry dn="cn=module{0},cn=config" (line=16): <olcModuleLoad> handler exited with 1 Closing DB... So I followed the setps under "BDB/HDB backends removed: migrating to LMDB backend". But upon trying to restore the backup again, it just told me slapadd: could not add entry dn="cn=config" (line=1): Closing DB... The first set of lines in cn\=config.ldif reads 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: 71b384b4-aca9-1032-883a-d9850217023f creatorsName: cn=config createTimestamp: 20130908080726Z entryCSN: 20130908080726.757296Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130908080726Z So I'm not sure what it wants to tell me now. I already checked against the config of the main instance, made a few modifications, but the error message is the same. Here the modifications: 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: 71b384b4-aca9-1032-883a-d9850217023f creatorsName: cn=config createTimestamp: 20130908080726Z olcTLSCACertificateFile: /etc/ssl/certs/xyz-chain.pem olcTLSCertificateFile: /etc/ssl/certs/mail.domain.de.cert.pem olcTLSCertificateKeyFile: /etc/ssl/private/mail.domain.de.private.pem entryCSN: 20130908080726.757296Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=mail modifyTimestamp: 20130908080726Z Could anybody tell me what exactly the problem is? Richard

2 12

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical