openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

Re: no contextCSN attribute on consumers
by cYuSeDfZfb cYuSeDfZfb 12 Jun '23

12 Jun '23

Op 12-06-2023 om 17:29 schreef Quanah Gibson-Mount: > It appears you are using the historic back-hdb or back-bdb backend to > OpenLDAP. These backends are particularly susceptible to corruption. > You should migrate to using the supported backend (back-mdb). You > should also upgrade to a supported release series (2.5 or 2.6) as 2.4 > hasn't been supported for a few years. Yes we are in the middle of migrating. :-) The old structure still uses bdb, yes. While working on new (RHEL9) servers with symas-repo 2.5 openldap, things started happening with the 'old' (but still production) ldap. Thank you very much for your insights! Kind regards!

1 0

Re: no contextCSN attribute on consumers
by cYuSeDfZfb cYuSeDfZfb 12 Jun '23

12 Jun '23

Hi Quanah, Thanks for the swift reponse! I think I do, yes, see, from consumer one: olcSyncrepl: {0}rid=202 provider=ldap://master-acc-02.ldap.infra.com:389 bindmethod=simple filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" starttls=critical tls_reqcert=demand olcSyncrepl: {1}rid=201 provider=ldap://master-acc-01.ldap.infra.com:389 bindmethod=simple filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" starttls=critical tls_reqcert=demand olcUpdateRef: ldap://provider-acc-02.ldap.infra.com:389 olcUpdateRef: ldap://provider-acc-01.ldap.infra.com:389 And the second consumer looks similar. Thanks again! On Mon, 12 Jun 2023 at 15:56, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > > --On Monday, June 12, 2023 3:23 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > Is there any explanation, why I would be unable to obtain these > > contextCSN attributes through an ldapsearch? > > Do you have the syncprov overlay instantiated on the database on the > consumers? > > --Quanah > > > >

2 1

no contextCSN attribute on consumers
by cYuSeDfZfb cYuSeDfZfb 12 Jun '23

12 Jun '23

Hi, We have a 4-machine setup with two providers (replicating between each other) and two consumers (for client access) that both replicate from both providers, type=refreshAndPersist I'm trying to write a script to monitor replication, using the contextCSN attribute. ldapsearch on the providers gives the expected the contextCSN attributes: contextCSN: 20230612115901.693614Z#000000#001#000000 contextCSN: 20230612115904.937471Z#000000#002#000000 However, the same ldapsearch on the consumers gives *no* contextCSN attributes *at all*. But when using slapcat to check directly on the consumers databases, we *can* see the attributes, and they are also up-to-date: contextCSN: 20230612115801.572594Z#000000#001#000000 contextCSN: 20230612115804.594419Z#000000#002#000000 Is there any explanation, why I would be unable to obtain these contextCSN attributes through an ldapsearch? This is RHEL7.9, with openldap 2.4.44 Thanks!

2 1

back-ldap proxy doesn't forward response from upstream server
by Sven Feyerabend 12 Jun '23

12 Jun '23

Hello everyone, I have set up two slapd instances in mirror mode. As described in the documentation I used another slapd instance with ldap backend to proxy the requests and provide failover capabilities in case one of the upstream servers becomes unavailable. Now I have the curious situation, that the proxy correctly forwards the search request from a client to the upstream server but doesn't return the result. I can see in the log that the upstream server responds with one entry: SEARCH RESULT tag=101 err=0 qtime=0.000034 etime=0.001134 nentries=1 The proxy however does not forward this result to the client: SEARCH RESULT tag=101 err=0 qtime=0.000034 etime=0.001730 nentries=0 The client (ldapsearch for test purposes) then gives me the following result: # search result search: 2 result: 0 Success I don't understand what I did wrong. I imported the correct schema into the proxy instance, my config of the ldap backend on the proxy is as follows: # {2}ldap, config dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLdapConfig olcDatabase: {2}ldap olcSuffix: ROOT_SUFFIX_OF_UPSTREAM_DIRECTORY olcDbURI: ldap://openldap-test-0.ldap-test:1389,ldap://openldap-test-1.ldap-test:1389 Does anyone know how to solve this? Some help would be appreciated greatly. Thanks in advance and kind regards Sven

2 1

"pwdHistory" Attribute Is Not Getting Deleted
by Nagesh Nikavade (EXT-NSB) 12 Jun '23

12 Jun '23

