openldap-technical

openldap-technical@openldap.org

9851 discussions

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

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

11 Apr '22

--On Monday, April 11, 2022 5:00 PM +0000 Dean Lewis <deanlewis(a)thomas-march.com> wrote: > > Thanks, that sounds like an easier method but I'm running 2.4.47 > unfortunately. I would strongly advise upgrading to OpenLDAP 2.5 or later and using remoteauth for this. Regards, Quanah

1 0

SASL Authentication Pass-through
by t04s＠thomas-march.com 10 Apr '22

10 Apr '22

Hi, Hopefully someone can help. I'm trying to get SASL passthrough working in OpenLDAP to Active Directory. AD is the primary directory but I need Linux users to be able to authenticate to AD (via OpenLDAP) such that they don't have to manage multiple passwords. However, I've set things up as per various guidance (here<https://www.openldap.com/doc/admin21/sasl.html>, here<https://archive.camratus.com/2017/01/24/openldap-lsc-active-directory-sync-…>, here<https://www.ltb-project.org/documentation/sasl_delegation.html> and here<https://www.hellovinoth.com/pass-through-openldap-authentication-using-sasl…>) and it doesn't seem to work for me on Debian 10. After configuring everything I can run the following successfully: ldapsearch -x -H ldap://server.company.com:389 -D cn=ldapbind,cn=Users,DC=company,DC=com -w examplebindpassword -b '' -s base ldapsearch -x -H ldap://server.company.com:389 -D cn=ldapbind,cn=Users,DC=company,DC=com -w examplebindpassword -b "OU=Users,OU=IT,OU=Departments,OU=Group,DC=company,DC=com" "(userPrincipalName=testuser(a)company.com)" ldapsearch -x -H ldap://server.company.com:389 -D "CN=Test User,OU=Users,OU=IT,OU=Departments,OU=Group,DC=company,DC=com" -w exampleuserpassword -b "CN=Test User,OU=Users,OU=IT,OU=Departments,OU=Group,DC=company,DC=com" -s base "(objectclass=*)" These all return the correct results from Active Directory, so this works fine. Finally, I can run: sudo testsaslauthd -u testuser(a)company.com<mailto:grahambrooke@thomas-march.com> -p exampleuserpassword and I get: 0: OK "Success." So finally I create the same user in local OpenLDAP as Test User and add the password as {SASL}testuser(a)company.com<mailto:{SASL}testuser@thomas-march.com> and try to test pass-through authentication to AD: ldapsearch -x -H ldap://localhost -b dc=testing-prod,dc=com -D uid=testuser,ou=users,dc=testing-prod,dc=com -w exampleuserpassword But this doesn't work. I get the error: ldap_bind: Invalid credentials (49) So SASL passthrough just isn't working and it isn't reading the password attribute as such because if I do: ldapsearch -x -H ldap://localhost -b dc=testing-prod,dc=com -D uid=testuser,ou=users,dc=testing-prod,dc=com -w {SASL}testuser(a)company.com This returns the local LDAP user. So it's reading the password literally as a password instead of interpreting it as SASL passthrough to AD. Have I missed some steps here? What am I missing? I have checked that --enable-spasswd has been compiled in by running ldd /usr/sbin/slapd: linux-vdso.so.1 (0x00007ffcbd7b8000) libldap_r-2.4.so.2 => /lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f3e72bc2000) liblber-2.4.so.2 => /lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f3e72bb1000) libdb-5.3.so => /lib/x86_64-linux-gnu/libdb-5.3.so (0x00007f3e729f5000) libodbc.so.2 => /lib/x86_64-linux-gnu/libodbc.so.2 (0x00007f3e72785000) libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f3e72768000) libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f3e725bb000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f3e7257f000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f3e72565000) libslapi-2.4.so.2 => /lib/x86_64-linux-gnu/libslapi-2.4.so.2 (0x00007f3e72543000) libltdl.so.7 => /lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f3e72538000) libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f3e7252c000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3e7250b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3e72349000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3e72344000) libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f3e72215000) libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f3e721f6000) libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f3e72072000) libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f3e71e5f000) libnettle.so.6 => /lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f3e71e25000) libhogweed.so.4 => /lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007f3e71dec000) libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f3e71d69000) /lib64/ld-linux-x86-64.so.2 (0x00007f3e72dac000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f3e71d50000) libffi.so.6 => /lib/x86_64-linux-gnu/libffi.so.6 (0x00007f3e71d46000) I can see libsasl2.so.2 there so I think that's fine. And, I've also run both saslauthd and slapd in debug mode but I get no useful output that I can see. It looks like saslauthd and slapd just aren't talking. Any help or pointers are really appreciated. t04s /---

2 1

Official way to import schema with cn=config
by David Timber 05 Apr '22

05 Apr '22

I had to write my own schema for my application and I was struggling to figure out how to import the schema I wrote to cn=config. I had though I was missing something until I found this. https://gist.github.com/jaseg/8577024 Notice the name of the script. Someone had to write this because there's no tool that you can use to import schemas when the slapd is configured with cn=config. You can get away with it by using include directive with slapd.conf. I know there's a way to do it with slaptest, but that method is just unacceptable. So, how I understood is, either you have to use slaptest to rebuild the entirety of the schema in ldif format, or you have to handcraft the schema in ldif by figuring out with {} index to start with. This is all backwards. slapadd and slapmodify are just cranky tools you can only use in specific cases(eg: restoring from mdb_copy backup data). In most cases, using those tools to manipulate cn=config is near impossible. I like the idea behind cn=config, but I believe that calling slapd.conf deprecated is just unfair with problems like these. Is there a set date/version for the drop of support for slapd.conf? I'd like to stick with slapd.conf if it's not going to happen in like 5 years time.

8 23

STARTTLS vs LDAPS
by thomaswilliampritchard＠gmail.com 01 Apr '22

01 Apr '22

At risk of beating a dead horse, I'd like to hear considerations on STARTTLS vs LDAPS. I'm also particularly interested if openldap plans to support LDAPS long term or if there's actually a deprecation effort going on around LDAPS where it would one day no longer be supported by openldap. This seems to be the most comprehensive post discussing the virtue of the two. https://security.stackexchange.com/questions/257749/is-ldaps-or-starttls-mo… I also found a post in this Archive from 2018 that seems to indicate a change of opinion where LDAPS should be preferred, and not deprecated. https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… Does openldap agree that LDAPS should now be the preferred implementation and STARTLS should be discouraged? I do not have a security background and there is certainly a lot of room for me to misunderstand, but it seems like STARTTLS leaves the door open for a "tls downgrade attack" where a man in the middle could essentially reply to a client effectively saying start tls is not supported and then the client falls back to non tls communication (which is obviously unfortunate). Even if the backend server is properly not responding to clients until STARTTLS is initiated, the man in the middle could initiate a connection with STARTTLS to the ldap server and be talking plaintext to the client. Is that legitimately possible or am I missing a nuance? If one were to only support clients over LDAPS it seems this would be mitigated? Thanks for the considerations, looking forward to hearing the expert opinions on the topic.

9 20

delete glue entry
by Michael Ströder 01 Apr '22

01 Apr '22

HI! Had a MDB database with a glue entry in it on all replicas in a multi-provider setup (release 2.6.1). I could not update this entry anymore. Is it possible to delete a glue entry via LDAP? All subordinate entries were already removed before. Ciao, Michael.

2 1

RE26 testing call #1 (OpenLDAP 2.6.2)
by Quanah Gibson-Mount 01 Apr '22

01 Apr '22

This is the first testing call for OpenLDAP 2.6.2. Depending on the results, this may be the only testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.6.2 Engineering Added libldap support for OpenSSL 3.0 (ITS#9436) Added slapd support for OpenSSL 3.0 (ITS#9436) Fixed ldapdelete to prune LDAP subentries (ITS#9737) Fixed libldap to drop connection when non-LDAP data is received (ITS#9803) Fixed libldap to allow newlines at end of included file (ITS#9811) Fixed slapd slaptest conversion of olcLastBind (ITS#9808) Fixed slapd to correctly init global_host earlier (ITS#9787) Fixed slapd bconfig locking for cn=config replication (ITS#9584) Fixed slapd usage of thread local counters (ITS#9789) Fixed slapd to clear runqueue task correctly (ITS#9785) Fixed slapd syncrepl handling of new sessions (ITS#9584) Fixed slapd to clear connections on bind (ITS#9799) Fixed slapd syncrepl ODSEE replication of unknown attr (ITS#9801) Fixed slapd-asyncmeta memory leak in keepalive setting (ITS#9802) Fixed slapd-ldap memory leak in keepalive setting (ITS#9802) Fixed slapd-meta SEGV on config rewrite (ITS#9802) Fixed slapd-meta ordering on config rewrite (ITS#9802) Fixed slapd-meta memory leak in keepalive setting (ITS#9802) Fixed slapd-monitor SEGV on shutdown (ITS#9809) Added slapo-autoca support for OpenSSL 3.0 (ITS#9436) Added slapo-otp support for OpenSSL 3.0 (ITS#9436) Fixed slapo-pcache SEGV on shutdown (ITS#9809) Fixed slapo-ppolicy operation handling to be consistent (ITS#9794) Build Enviornment Add ability to override default compile time paths (ITS#9675) Fix compiliation with certain versions of gcc (ITS#9790) Fix compilation with openssl exclusions (ITS#9791) Fix warnings from make jobserver (ITS#9788) Documentation admin26 Document new lloadd features (ITS#9780) Fixed slapd.conf(5)/slapd-config(5) syncrepl sizelimit/timelimit documentation (ITS#9804) Fixed slapd-sock(5) to clarify "sockresps result" behavior (ITS#8255) Regards, Quanah

6 9

RE25 Testing call #1 (OpenLDAP 2.5.12)
by Quanah Gibson-Mount 01 Apr '22

01 Apr '22

This is the first testing call for OpenLDAP 2.5.12. Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.5.12 Engineering Fixed libldap to drop connection when non-LDAP data is received (ITS#9803) Fixed libldap to allow newlines at end of included file (ITS#9811) Fixed slapd slaptest conversion of olcLastBind (ITS#9808) Fixed slapd usage of thread local counters (ITS#9789) Fixed slapd to clear runqueue task correctly (ITS#9785) Fixed slapd bconfig locking for cn=config replication (ITS#9584) Fixed slapd syncrepl handling of new sessions (ITS#9584) Fixed slapd to clear connections on bind (ITS#9799) Fixed slapd syncrepl ODSEE replication of unknown attr (ITS#9801) Fixed slapd-asyncmeta memory leak in keepalive setting (ITS#9802) Fixed slapd-ldap memory leak in keepalive setting (ITS#9802) Fixed slapd-meta SEGV on config rewrite (ITS#9802) Fixed slapd-meta ordering on config rewrite (ITS#9802) Fixed slapd-meta memory leak in keepalive setting (ITS#9802) Fixed slapd-monitor SEGV on shutdown (ITS#9809) Fixed slapo-pcache SEGV on shutdown (ITS#9809) Fixed slapo-ppolicy operation handling to be consistent (ITS#9794) Build Environment Fix compilation with openssl exclusions (ITS#9791) Fix warnings from make jobserver (ITS#9788) Fix compiliation with certain versions of gcc (ITS#9790) Documentation Fixed slapd.conf(5)/slapd-config(5) syncrepl sizelimit/timelimit documentation (ITS#9804) Regards, Quanah

2 1

Re: STARTTLS vs LDAPS
by Braiam 31 Mar '22

31 Mar '22

On Thu, Mar 31, 2022 at 11:46 AM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, March 31, 2022 12:16 PM -0400 Braiam <braiamp(a)gmail.com> > wrote: > > > What would be the process to modify content on the openldap.org page? > > Depends on the content. The main web pages are in the OpenLDAP Web git > repository. > This repository seems to be the FAQ: https://git.openldap.org/project/faq/-/tree/master/data/item There's a website project too. I couldn't figure out what markup language items on the faq project uses. > --Quanah > -- Braiam

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