openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

Questions about slapo-memberof
by Alex Samad - Yieldbroker 18 Aug '23

18 Aug '23

Hi I am using slapo-memberof wondering about its performance, I have a couple of groups that have a large pool of unique member attributes. I had some maintenance code that would update the largest group - say about 4k uniquemember entries. The code is wrong it rewrite all of the attributes instead of just updating the diff. But what we noticed is that for upto 13 sec the memberof attrib could be wrong on a user object whilst I presume slapo-memberof re evaluated all of the memberships Question I am in the middle of rewritting the maintenance code - will slapo-memberof only reprocess the additions / diffs or will it reeval all ... Do I have any control over how many threads or are there any control knobs I can tune for the slapo-memberof to help with this ? Thanks Alex

1 0

Re: 2.6.4 replication oddness
by Quanah Gibson-Mount 17 Aug '23

17 Aug '23

--On Thursday, August 17, 2023 2:02 PM -0400 Brendan Kearney <bpk678(a)gmail.com> wrote: >> Generally an export of the cn=config DB, minus any passwords of the >> different providers. If the config is identical across all 3, then >> just one copy of the config. >> >> --Quanah > > i have attached the export of cn=config, with sensitive data removed. > the config is intended to be identical between the nodes, though i have > broken things apart, in an attempt to rectify some issues and update > things to new functionality. I'm going to take this off list, but your config is an utter mess and contains a lot of things that need fixing. ;) I'll follow up once I have some time to fix it. --Quanah

2 2

slapd module thread synchronization and portability. __atomic_xxx().
by Sean Gallagher 17 Aug '23

17 Aug '23

Hi OpenLDAP affiliates, I'm working on a slapd module and have started looking at thread safety. I've noticed that lloadd uses __atomic_xx GCC builtins but slapd does not. Is there are reason for this? Does lloadd compile and run on all the same targets that slapd does? Sean. -- This email has been checked for viruses by AVG antivirus software. www.avg.com

2 1

2.6.4 replication oddness
by Brendan Kearney 17 Aug '23

17 Aug '23

list members, i am implementing slapd 2.6.4, having had 2.4.x running for quite some time. i had 2 primary nodes with n-way multi primary replication working like a charm, and want to have 2.6.4 with 3 primary nodes. i keep running into some odd issues when i bring up all three nodes and they begin replicating between each of the nodes. i have failure messages showing the instances core-dumping and want to find why the core dumps occur. Aug 08 16:21:20 server1 systemd[1]: slapd.service: Main process exited, code=dumped, status=11/SEGV Aug 08 16:21:20 server1 systemd[1]: slapd.service: Failed with result 'core-dump'. i have enable "stats" log level, and don't get much more info. i can run one instance and seem to be working without core dumping, but if i turn up one or both of the other slapd instances, all 3 of the instances begin failing. should i bump the log level up or is there diagnostics i can run, to find the reason things are failing? any insight is greatly appreciated. if i need to provide more info, let me know what is needed. thanks in advance, brendan

2 8

ldap_add: Naming violation (64) additional info: value of single-valued naming attribute 'dc' conflicts with value present in entry
by Kaushal Shriyan 17 Aug '23

17 Aug '23