Hello Team, We have upgraded from openldap2.4.52 to openldap2.6.2 in our system. With new openldap2.6.2 version, "pwdHistory" attribute isn't being deleted. I have executed the below command: ldapmodify -x -y /opt/Nokia_BP/etc/ldapfiles/fssecldap.ldaproot -D uid=fsLDAPRoot,ou=People,fsFragmentId=Security,fsClusterId=ClusterRoot >/dev/null<<EOF dn: uid=Nemuadmin,ou=People,fsFragmentId=Security,fsClusterId=ClusterRoot changetype: modify delete: pwdHistory EOF I was able to delete "pwdHistory" in old openldap2.4.52 with the same command. Anything got changed regarding this(pwdHistory) in new openldap2.6.2 ? Or is there any other way to delete the "pwdHistory". Thanks in advance. Best Regards, Nagesh

2 1

mdb_txn_abort() thread
by Sam Dave 08 Jun '23

08 Jun '23

Hi, The documentation for mdb_txn_begin() says "A transaction and its cursors must only be used by a single thread, and a thread may only have a single transaction at a time.". Does this also hold for mdb_txn_abort() for read-write transactions? I.e. does the abort also have to happen on the same OS thread as all the previous things (begin, put, etc.)? - Samuel

2 9

argon2 as builtin module?
by Geert Hendrickx 02 Jun '23

02 Jun '23

Hi I was wondering why the argon2 password module can only be built as a dynamic module, and not statically into the slapd binary, like other backends and overlays can be. That would for example make it easier to use slappasswd -h {ARGON2} without having to specify -o module-load=argon2 and module-path etc. Is it because you want to avoid link dependencies on 3rd party libsodium or libargon2 directly in slapd (and slappasswd) itself? Or just because it was previously a contrib module, and just copied over like that? By the way, while looking at the code, I noticed a typo in configure.ac: > if test "$ol_enable_argon2" = "yes" ; then > SLAPD_DYNAMIC_PWMODS="$SLAPD_DYNAMIC_PWDMODS argon2.la" > fi ^^ ^^^ It's referencing two different variables there, which is harmless today, but will be a build bug once multiple password modules become available. SLAPD_DYNAMIC_PWMODS is the correct one. Geert

2 1

Only view exact match on ACL
by Lukas Adrian Kron 24 May '23

24 May '23

Hello, I would like to restrict bind users in the search. I've already managed that they only see groups for which you have been activated. Now I have the problem that bind users should only see users in the people branch if they know the exact user name in the search. So far I have solved the whole thing using the following two ACL sets. You can now also search for people. Since I had to include objectClass for the search to work, you can search for all people or for other values. However, I want all the data I specify to be displayed, but only if the username returns an exact result. I am at the end of my knowledge with the ACL sets. All the Info on ACL cannot help me further here. {5} to dn.exact="ou=Personen,dc=SERVER" by group.exact="GROUP" search by * break {6} to dn.one="ou=Personen,dc=SERVER" attrs=entry,cn,objectClass,givenname,uid,mail,sn,userPassword by group.exact="GROUP" read by * break Thanks a lot. Kindly Lukas Adrian

1 0

SSL timeout
by Robert T Dunn 23 May '23

23 May '23

We are experiencing a problem with SSL timeout as reported with issue 8047: https://bugs.openldap.org/show_bug.cgi?id=8047 Our issue is when the LDAP client does an SSL connect to establish the TLS session with the remote server. If the SERVER_HELLO returned from the remote server takes a significant amount of time or does not come back from the server at all (for example, someone unplugged the server), the LDAP client connection DOES NOT timeout, and there are no LDAP configuration options to force the session to timeout. So, the LDAP client connection is effectively hung forever. Issue 8047 reported the SSL timeout issue, but the issue's status is still UNCONFIRMED. Are there any plans to correct this problem in future versions of LDAP Client? Thanks, Rob Dunn IBM z/TPFDF development email: strmbrgr(a)us.ibm.com<mailto:strmbrgr@us.ibm.com> phone: (845) 433-1312

3 3

DIT changes approval
by sysadm+ldap-technical＠rolep.work 23 May '23

23 May '23

Hello, Is there any way to approve (past or future) DIT changes by more than one people? OpeLDAP has ACL sets, I know. But I don't understand, how (or even can I) to use it forr approve changes in (part of) DIT by two or more people (must not singly, but whole set of people).

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical