openldap-technical April 2022

openldap-technical@openldap.org

27 participants
27 discussions

OPENLDAP client API option to capture the communication traces in a file
by chou.ravin177＠gmail.com 25 Apr '22

25 Apr '22

How client can leverage this LBER_OPT_LOG_PRINT_FILE option to redirect the log to the file? I had tried setting this option after ldap_initalize from the client end. But still, I couldn't get any traces in the supplied logfile. The traces works fine in the console mode with DEBUG_OPENLDAP. But they seem not to be working with this. Could you suggest any other approach or configuration which can be used to capture the underlying OpenLDAP communication from the client-side? @hyc/@openldap-technical-owner@openldap.org: Would appreciate it if you can share any thoughts?

1 0

Attempting to build docker image with symas RPMs
by thomaswilliampritchard＠gmail.com 25 Apr '22

25 Apr '22

I tried searching before posting but was getting a gateway timeout - apologies if this was answered previously. I am attempting to build a docker image from debian using symas RPMs to facilitate local testing. I am new to RPMs / Linux Package Management so forgive me if this is an obvious answer. ``` FROM debian:buster RUN apt update RUN apt install --yes --quiet wget RUN apt install --yes --quiet gnupg RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys DA26A148887DCBEB RUN wget -q https://repo.symas.com/configs/SOLDAP/d10/release25.list -O /etc/apt/sources.list.d/soldap-release25.list RUN apt update RUN apt install symas-openldap-clients symas-openldap-server RUN rm --force --recursive /var/lib/apt/lists/* ``` This fails on the symas-openldap-clients and symas-openldap-server installation with #11 0.600 E: Unable to locate package symas-openldap-clients #11 0.600 E: Unable to locate package symas-openldap-server If I skip that step I can build and sanity check the debian version ``` root@fc0489d57cd4:/# cat /etc/issue Debian GNU/Linux 10 \n \l ``` Any advice how to make this work for Debian? Is it possible to make this work for centos7 image? I understand symas only publishes for RHEL but curious if centos7 can work with the REHL repo information. I was unable to get it to work failing with a similar issue.

4 7

Re: SASL Authentication Pass-through
by Quanah Gibson-Mount 21 Apr '22

21 Apr '22

--On Monday, April 11, 2022 7:23 PM +0000 Dean Lewis <deanlewis(a)nexus-people.com> wrote: > > > If I had a choice, I wouldn't be using this version at all. As with most > packages, I'd run the very latest. But I don't have a choice here so this > question is about getting pass-through auth working with OpenLDAP 2.4 and > AD. > > > If that's possible, what am I missing in the configuration? No idea. Remoteauth was written because of a number of issues around using SASL passthrough. If your OpenLDAP servers are running RedHat (or derivatives), Debian, or Ubuntu, there are freely available options that allow you to be using current releases of OpenLDAP, such as the LTB project and the builds from Symas. Regards, Quanah

2 4

issues configuring SASL EXTERNAL and proxyauth with chain used for ppolicy_forward_updates
by Kartik Subbarao 18 Apr '22

18 Apr '22

I have a consumer server (2.4.57) that successfully forwards pwdFailureTime modifications to the master server using GSSAPI authentication. I want to replace GSSAPI with certificate-based (SASL EXTERNAL) authentication along with proxy authorization. Basically, I want to configure the equivalent of the following command line: LDAPTLS_KEY=server.key LDAPTLS_CERT=server.crt \ ldapmodify -Z -Y EXTERNAL \ -e '!authzid=dn:cn=proxydn,dc=example,dc=com' -e relax \ -h ldap-master.example.com -f update_pwdfailuretime.ldif The command line works as expected -- it authenticates successfully using the server certificate, and then does PROXYAUTHZ to cn=proxydn,dc=example,dc=com to perform the modify operation. The issue is when I try to configure this behavior with chain on the consumer server. I've tried various incantations along these lines: chain-idassert-bind bindmethod=SASL saslmech=EXTERNAL tls_cert=server.crt tls_key=tls.key authzId=dn:cn=proxydn,dc=example,dc=com The SASL EXTERNAL authentication works fine -- It binds to the master with the DN mapped from the certificate's subject. But it doesn't do the proxyauthz to cn=proxydn,dc=example,dc=com. I've read through the docs in detail and tried various modes, flags and other settings, but I can't get it to do the proxy authz. Does anyone have a known working config for this kind of setup that they can share? Otherwise, any suggestions on the best way to troubleshoot this further would be great. Thanks, -Kartik

4 5

Re: Understanding bind_anon_dn and update_anon
by Dave Macias 18 Apr '22

18 Apr '22

> > What you want is not possible with a simple bind (bind as a user without > providing a password). You could use something like client certificate > authentication (SASL/EXTERNAL). > > Regards, > Quanah > Thank you for the explanation! Appreciate it I'll explore this route. Best, Dave

1 0

Parameter for choosing algorithm in module "argon2.la"
by Juergen.Sprenger＠swisscom.com 18 Apr '22

18 Apr '22

Hi, Currently I am trying to use argon2 password hashes with OpenLDAP 2.6.1. Everything works fine so far, but I can't get module argon2.la to create argon2id hashes. In argon2 command is a switch to use Argon2id instead of Argon2i: echo -n "password" | argon2 somesalt -id -e $argon2id$v=19$m=4096,t=3,p=1$c29tZXNhbHQ$qLml5cbqFAO6YxVHhrSBHP0UWdxrIxkNcM8aMX3blzU slappasswd -o module-load="argon2.la" -h {ARGON2} -s password {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$P3r67PwtSB5fq2JvTaGZfw$WNup4MZcRkvGwIVWFKjU92nHiM/vu6DUTnSOVpLYwVM Is it possible to use choose between argon2i, argon2d and argon2id in that library? Regards Juergen Sprenger

2 1

Understanding bind_anon_dn and update_anon
by Dave Macias 18 Apr '22

18 Apr '22

Hello, Running: 2.6.1 Looking at the slapd.conf man page we have this interesting paragraph: *bind_anon_cred allows anonymous bind when credentials are not empty (e.g. when DN is empty). bind_anon_dn allows unauthenticated (anonymous) bind when DN is not empty. update_anon allows unauthenticated (anonymous) update operations to be processed (subject to access controls and other administrative limits).* *My goal is to have a dn who is a memberof a group to be able to add/edit/deletes (write) operations to a subtree by only using the binddn (no password).* I have no issues with the below acl when we ldapmodify/delete/add with binddn+password *olcAccess: {2}to dn.subtree="ou=dns,dc=example,dc=net" filter="(!(|(idnsName=*'.')(objectClass=organizationalUnit)))" by dn="cn=dnsmanager,dc=example,dc=net" write by group.expand="cn=dns,ou=group,dc=example,dc=net" write by * read* I added the below to my* dn: cn=config* *olcAllows: bind_anon_dnolcAllows: update_anon* Since I still could not make any write operations with simple binddn I changed the ACL to below. (adding anonymous write) olcAccess: {2}to dn.subtree="ou=dns,dc=example,dc=net" filter="(!(|(idnsName=*'.')(objectClass=organizationalUnit)))" by dn="cn=dnsmanager,dc=example,dc=net" write by group.expand="cn=dns,ou=group,dc=example,dc=net" write by anonymous write by * read This of course still was not my end goal since I could use a nonexisting binddn to make changes. > ldapsearch -xLLL "filter" dn | awk '{print $NF}' | sed '/^$/d' | ldapdelete -D uid=*someuserthatdoesnotexist*,ou=people,dc=example,dc=net So I'm guessing I'm not understanding or not configuring this correctly. Is it even possible to do this? Any input is appreciated. Thank you, Dave

2 1

MemberOf group in group search not working
by erikdewaard＠gmail.com 16 Apr '22

16 Apr '22

Hi, On openldap 2.5.11 I have some weird behavior with group in group searches using memberOf. #Working # ldapsearch -LLL -H ldap:// -x -b 'dc=example,dc=com' '(uid=user5)' memberOf dn: uid=user5,ou=People,dc=example,dc=com memberOf: cn=groupingroup,ou=groups,dc=example,dc=com #Working # ldapsearch -LLL -H ldap:// -x -b 'dc=example,dc=com' '(uid=user1)' memberOf dn: uid=user1,ou=People,dc=example,dc=com memberOf: cn=group1,ou=groups,dc=example,dc=com memberOf: cn=groupingroup,ou=groups,dc=example,dc=com Now the weird behavior part when querying if user1 is indeed a memberOf groupingroup i sometimes get 0 results, need to query multiple times before i indeed get the correct answer. # ldapsearch -H ldap:/// -LLL -x -b 'dc=example,dc=com' '(&(uid=user1)(|(memberOf=cn=groupingroup,ou=groups,dc=example,dc=com)))' uid # ldapsearch -H ldap:/// -LLL -x -b 'dc=example,dc=com' '(&(uid=user1)(|(memberOf=cn=groupingroup,ou=groups,dc=example,dc=com)))' uid # ldapsearch -H ldap:/// -LLL -x -b 'dc=example,dc=com' '(&(uid=user1)(|(memberOf=cn=groupingroup,ou=groups,dc=example,dc=com)))' uid # ldapsearch -H ldap:/// -LLL -x -b 'dc=example,dc=com' '(&(uid=user1)(|(memberOf=cn=groupingroup,ou=groups,dc=example,dc=com)))' uid dn: uid=user1,ou=People,dc=example,dc=com uid: user1 user5 completely fell of the map. # ldapsearch -H ldap:/// -LLL -x -b 'dc=example,dc=com' '(&(uid=user5)(|(memberOf=cn=groupingroup,ou=groups,dc=example,dc=com)))' uid When querying memberOf groupingroup, it looks like its randomly returning just one group. #only returning group2 # ldapsearch -H ldap:// -LLL -x -b 'dc=example,dc=com' "(memberOf=cn=groupingroup,ou=groups,dc=example,dc=com)" uid dn: uid=user3,ou=People,dc=example,dc=com uid: user3 dn: uid=user4,ou=People,dc=example,dc=com uid: user4 dn: cn=group1,ou=Groups,dc=example,dc=com dn: cn=group2,ou=Groups,dc=example,dc=com #only returning group1 # ldapsearch -H ldap:// -LLL -x -b 'dc=example,dc=com' "(memberOf=cn=groupingroup,ou=groups,dc=example,dc=com)" uid dn: uid=user1,ou=People,dc=example,dc=com uid: user1 dn: uid=user2,ou=People,dc=example,dc=com uid: user2 dn: cn=group1,ou=Groups,dc=example,dc=com dn: cn=group2,ou=Groups,dc=example,dc=com --conf # stand-alone slapd config include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/dyngroup.schema # allow big PDUs from anonymous (for testing purposes) sockbuf_max_incoming 4194303 moduleload back_ldap moduleload dynlist ####################################################################### # database definitions ####################################################################### database config database mdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret directory /var/lib/ldap lastbind off overlay dynlist dynlist-attrset groupOfURLs memberURL uniqueMember+memberOf@groupOfUniqueNames* database monitor --conf --data dn: dc=example,dc=com structuralObjectClass: domain dc: example objectClass: top objectClass: domain dn: ou=People,dc=example,dc=com structuralObjectClass: organizationalUnit ou: People objectClass: top objectClass: organizationalUnit dn: ou=Groups,dc=example,dc=com ou: Groups structuralObjectClass: organizationalUnit objectClass: organizationalUnit objectClass: top dn: uid=user1,ou=People,dc=example,dc=com displayName: User 1 cn: User 1 loginShell: /bin/bash uidNumber: 2001 gidNumber: 3000 homeDirectory: /home/user1 mail: user1(a)example.com uid: user1 sn: user1 structuralObjectClass: inetOrgPerson objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount dn: uid=user2,ou=People,dc=example,dc=com displayName: User 2 cn: User 2 loginShell: /bin/bash uidNumber: 2002 gidNumber: 3000 homeDirectory: /home/user2 mail: user2(a)example.com uid: user2 sn: user2 structuralObjectClass: inetOrgPerson objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount dn: uid=user3,ou=People,dc=example,dc=com displayName: User 3 cn: User 3 loginShell: /bin/bash uidNumber: 2003 gidNumber: 3000 homeDirectory: /home/user3 mail: user3(a)example.com uid: user3 sn: user3 structuralObjectClass: inetOrgPerson objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount dn: uid=user4,ou=People,dc=example,dc=com displayName: User 4 cn: User 4 loginShell: /bin/bash uidNumber: 2004 gidNumber: 3000 homeDirectory: /home/user4 mail: user4(a)example.com uid: user4 sn: user4 structuralObjectClass: inetOrgPerson objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount dn: uid=user5,ou=People,dc=example,dc=com displayName: User 5 cn: User 5 loginShell: /bin/bash uidNumber: 2005 gidNumber: 3000 homeDirectory: /home/user5 mail: user5(a)example.com uid: user5 sn: user5 structuralObjectClass: inetOrgPerson objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount dn: cn=group1,ou=Groups,dc=example,dc=com cn: group1 gidNumber: 3001 objectClass: groupOfUniqueNames objectClass: top objectClass: posixGroup ou: group1 structuralObjectClass: groupOfUniqueNames uniqueMember: uid=user1,ou=People,dc=example,dc=com uniqueMember: uid=user2,ou=People,dc=example,dc=com dn: cn=group2,ou=Groups,dc=example,dc=com cn: group2 gidNumber: 3002 objectClass: groupOfUniqueNames objectClass: top objectClass: posixGroup ou: group2 structuralObjectClass: groupOfUniqueNames uniqueMember: uid=user3,ou=People,dc=example,dc=com uniqueMember: uid=user4,ou=People,dc=example,dc=com dn: cn=groupingroup,ou=Groups,dc=example,dc=com cn: groupingroup gidNumber: 3003 objectClass: groupOfUniqueNames objectClass: top objectClass: posixGroup ou: groupingroup structuralObjectClass: groupOfUniqueNames uniqueMember: uid=user5,ou=People,dc=example,dc=com uniqueMember: cn=group1,ou=Groups,dc=example,dc=com uniqueMember: cn=group2,ou=Groups,dc=example,dc=com

4 5

inplace modification of objectclasses?
by Ede Wolf 12 Apr '22

12 Apr '22

Hello again, I am wondering, wether it is possible, to replace/overwrite an item without changing its index number, or wether for this case I do have to manually edit the schema.ldif (and thereby ruin the CRC)? Assuming I have this example: olcObjectClasses: {4}( 1.1.1 NAME 'myoc' DESC 'My objectclass' SUP top ABSTRACT MAY ( myAttribute ) ) olcObjectClasses: {5}( 1.1.2 NAME 'myotheroc' DESC 'My other objectclass' SUP myoc STRUCTURAL MUST ( myotherAttribute ) ) So the lower one(5) depends upon the preceeding one (4). Now I would like to modify the first (4) objectclass definition to f.e. MUST (myAttribute). Using ldapmodify the classical way: delete: olcObjectClasses olcObjectClasses: (1.1.1....old) - add: olcObjectClasses olcObjectClasses: (1.1.1....new) does of course not work, as it will get a new, higher index and therefore any subsequential startup of openldap will fail, as our current index 5 has a reference to an objectclass that now however comes later and has an index of f.e. 17. However, I have not been able to figure out, how to use "replace: olcObjectClasses" to only replace a single instance and keep it in place. Therefore I am wondering, is there a way to use ldapmodify, or any other tool, to modify entries without changing the index, that in turn of course would break ldif? Thanks Ede

2 2

ppolicy related migration issues
by Ede Wolf 12 Apr '22

12 Apr '22

Hello I am having issues migrating my configdb from 2.4.57 to 2.6.1. The issue being the ppolicy schema, that upon import claims a duplicate attribute type, that I cannot track down. A recursive grep does not reveal the attribute oid anywhere as duplicate. This happens with a 2.6.0 instance on alpine as well as with 2.6.1 on arch. In addidtion, I can happily import that configdb.ldif into another 2.4.x openldap instance, so I doubt it is corrupt. Coming from a working instance anyway. So I assume, I might have missed some reading, but my search skills did not produce any results. Removing the ppolicy schema part from the config_db.ldif makes the import finish errorfree, but well, but later it is being used. Here is the output of my trying, the oid in question is the "pwdAttribute", but removing just that makes just the next attribute fail. # slapadd -n0 -F /etc/openldap/slapd.d/ -v -l config_db.ldif added: "cn=config" (00000001) added: "cn=module{0},cn=config" (00000001) added: "cn=schema,cn=config" (00000001) added: "cn={0}core,cn=schema,cn=config" (00000001) added: "cn={1}cosine,cn=schema,cn=config" (00000001) added: "cn={2}dyngroup,cn=schema,cn=config" (00000001) added: "cn={3}inetorgperson,cn=schema,cn=config" (00000001) added: "cn={4}nis,cn=schema,cn=config" (00000001) added: "cn={5}openldap,cn=schema,cn=config" (00000001) added: "cn={6}pmi,cn=schema,cn=config" (00000001) olcAttributeTypes: value #0 olcAttributeTypes: Duplicate attributeType: "1.3.6.1.4.1.42.2.27.8.1.1" slapadd: could not add entry dn="cn={7}ppolicy,cn=schema,cn=config" (line=396): olcAttributeTypes: Duplicate attributeType: "1.3.6.1.4.1.42.2.27.8.1.1" Closing DB... The slapd.d directory is of course empty before import. Anything I might have missed? Thanks Ede P.S. Most likely well known, as I have not altered it, but here is the offending part alltogether: dn: cn={7}ppolicy,cn=schema,cn=config objectClass: olcSchemaConfig cn: {7}ppolicy olcAttributeTypes: {0}( 1.3.6.1.4.1.42.2.27.8.1.1 NAME 'pwdAttribute' EQUALI TY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) olcAttributeTypes: {1}( 1.3.6.1.4.1.42.2.27.8.1.2 NAME 'pwdMinAge' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121. 1.27 SINGLE-VALUE ) olcAttributeTypes: {2}( 1.3.6.1.4.1.42.2.27.8.1.3 NAME 'pwdMaxAge' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121. 1.27 SINGLE-VALUE ) olcAttributeTypes: {3}( 1.3.6.1.4.1.42.2.27.8.1.4 NAME 'pwdInHistory' EQUALI TY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.1 21.1.27 SINGLE-VALUE ) olcAttributeTypes: {4}( 1.3.6.1.4.1.42.2.27.8.1.5 NAME 'pwdCheckQuality' EQU ALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.11 5.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {5}( 1.3.6.1.4.1.42.2.27.8.1.6 NAME 'pwdMinLength' EQUALI TY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115. 121.1.27 SINGLE-VALUE ) olcAttributeTypes: {6}( 1.3.6.1.4.1.42.2.27.8.1.7 NAME 'pwdExpireWarning' EQ UALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466. 115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {7}( 1.3.6.1.4.1.42.2.27.8.1.8 NAME 'pwdGraceAuthNLimit' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.146 6.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {8}( 1.3.6.1.4.1.42.2.27.8.1.9 NAME 'pwdLockout' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) olcAttributeTypes: {9}( 1.3.6.1.4.1.42.2.27.8.1.10 NAME 'pwdLockoutDuration' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.14 66.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {10}( 1.3.6.1.4.1.42.2.27.8.1.11 NAME 'pwdMaxFailure' EQU ALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.1 15.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {11}( 1.3.6.1.4.1.42.2.27.8.1.12 NAME 'pwdFailureCountInt erval' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1. 4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {12}( 1.3.6.1.4.1.42.2.27.8.1.13 NAME 'pwdMustChange' EQU ALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) olcAttributeTypes: {13}( 1.3.6.1.4.1.42.2.27.8.1.14 NAME 'pwdAllowUserChange ' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) olcAttributeTypes: {14}( 1.3.6.1.4.1.42.2.27.8.1.15 NAME 'pwdSafeModify' EQU ALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) olcAttributeTypes: {15}( 1.3.6.1.4.1.4754.1.99.1 NAME 'pwdCheckModule' DESC 'Loadable module that instantiates "check_password() function' EQUALITY cas eExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcAttributeTypes: {16}( 1.3.6.1.4.1.42.2.27.8.1.30 NAME 'pwdMaxRecordedFail ure' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4. 1.1466.115.121.1.27 SINGLE-VALUE ) olcObjectClasses: {0}( 1.3.6.1.4.1.4754.2.99.1 NAME 'pwdPolicyChecker' SUP t op AUXILIARY MAY pwdCheckModule ) olcObjectClasses: {1}( 1.3.6.1.4.1.42.2.27.8.2.1 NAME 'pwdPolicy' SUP top AU XILIARY MUST pwdAttribute MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdC heckQuality $ pwdMinLength $ pwdExpireWarning $ pwdGraceAuthNLimit $ pwdLoc kout $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ pwdMu stChange $ pwdAllowUserChange $ pwdSafeModify $ pwdMaxRecordedFailure ) ) structuralObjectClass: olcSchemaConfig

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2022