Hi, I am running the below mentioned openldap server version on CentOS Linux release 7.9.2009 (Core). The details are as follows. # cat /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" # # rpm -qa | grep openldap openldap-clients-2.4.44-25.el7_9.x86_64 openldap-servers-2.4.44-25.el7_9.x86_64 openldap-2.4.44-25.el7_9.x86_64 # # slapd -VV @(#) $OpenLDAP: slapd 2.4.44 (Feb 23 2022 17:11:27) $ mockbuild(a)x86-01.bsys.centos.org: /builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd # systemctl status slapd ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2023-08-17 05:57:50 IST; 5min ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Process: 6448 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=0/SUCCESS) Process: 6410 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS) Main PID: 6450 (slapd) CGroup: /system.slice/slapd.service └─6450 /usr/sbin/slapd -u ldap -h ldapi:/// ldap:/// Aug 17 05:59:50 cbopenldap slapd[6450]: conn=1001 op=1 RESULT tag=105 err=64 text=value of single-valued naming attribute 'dc' conflicts with value present in entry Aug 17 05:59:50 cbopenldap slapd[6450]: conn=1001 op=2 UNBIND Aug 17 05:59:50 cbopenldap slapd[6450]: conn=1001 fd=11 closed Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 fd=11 ACCEPT from IP=[::1]:42840 (IP=[::]:389) Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 op=0 BIND dn="" method=128 Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 op=0 RESULT tag=97 err=0 text= Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 op=1 SRCH base="dc=corporate,dc=mydomain,dc=in" scope=2 deref=0 filter="(objectClass=*)" Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 op=2 UNBIND Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 fd=11 closed # # netstat -antup | grep -i 389 tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 6450/slapd tcp6 0 0 :::389 :::* LISTEN 6450/slapd # The distinguished name is *dc=corporate,dc=mydomain,dc=in * # cat mydomain_config.ldif dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=corporate,dc=mydomain,dc=in dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootDN olcRootDN: cn=admin,dc=corporate,dc=mydomain,dc=in #ldapmodify -Y EXTERNAL -H ldapi:/// -f mydomain_config.ldif # cat mydomain_config2.ldif dn: olcDatabase={2}hdb,cn=config changeType: modify replace: olcRootPW olcRootPW: {SSHA}m2NMC1NMrp5BavWVSHm2Becq7J2fHDNa #ldapmodify -Y EXTERNAL -H ldapi:/// -f mydomain_config2.ldif # cat mydomain_config3.ldif dn: olcDatabase={1}monitor,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external, cn=auth" read by dn.base="cn=admin,dc=corporate,dc=mydomain,dc=in" read by * none #ldapmodify -Y EXTERNAL -H ldapi:/// -f mydomain_config3.ldif The distinguished name is *dc=corporate,dc=mydomain,dc=in * # cat mydomain.ldif dn: dc=corporate,dc=mydomain,dc=in objectClass: dcObject objectClass: organization dc: mydomain o: mydomain # ldapadd -f mydomain.ldif -D cn=admin,dc=corporate,dc=mydomain,dc=in -W adding new entry "dc=corporate,dc=mydomain,dc=in" ldap_add: Naming violation (64) additional info: value of single-valued naming attribute 'dc' conflicts with value present in entry # ldapsearch -x -b dc=corporate,dc=mydomain,dc=in *Output of ldapsearch -x -b dc=corporate,dc=mydomain,dc=in command* # extended LDIF # # LDAPv3 # base <dc=corporate,dc=mydomain,dc=in> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1 # I am encountering the below issue as explained with the steps mentioned above ldap_add: Naming violation (64) > additional info: value of single-valued naming attribute 'dc' conflicts > with value present in entry Am I missing anything? Please guide me. Thanks in advance. Best Regards, Kaushal

2 1

Re: ldapmodify: wrong attributeType at line 5, entry "olcDatabase={2}hdb,cn=config"
by Kaushal Shriyan 11 Aug '23

11 Aug '23

On Wed, Aug 9, 2023 at 8:29 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Wednesday, August 9, 2023 7:31 PM +0530 Kaushal Shriyan > <kaushalshriyan(a)gmail.com> wrote: > > > Configure OpenLDAP server while sending the configuration to the LDAP > > server. > ># cat db.ldif > > dn: olcDatabase={2}hdb,cn=config > > changetype: modify > > replace: olcSuffix > > olcSuffix: dc=itzgeek,dc=local > > dn: olcDatabase={2}hdb,cn=config > > changetype: modify > > replace: olcRootDN > > olcRootDN: cn=ldapadm,dc=itzgeek,dc=local > > dn: olcDatabase={2}hdb,cn=config > > changetype: modify > > replace: olcRootPW > > olcRootPW: {SSHA}RCQG8Sec/XtirtjxXL2cbAyeeWH2A9r/ > > > This is not valid LDIF change format. I suggest reading documentation on > how to create valid LDIF changes. > > <https://ldap.com/ldif-the-ldap-data-interchange-format/> has some good > detail, see the section on: > > LDIF Modify Change Records > > Regards, > Quanah > > Thanks Quanah for the quick email response. Is there a way to validate the LDIF file once it is created? Please guide me. Thanks in advance. Best Regards, Kaushal

2 1

ldapmodify: wrong attributeType at line 5, entry "olcDatabase={2}hdb,cn=config"
by Kaushal Shriyan 09 Aug '23

09 Aug '23

