openldap-technical

openldap-technical@openldap.org

8 participants
9792 discussions

Question regarding password dictionary rule in OpenLDAP
by Alan Andrea 31 Jan '22

31 Jan '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

OpenLDAP 2.6.1 testing call #1 (OpenLDAP 2.6.1)
by Quanah Gibson-Mount 20 Jan '22

20 Jan '22

This is the first testing call for OpenLDAP 2.6.1. 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. We are aware of two issues with the regression suite tests failing (its4448 and its8752), so no need to report failures for those. Thanks! OpenLDAP 2.6.1 Engineering Fixed libldap to init client socket port (ITS#9743) Added slapd config keyword for logfile format (ITS#9745) Fixed slapd to allow objectClass edits with no net change (ITS#9772) Fixed slapd configtable population (ITS#9576) Fixed slapd to only set loglevel in server mode (ITS#9715) Fixed slapd logfile-rotate use of uninitialized variable (ITS#9730) Fixed slapd passwd scheme handling with slapd.conf (ITS#9750) Fixed slapd postread support for modrdn (ITS#7080) Fixed slapd syncrepl recreation of deleted entries (ITS#9282) Fixed slapd syncrepl replication with ODSEE (ITS#9707) Fixed slapd syncrepl to properly replicate glue entries (ITS#9647) Fixed slapd syncrepl to reject REFRESH for precise resync (ITS#9742) Fixed slapd syncrepl to avoid busy loop during refresh (ITS#9584) Fixed slapd syncrepl when X-ORDERED is specified (ITS#9761) Fixed slapd syncrepl to better handle out of order delete ops (ITS#9751) Fixed slapd syncrepl to correctly close connections when config is deleted (ITS#9776) Fixed slapd-mdb to update indices correctly on replace ops (ITS#9753) Fixed slapd-wt to set correct flags (ITS#9760) Fixed slapo-accesslog to fix assertion due to deprecated code (ITS#9738) Fixed slapo-accesslog to fix inconsistently normalized minCSN (ITS#9752) Fixed slapo-accesslog delete handling of multi-valued config attrs (ITS#9493) Fixed slapo-autogroup to maintain values in insertion order (ITS#9766) Fixed slapo-constraint to maintain values in insertion order (ITS#9770) Fixed slapo-dyngroup to maintain values in insertion order (ITS#9762) Fixed slapo-dynlist compare operation for static groups (ITS#9747) Fixed slapo-dynlist static group filter with multiple members (ITS#9779) Fixed slapo-ppolicy when not built modularly (ITS#9733) Fixed slapo-refint to maintain values in insertion order (ITS#9763) Fixed slapo-retcode to honor requested insert position (ITS#9759) Fixed slapo-sock cn=config support (ITS#9758) Fixed slapo-syncprov memory leak (ITS#8039) Fixed slapo-syncprov to generate a more accurate accesslog query (ITS#9756) Fixed slapo-syncprov to allow empty DB to host persistent syncrepl connections (ITS#9691) Fixed slapo-syncprov to consider all deletes for sycnInfo messages (ITS#5972) Fixed slapo-translucent to warn on invalid config (ITS#9768) Fixed slapo-unique to warn on invalid config (ITS#9767) Fixed slapo-valsort to maintain values in insertion order (ITS#9764) Build Environment Fix test022 to preserve DELAY search output (ITS#9718) Fix slapd-watcher to allow startup when servers are down (ITS#9727) Contrib Fixed slapo-lastbind to work with 2.6 lastbind-precision configuration (ITS#9725) Documentation Fixed slapd.conf(5)/slapd-config(5) documentation on lastbind-precision (ITS#9728) Fixed slapo-accesslog(5) to clarify logoldattr usage (ITS#9749) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 3

CRL refresh in OpenLDAP
by Xabier Berasategui Cano 19 Jan '22

19 Jan '22

Hi, We have an application that uses a client certificate to authenticate to OpenLDAP server 2.4.46 at SSL/TLS level. Among other things, olcTLSCRLCheck directive is configured to "peer" value to verify if the client certificate has not been revoked and the CRL is updated every day via script and expires after 15 days. Everything works well until the 15 days are exceeded and the authentication of the application fails since the server has not been restarted to refresh the CRL. Is there a way to refresh the CRL without restarting the server? Thanks in advance Regards P Please consider the environment before printing this e-mail.

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