openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

[LMDB] mdb_env_set_mapsize and read transactions
by Ken Wenzel 01 Feb '22

01 Feb '22

Hello, I like to implement an autogrow functionality for LMDB. The documentation for mdb_env_set_mapsize says that no transactions should be active when using this function. When looking at the code I can see that the function only checks if there is an active WRITE transaction and in this case it returns an error. Is it possible to reuse existing READ transactions or even associated cursors after mdb_env_set_mapsize has been called? Thank you and best regards, Ken

3 4

Minor typo in slapo-ppolicy
by Ulrich Windl 01 Feb '22

01 Feb '22

Hi! I just discovered a minor typo in my version of the slapo-ppolicy manual page (possibly it's fixed alrerady): The manual page lists "pwdGraceAuthnLimit", but the attribute returned by slapcat is "pwdGraceAuthNLimit" (different case for 'N') The name from the schema also is "pwdGraceAuthNLimit". Regards, Ulrich

2 1

Question regarding password dictionary rule in OpenLDAP
by Alan Andrea 01 Feb '22

01 Feb '22

I have a question regarding password rules that are enforced when a user changes their password in OpenLDAP. We have a need to implement a dictionary rule whereby words and phrases in a dictionary are not allowed in a users password. I am not able to see currently where such functionality exists in OpenLDAP and am wondering if there are any extensions to OPenLDAP that were developed to support this or if it would be required to write code to support this feature? Thanks,Alan

3 3

Need to define behaviour when storing pwdChangedTime
by David Coutadeur 31 Jan '22

31 Jan '22

Hi, When doing a backup / restore on my OpenLDAP 2.5.9 instance, I faced a behaviour that I think must be defined explicitely, in draft-behera-ldap-password-policy, or at least in OpenLDAP documentation. My backup contains an entry like this: dn: uid=test,ou=people,ou=branch,dc=example,dc=com cn: test sn: test givenName: test uid: test userPassword: secret pwdChangedTime: 20220110153431Z mail: test(a)domain.com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person There is also a valid default password policy: (which must be defined before the users in the backup file) dn: cn=default,ou=ppolicies,dc=example,dc=com objectClass: pwdPolicy objectClass: pwdPolicyChecker objectClass: organizationalRole cn: default pwdMaxAge: 7776000 pwdAttribute: userPassword pwdCheckQuality: 2 pwdLockout: TRUE pwdMaxFailure: 5 pwdMinLength: 6 pwdMustChange: TRUE pwdCheckModule: /usr/local/openldap/lib64/ppm.so When restoring the backup with this command: ldapadd -x -h '127.0.0.1:389' -D 'cn=Manager,dc=example,dc=com' -w 'secret' -f backup.ldif -e relax I have an error showing that the attribute pwdChangedTime is duplicated and must not be defined twice. I assume that the password policy does not replace my pwdChangedTime value with the current date, but duplicates the attribute. Could you define this behaviour somewhere? 1/ Is it possible to update the pwdChangedTime attribute along with the userPassword ? 2/ If so, what value should be stored? (the given value or the current date?) 3/ Optionally, update OpenLDAP code according to the defined behaviour Thanks in advance for your answer. Regards, David

5 7

How to properly test whether an asynchronous ldap_connect() has fully connected?
by nickpelling＠nickpelling.com 27 Jan '22

27 Jan '22

I'm trying to run OpenLDAP on a Cortex-M7 processor, but to be a "good citizen" my LDAP client code needs to connect asynchronously. (The code connects synchronously fine.) Stripped down to the bare minimum (i.e. no error handling) for clarity here (the actual code has tons of error handling), my asynchronous connection code looks like this: ldap_set_option(pstContext->ld, LDAP_OPT_CONNECT_ASYNC, LDAP_OPT_ON); // Enable async connection ldap_connect(ld); // Do the LDAP connection As you'd expect, the next step is to test (asynchronously) whether the connection has completed, but it can't see any OpenLDAP functionality to do this directly. So here's what my test currently looks like: /** * Determine whether a connection has yet connected * * @param[in] LDAP connection instance to test * * @retval 0 if connection has connected * @retval -2 if connection is still waiting * @return ...otherwise an unexpected problem was encountered */ int ldap_connection_connected(LDAP * ld) { ber_socket_t sd; int iRetVal; iRetVal = -99; // Default to "an unexpected problem was encountered" if (ld->ld_defconn != NULL) { if (ld->ld_defconn->lconn_status == LDAP_CONNST_CONNECTED) { iRetVal = 0; // i.e. the connection has already connected, so exit early! } else { // Get the connection's sockbuffer ber_sockbuf_ctrl( ld->ld_defconn->lconn_sb, LBER_SB_OPT_GET_FD, &sd ); // Check to see if a result has yet been received via this sockbuffer iRetVal = ldap_int_check_async_open( ld, sd ); } } return iRetVal; } However, my bind code (i.e. that executes immediately after this) fails to connect to the server after an asynchronous ldap_connect(), even though it works fine after a synchronous ldap_connect(). Moreover, it looks to me (from the timings) as though my test for asynchronous connection is signalling completion earlier than I'm expecting, so I'm wondering if this is not waiting properly, e.g. if it's returning after the very first message response when it should be waiting for a whole series of message responses to arrive. Am I missing some clever OpenLDAP trick for correctly detecting when asynchronous ldap_connect() calls have fully connected? Thanks!

1 0

mdb_txn_begin() before mdb_dbi_open()
by Sam Dave 25 Jan '22

25 Jan '22

Hello, 1. I create a read-only transaction on an environment with mdb_txn_begin(). 2.Then I get a database handle on the same environment (using mdb_dbi_open() within a separate transaction). 3. Finally I try to create and use a cursor using the database in 2. and transaction in 1. but I get various runtime errors ("Segmentation fault" or "double free or corruption"). However, if I switch 1. and 2., everything works. Must a database really be created before a transaction? If so, curious to learn if this is mentioned anywhere in the docs (I didn't see it) Regards, Sam

2 1

mdb_cursor_close and mdb_txn_close/abort for read-only transactions
by Sam Dave 24 Jan '22

24 Jan '22

Hello, The mdb_cursor_close() documentation says: "Its transaction must still be live if it is a write-transaction." This leads me to my question: For *read-only* transactions, is it allowed to run mdb_cursor_close() *after* mdb_txn_close() or mdb_txn_abort()? Regards, Sam

2 2

Problem with connection on localhost for push replication
by frederic.goudal＠bordeaux-inp.fr 21 Jan '22

21 Jan '22

Hello, I have a strange problem : I have a push replication setup and delta-sync on a 2.6.0 instance. My replication is broken. What I find in the log is the following : slap_client_connect: URI=ldap://localhost DN="uid=ldapsync,ou=people,dc=ipb,dc=fr" ldap_sasl_bind_s failed (-5) than it retries 5 times, and in the log I just find : ldapa2021 slapd[265608]: do_syncrep1: rid=415 starting refresh (sending cookie=rid=415,csn=20130927152219.157851Z#000000#001#000000;20131127140429.597497Z#000000#002#00000\ 0;20141208130549.278599Z#000000#004#000000;20220120073003.212785Z#000000#00a#000000;20220119182551.334341Z#000000#018#000000) ldapa2021 slapd[265608]: conn=1008 op=1 syncprov_op_search: got a persistent search with a cookie=rid=415,csn=20130927152219.157851Z#000000#001#000000;20131127140429.59749\ 7Z#000000#002#000000;20141208130549.278599Z#000000#004#000000;20220120073003.212785Z#000000#00a#000000;20220119182551.334341Z#000000#018#000000 slapd[265608]: do_syncrep2: rid=415 LDAP_RES_SEARCH_RESULT slapd[265608]: do_syncrep2: rid=415 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform ldapa2021 slapd[265608]: do_syncrep2: rid=415 (53) Server is unwilling to perform ldapa2021 slapd[265608]: do_syncrepl: rid=415 rc -101 retrying every five minutes. The problem is that if I do an external ldapsearch with the same bind_dn and the password in the syncrepl definition, the bind is correct. my syncrelpl entry is {0}rid=415 provider=ldap://localhost binddn="uid=ldapsync,ou=people,dc=ipb,dc=fr" bindmethod=simple credentials=****** filter="(objectclass=*)" searchbase="dc=ipb,dc=fr" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 exattrs=hasSubordinates I'm a bit lost... -- Frédéric Goudal DSI Bordeaux-INP 05 56 84 23 11

1 0

2.6.1 with olcTLSVerifyClient=demand fails - TLS accept failure error, error=-1
by patrick+openldap.org＠laimbock.com 21 Jan '22

21 Jan '22

Hi, I'm having trouble getting OpenLDAP 2.6.1 on AlmaLinux 8.5 to work with olcTLSVerifyClient=demand which results in: connection_read(11): TLS accept failure error=-1 id=1001, closing ... conn=1001 fd=11 closed (TLS negotiation failure). With olcTLSVerifyClient=try I get: error unable to get TLS client DN, error 49. I tried various Google suggestions: check certificate permissions, SELinux AVCs (there are none), created CA, server and client certificates with EasyRSA and manually created the same certificates, ran slapd as root and tried with a python-ldap script. [root@ldap1 openldap]# ldapwhoami -d 1 -H ldaps://<FQDN> -x ... connect success TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS read server hello TLS trace: SSL_connect:TLSv1.3 read encrypted extensions TLS trace: SSL_connect:SSLv3/TLS read server certificate request TLS certificate verification: depth: 1, err: 0, subject: /C=NL/O=Example/OU=IT/CN=OpenLDAP-CA, issuer: /C=NL/O=Example/OU=IT/CN=OpenLDAP-CA TLS certificate verification: depth: 0, err: 0, subject: /C=NL/O=Example/OU=IT/CN=<FQDN>, issuer: /C=NL/O=Example/OU=IT/CN=OpenLDAP-CA TLS trace: SSL_connect:SSLv3/TLS read server certificate TLS trace: SSL_connect:TLSv1.3 read server certificate verify TLS trace: SSL_connect:SSLv3/TLS read finished TLS trace: SSL_connect:SSLv3/TLS write change cipher spec TLS trace: SSL_connect:SSLv3/TLS write client certificate TLS trace: SSL_connect:SSLv3/TLS write finished ... TLS trace: SSL3 alert read:fatal:unknown ldap_err2string ldap_result: Can't contact LDAP server (-1) There is only one ldap.conf and it's in /etc/openldap: BASE dc=example,dc=ldap URI ldaps://<FQDN> TLS_CACERT /etc/openldap/certs/openldap-CA.crt TLS_CERT /etc/openldap/certs/ldap-admin.crt TLS_KEY /etc/openldap/certs/ldap-admin.key TLS_REQCERT demand Certificates (slapd runs with -u ldap): [root@ldap1 certs]# ll /etc/openldap/certs total 20 -rw-r--r--. 1 root root 1980 21 jan 15:24 <FQDN>.crt -r--------. 1 ldap root 2484 21 jan 15:24 <FQDN>_nopass.key.crt -rw-r--r--. 1 root root 1984 21 jan 15:24 ldap-admin.crt -r--------. 1 patrick root 2484 21 jan 15:24 ldap-admin_nopass.key.crt -rw-r--r--. 1 root root 1952 21 jan 15:24 openldap-CA.crt dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /run/openldap/slapd.args olcPidFile: /run/openldap/slapd.pid olcPasswordCryptSaltFormat: $6$%s olcLogLevel: -1 olcTLSCACertificateFile: /etc/openldap/certs/openldap-CA.crt olcTLSCertificateFile: /etc/openldap/certs/ldap-server.crt olcTLSCertificateKeyFile: /etc/openldap/certs/ldap-server.key olcTLSDHParamFile: /etc/pki/tls/certs/dhparam2048 olcTLSVerifyClient: demand The certificates are attached (the keys have no password) plus the output of 'openssl x509 -text -noout -in <cert> > <cert>.txt'. The python script test.py that I used is also attached. Thank you for any suggestions how to make this work or where to look. Best, Patrick

2 1

Reason behind "OPENLDAP_2.200" version number for openldap 2.6 version?
by thrivikram.rage＠gmail.com 21 Jan '22

21 Jan '22

Hi There , Is there any reason behind "OPENLDAP_2.200" version number for openldap 2.6 version ? , For earlier versions of "openldap 2.5.7 " the generated file was "OPENLDAP_2.5.7". Thanks, Vikram

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