Hi, I am running the below mentioned openldap server version on CentOS Linux release 7.9.2009 (Core) # rpm -qa | grep openldap openldap-servers-2.4.44-25.el7_9.x86_64 openldap-servers-sql-2.4.44-25.el7_9.x86_64 openldap-devel-2.4.44-25.el7_9.x86_64 openldap-2.4.44-25.el7_9.x86_64 compat-openldap-2.3.43-5.el7.x86_64 openldap-clients-2.4.44-25.el7_9.x86_64 # # slapd -VV @(#) $OpenLDAP: slapd 2.4.44 (Feb 23 2022 17:11:27) $ mockbuild(a)x86-01.bsys.centos.org: /builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd # # systemctl status slapd ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2023-08-09 18:17:23 IST; 3min 36s ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Main PID: 16246 (slapd) CGroup: /system.slice/slapd.service └─16246 /usr/sbin/slapd -u ldap -h ldapi:/// ldap:/// Aug 09 18:17:22 cbopenldap slapd[16243]: @(#) $OpenLDAP: slapd 2.4.44 (Feb 23 2022 17:11:27) $ mockbuild(a)x86-01.bsys.centos.org: /builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd Aug 09 18:17:23 cbopenldap slapd[16246]: slapd starting Aug 09 18:17:23 cbopenldap systemd[1]: Started OpenLDAP Server Daemon. Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 fd=11 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 op=0 BIND dn="" method=163 Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber...l,cn=auth" Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 op=0 RESULT tag=97 err=0 text= Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 op=1 UNBIND Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 fd=11 closed Hint: Some lines were ellipsized, use -l to show in full. # *Setup LDAP admin password* slappasswd -h {SSHA} -s ldappassword # cd /etc/openldap/slapd.d/ # ls -ltrh total 4.0K -rw------- 1 ldap ldap 589 Aug 5 16:27 cn=config.ldif drwxr-x--- 3 ldap ldap 182 Aug 5 16:37 cn=config # cd cn\=config # ls -ltrh total 20K -rw------- 1 ldap ldap 378 Aug 5 16:27 cn=schema.ldif -rw------- 1 ldap ldap 609 Aug 5 16:27 olcDatabase={2}hdb.ldif -rw------- 1 ldap ldap 443 Aug 5 16:27 olcDatabase={-1}frontend.ldif -rw------- 1 ldap ldap 513 Aug 5 16:27 olcDatabase={0}config.ldif -rw------- 1 ldap ldap 611 Aug 5 16:37 olcDatabase={1}monitor.ldif drwxr-x--- 2 ldap ldap 108 Aug 5 16:38 cn=schema # cd cn=schema # ls -ltrh total 40K -rw------- 1 ldap ldap 16K Aug 5 16:27 cn={0}core.ldif -rw------- 1 ldap ldap 12K Aug 5 16:38 cn={1}cosine.ldif -rw------- 1 ldap ldap 6.5K Aug 5 16:38 cn={2}nis.ldif -rw------- 1 ldap ldap 2.9K Aug 5 16:38 cn={3}inetorgperson.ldif # Configure OpenLDAP server while sending the configuration to the LDAP server. # cat db.ldif dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=itzgeek,dc=local dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootDN olcRootDN: cn=ldapadm,dc=itzgeek,dc=local dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {SSHA}RCQG8Sec/XtirtjxXL2cbAyeeWH2A9r/ # # ldapmodify -Y EXTERNAL -H ldapi:/// -f db.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 ldapmodify: wrong attributeType at line 5, entry "olcDatabase={2}hdb,cn=config" # Please guide me. Thanks in advance. Best Regards, Kaushal

2 1

Help writing a slapd plugin
by John Scott 07 Aug '23

07 Aug '23

Hi, Inspired by the proprietary server at ldap.dnssek.info, I'd like to make a slapd plugin that, when queried for a particular email address, finds the OpenPGP keys and S/MIME certificates by doing DNS lookups (possibly aided by DANE), and then serves them back to the requestor. Currently the documentation in the OpenLDAP Administrator's Guide still needs to be written. Since not a lot of software supports DANE right now, but a lot of programs *do* support LDAP, I think a bridge between the two is something that could really benefit the Internet community. Could someone steer me in the right direction on how to get started? Thanks

3 2

Idea for security module: Using dnX509peerNormalize() to validate client certificates
by Sean Gallagher 07 Aug '23

07 Aug '23

Hi OpenLDAP team, I am investigating writing a module to perform certificate validation as has been discussed in previous posts (See the "Proposal to strengthen slapd EXTERNAL authentication" thread on the openldap-technical(a)openldap.org list). The idea is to inspect the subject name on the client certificate as soon as possible after TLS is established and close the connection if it does not match some predefined pattern. This would allow client certificates signed by public CAs to be used safely with slapd. Looking through the code, I see that dnX509peerNormalize() is called almost immediately after the TLS is established and that it may be handled by a callable handler installed by the register_certificate_map_function() entry point. This would be an ideal place to inspect the certificate. The only problem being it that there is no way to "reject" a certificate and force the connection to be closed. It may be possible to use the ssl context passed into the dnX509peerNormalize() function to close the connection but this would not be very clean and likely have undesirable side effects. What would be good is if dnX509peerNormalize() could return a particular error code to signal that the connection should be immediately closed. I see that LDAP_INVALID_CREDENTIALS is already used to signal benign invalid credentials. Maybe a new error code is required. something like "LDAP_HOSTILE_CREDENTIALS". connection.c: connection_read() could then detect this and close the connection in an orderly fashion by calling connection_closing( c, "TLS Client certificate rejected" ); connection_close( c ); This would seem to be a generally useful thing to have in the slapd core. Is this something the OpenLDAP project would consider doing? Sean. -- This email has been checked for viruses by AVG antivirus software. www.avg.com

2 5

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

07 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical