openldap-technical

openldap-technical@openldap.org

18 participants
9785 discussions

Start a nNew thread

how to identify users or service accounts that have write access
by kalybox2020＠gmail.com 07 May '24

07 May '24

In openldap 2.4, how to identify users or service accounts that have write access. Can we do ldapsearch and find out?

3 3

Not affected: gitlab cve-2023-7028
by Quanah Gibson-Mount 04 May '24

04 May '24

Hello, Community members may be aware of <https://nvd.nist.gov/vuln/detail/CVE-2023-7028> I wanted to note that the OpenLDAP self hosted gitlab instance is not affected by this vulnerability as we regularly update our gitlab instance. Regards, Quanah

1 0

Replication Questions
by BECOT Jérôme 30 Apr '24

30 Apr '24

Hello ! I have few questions regarding replication. I'm doing partial replication on plain replication by limiting the syncrepl user permissions in the ACL. It works well. Is it supported ? Would it work with a delta-sync replication ? Another thing I've been told about is about memberOf overlay. My colleague told me that replication may fail when memberOf is enabled on consumers, mainly because sometimes the group is replicated before the user and memberOf would create an entry if a search is made on the user not yet replicated. Have you some insights about this behaviour that I have not met yet ? Regards

4 4

bindDN massage error
by lsoulas 30 Apr '24

30 Apr '24

Hi, I testing a configuration with rewriteMap option. I have an error bindDN massage error when the rule is redirected. I think who I don't use a good regexp for the rule. My configuration : /defaultsearchbase dc=local,dc=lan database meta suffix "dc=lan" uri "ldaps://192.168.50.2/dc=lan" overlay rwm rwm-rewriteEngine on rwm-rewriteMap ldap attr2dn "ldap://192.168.50.10" rwm-rewriteContext bindDN rwm-rewriteRule "(.*)" "${attr2dn(%1)}" "#"/ For this test, I whish who all request is redirected of the other server. If I viewing a tcp frames, the cn request add a $ in frame: /cn.$user, cn=Users,dc=local,dc=lan/ Thank you for your feedback *Loïc*

1 0

Need information related to multi thread support in OpenLDAP c sdk client
by c.venugopal521＠gmail.com 29 Apr '24

29 Apr '24

Hi Team, We are working on migration of nsldap C sdk to OpenLDAP c sdk for our application client code. As part of this activity, replacing API one by one and also looking for constant replacement. In NSLDAP C SDK: /* * Thread function callbacks (an API extension -- * LDAP_API_FEATURE_X_THREAD_FUNCTIONS). */ #define LDAP_OPT_THREAD_FN_PTRS 0x05 /* 5 - API extension */ /* * Thread callback functions: */ typedef void *(LDAP_C LDAP_CALLBACK LDAP_TF_MUTEX_ALLOC_CALLBACK)( void ); typedef void (LDAP_C LDAP_CALLBACK LDAP_TF_MUTEX_FREE_CALLBACK)( void *m ); typedef int (LDAP_C LDAP_CALLBACK LDAP_TF_MUTEX_LOCK_CALLBACK)( void *m ); typedef int (LDAP_C LDAP_CALLBACK LDAP_TF_MUTEX_UNLOCK_CALLBACK)( void *m ); typedef int (LDAP_C LDAP_CALLBACK LDAP_TF_GET_ERRNO_CALLBACK)( void ); typedef void (LDAP_C LDAP_CALLBACK LDAP_TF_SET_ERRNO_CALLBACK)( int e ); typedef int (LDAP_C LDAP_CALLBACK LDAP_TF_GET_LDERRNO_CALLBACK)( char **matchedp, char **errmsgp, void *arg ); typedef void (LDAP_C LDAP_CALLBACK LDAP_TF_SET_LDERRNO_CALLBACK)( int err, char *matched, char *errmsg, void *arg ); /* * Structure to hold thread function pointers: */ struct ldap_thread_fns { LDAP_TF_MUTEX_ALLOC_CALLBACK *ltf_mutex_alloc; LDAP_TF_MUTEX_FREE_CALLBACK *ltf_mutex_free; LDAP_TF_MUTEX_LOCK_CALLBACK *ltf_mutex_lock; LDAP_TF_MUTEX_UNLOCK_CALLBACK *ltf_mutex_unlock; LDAP_TF_GET_ERRNO_CALLBACK *ltf_get_errno; LDAP_TF_SET_ERRNO_CALLBACK *ltf_set_errno; LDAP_TF_GET_LDERRNO_CALLBACK *ltf_get_lderrno; LDAP_TF_SET_LDERRNO_CALLBACK *ltf_set_lderrno; void *ltf_lderrno_arg; }; nsldap c sdk has thread function pointers option to support multi thread functionality for client programs. In our existing code, we are using 'LDAP_OPT_THREAD_FN_PTRS' option with ldap_set_option API like "Client code usage: ldap_set_option(hLDAP, LDAP_OPT_THREAD_FN_PTRS, &tfns);". Now, we are looking for similar functionality with in OpenLDAP to use it in our client program. Gone through OpenLDAP document and source code, but with my knowledge, did not get any equivalent one. Could you please provide more details on this to achieve equivalent functionality of LDAP_OPT_THREAD_FN_PTRS with OpenLDAP? Thank you Venu

2 1

ldclt ldap performance testing
by Marc 27 Apr '24

27 Apr '24

I am doing some basic testing with ldap with this command. ldclt \ -a 400 \ -H ldap://x.x.x.x:xxxx \ -e bindeach,bindonly,close \ -D "uid=test,dc=me,dc=local" \ -w yyyyyy \ -n 1 I was testing this on two container test environments. Both are running with ~500MB, 1 core. 1. alpine - slapd 2.6.3, mdb still with default slapd.conf ldclt[5594]: Average rate: 12627.00/thr (1262.70/sec), total: 12627 ldclt[5594]: Average rate: 0.00/thr ( 0.00/sec), total: 0 ldclt[5594]: All threads are dead - exit. 2. alpine - slapd 2.6.6, mdb configured with acl's, ssl, modules etc. ldclt[8900]: Average rate: 1495.00/thr ( 149.50/sec), total: 1495 ldclt[8900]: Average rate: 1498.00/thr ( 149.80/sec), total: 1498 ldclt[8900]: Average rate: 1490.00/thr ( 149.00/sec), total: 1490 What should I be expecting from this? It looks like maybe slapd of 1. is not 100% with this 'threads are dead' messages. While slapd of 2. with 150 req/sec is that to be expected normal?

3 5

cache userPassword with bind
by Marc 25 Apr '24

25 Apr '24

I am testing a bit with bind's. With consecutive binds with the same test account I always get 'result not in cache'. How can I get this in cache? access_allowed: result not in cache (userPassword) 6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND dn="uid=test,dc=me,dc=local" method=128 6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in cache (userPassword) 6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to "uid=test,dc=me,dc=local " "userPassword" requested 6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend default auth access granted to "(anonymous)" 6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access granted by read(=rscxd)

3 7

RE26 testing call (2.6.8) #1
by Quanah Gibson-Mount 19 Apr '24

19 Apr '24

This is the first testing call for OpenLDAP 2.6.8. 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.8 Engineering Fixed libldap exit handling with OpenSSL3 again (ITS#9952) Fixed slapd-meta with dynlist (ITS#10164) Fixed slapd-meta binds when proxying internal op (ITS#10165) Added slapo-nestgroup overlay (ITS#10161) Added slapo-memberof 'addcheck' option (ITS#10167) Fixed slapo-accesslog startup initialization (ITS#10170) Fixed slapo-dynlist with abandoned operations (ITS#10044) Build Fixed build with gcc14.x (ITS#10166) Fixed back-perl with clang15 (ITS#10177) Contrib Added slapo-alias contrib module (ITS#10104, ITS#10182) Fixed slapo-autogroup to work with slapo-dynlist (ITS#10185) Documentation Fixed slapo-memberof exattr requirements (ITS#7400) Fixed slapo-memberof is no longer deprecated (ITS#7400) Minor Cleanup ITS#10103 ITS#10171 ITS#10172 ITS#10173 ITS#10179 ITS#10186 ITS#10188 ITS#10193 Regards, Quanah

2 1

timeout and network-timeout values of zero for syncrepl in LAN replication
by Christopher Paul 17 Apr '24

17 Apr '24

Hello OpenLDAP-technical list, I'm curious about community perspectives on a specific LDAP replication timeout and network-timeout settings: Setting "timeout=0" or "network-timeout=0" within a syncrepl/olcSyncrepl definition for replication settings is not the best practice for LAN environments. These parameters, when set to zero, instruct syncrepl to wait indefinitely for connections and replication operations to conclude. Within a LAN context, establishing new connections should ideally occur in less than a second. Delays beyond a couple of seconds should kick in the retry logic. This suggests that a more fitting network-timeout range is between 1 to 5 seconds. Concerning the "timeout" parameter, the ideal range might be between 60 to 120 seconds, to handle operations exceeding a minute, but again, kicking in retry logic if they exceed two minutes. I admit that my stance on the "timeout" setting is tentative, given that search operation duration hinges more on the provider's responsiveness rather than network speed alone. This approach ensures that LDAP replication remains both responsive and resilient, without compromising on efficiency or performance. Thoughts? -- Chris Paul | Rex Consulting |https://www.rexconsulting.net

3 5

TLS init: ca md too weak
by Uwe Sauter 17 Apr '24

17 Apr '24

Hi all, one of my Rocky Linux 8 servers was updated automatically to 2.6.7 this night from the Symas repo. The install script seems to include an automated restart of the service but that failed with: main: TLS init def ctx failed: -1 error:0A00018E:SSL routines::ca md too weak As this is an internal network with a private CA the strength of the CA is of minor relevance. I think the change comes with symas-openssl-libs-3.0.8-1.el8.x86_64… Can anyone suggest a workaround (other than exchanging the CA and its issued certificates)? Thanks, Uwe

3 3

← Newer
1
...
8
9
10
11
12
13
14
...
979
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical