openldap-technical

openldap-technical@openldap.org

9897 discussions

Symas OpenLDAP for Linux Ubuntu PPA (18 LTS, 20 LTS)
by Quanah Gibson-Mount 09 Dec '20

09 Dec '20

Symas is now producing a PPA for Symas OpenLDAP for Linux on the Ubuntu platform. Packages can be obtained from: <https://launchpad.net/~symas/+archive/ubuntu/sofl/> The PPA build keeps all Ubuntu modifications (such as building nssov, etc). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Changes to CentOS project
by Quanah Gibson-Mount 09 Dec '20

09 Dec '20

In case people missed it, the CentOS project is changing how it operates, and changing the EOL for CentOS8 from 2029 to the end of 2021: <https://blog.centos.org/2020/12/future-is-centos-stream/> Symas plans to continue to produce packages suitable for CentOS7 and CentOS8 until their respective EOLs, and to continue to provide packages for RHEL7 and RHEL8 until their EOLs. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Reset admin pass
by Клеусов Владимир Сергеевич 09 Dec '20

09 Dec '20

Hi. How do I change the admin password correctly and not break replication ? =) here when setting up replication the password was mentioned dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootPW olcRootPW: 123 And dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=001 provider=ldaps://ldap1.domain.com searchbase="cn=config" bindmethod=simple credentials=123 binddn="cn=admin,cn=config" tls_reqcert=never type=refreshAndPersist retry="30 +" timeout=1 olcSyncRepl: rid=002 provider=ldaps://ldap2.domain.com searchbase="cn=config" bindmethod=simple credentials=123 binddn="cn=admin,cn=config" tls_reqcert=never type=refreshAndPersist retry="30 +" timeout=1 tls_reqcert=never type=refreshAndPersist retry="5 5 300 5" timeout=1 - replace: olcMirrorMode olcMirrorMode: TRUE

3 15

objectclass for organizationIdentifier?
by mark 08 Dec '20

08 Dec '20

Hi all, while creating directory entries in OpenLDAP I am struggling with the attribute organizationIdentifier (OID 2.5.4.97). The main problem: there seems to be no standard objectClass that contains this attribute (i.e. not in X.521). This has already been discussed in this thread from 2017: https://www.openldap.org/lists/openldap-technical/201701/msg00075.html. I would like to avoid creating my own custom auxiliary class when possible. Is anybody aware of (or has created) an existing object class for this attribute? - Mark

1 0

Failing "id uid" test
by armin.vehr＠mmlab.de 06 Dec '20

06 Dec '20

Hi ML! I have set up an OpenLDAP server with TLS/SSL support from the repositories. The platform is Debian 10. I followed this guide: https://kifarunix.com/setup-openldap-server-with-ssl-tls-on-debian-10/ Now I want to use the LDAP users on a CentOS 8 client, so I followed this guide in order to set up the LDAP authentication mechanisms: https://kifarunix.com/configure-sssd-for-openldap-authentication-on-centos-… The current state is that I get the following message returned when I try to check an LDAP user's ID on the client system: [root@myldapclient ~]# id testuser id: `testuser´: no such user Obviously sth. is malconfigured. At least enumerating all LDAP objects works on the client. The command ldapsearch -h myldapserver.mycompany.mytld -x -D "cn=readonlybind,dc=mycompany,dc=mytld" -W -LLL -b "dc=mycompany,dc=mytld" returns all of the LDAP's objects. I'd appreciate hints how to track the issue down. First: What is the default LDAP log on Debian 10 or how can I determine an alternative log, if this is recommended? Thank you! __________ Information from mm-lab IT security __________The message was checked by ESET Mail Security.

2 1

sharing transactions across threads
by James Anderson 04 Dec '20

04 Dec '20

the mdb_env_open documentation includes in its note about NOTLS, that A read-only transaction may span threads if the user synchronizes its use. to which read-only operations would this constraint apply? mdb_cursor_open and mdb_cursor_close look as if they modify transaction state for write transactions only. best regards, from berlin

5 11

Other error (80) when adding olcTLSCipherSuite
by Benjamin Schneider 02 Dec '20

02 Dec '20

Hi all, I'm running version 2.4.49 on Ubuntu 20.04. I've been unable to add the olcTLSCipherSuite configuration attribute. # ldapmodify -H ldapi:// -Y EXTERNAL -f set-ciphersuite.ldif returns: SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) set-ciphersuite.ldif contains the following: dn: cn=config changetype: modify add: olcTLSCipherSuite olcTLSCipherSuite: ALL I was able to successfully configure (and confirmed working) TLS by setting the following attributes: olcTLSCACertificateFile: /etc/ssl/certs/mydomain.fullchain.pem olcTLSCertificateFile: /etc/ssl/certs/mydomain.cert.pem olcTLSCertificateKeyFile: /etc/ssl/private/mydomain.privkey.pem and was just looking to limit which ciphers would be offered. I've found several discussions (here, on stackoverflow, etc.) that mention this error, but those discussions concerned these latter TLS attributes (which I had no problem adding) and not the olcTLSCipherSuite attribute. They also pointed to file permissions being the issue for the certificate files, which I've confirmed is not an issue. I would be grateful if anyone could point me in the right direction Ben

2 2

LDAP proxy backend does not drop idle connections
by Tero Saarni 02 Dec '20

02 Dec '20

Hi, I understood from slapd-ldap(5) description of "idle-timeout" that cached connections towards remote LDAP server would be automatically dropped after <time> seconds. Problem: cached connections that are idle do not get dropped. Questions: (1) Is this expected? (2) Are idle connections kept due to limitation in the implementation: when connection is idle, back-ldap does not have a trigger that could be used to drop idle connections? Background: While experimenting with this, it seems that idle timeout is only checked when there is new activity towards the cached connection i.e. connection needs to become active before idle timeout is checked. If the connection just remains idle, nothing will happen. I'm trying to study the timeout handling in back-ldap code, and I believe I found relevant code at the end of ldap_back_getconn() in bind.c. It will eventually trigger unbind and disconnect, but only when new activity happens after the idle period is reached. I did not find other paths that could trigger unbind of cached connection. -- Tero

4 8

HAProxy protocol support?
by Paul B. Henson 01 Dec '20

01 Dec '20

So management is insisting that we migrate our openLDAP systems from on premise into the cloud <sigh>. Specifically, AWS behind one of their load balancers. However, we currently rely upon some level of IP address based access control to distinguish between on-campus and off-campus clients. The Amazon load balancers do client NAT, so the back end servers have no idea who is connecting at the TCP/IP level. They do support the haproxy in band protocol for supplying this information from the load balancer to the server, but that requires specific support from the server to do. I don't see any such support in openldap or any evidence of past discussion regarding it. Is this something that would be considered as a possible feature to be included at some point, or something not desired as part of the code base? Thanks...

8 9

Re: Antw: [EXT] LDAP proxy backend does not drop idle connections
by Ulrich Windl 01 Dec '20

01 Dec '20

>>> Tero Saarni <tero.saarni(a)est.tech> schrieb am 01.12.2020 um 09:20 in Nachricht <HE1P189MB0491BEEEFFF202642C4145A988F40(a)HE1P189MB0491.EURP189.PROD.OUTLOOK.COM>: > Ulrich Windl wrote: >> It may depend on the version, but for us it worked. How did you check that > it doesn't work? > > I have tested by setting up "idassert‑bind" configuration which results in > cached connection. I set idle‑timeout to 5 (seconds). I did packet capture > with Wireshark to see that the connection is still up. OK, I don't know about the allowable range of the timeout and the scale of problem you are having, but we had idle connections that were inactive for days or weeks, so we set the timeout to one day. That worked. Considering that a closed connection may stay around for several seconds, a timeout of 5 seconds seems extremely short to me, however. Regards, Ulrich > > To test I have executed: > > 1. execute search from client > 2. wait for the duration of idle‑timeout to expire > 3. observe from LDAP protocol capture that the connection is still up > > > Secondly I tested: > > 1. execute search from client > 2. wait for the duration of idle‑timeout to expire > 3. execute search from client again > 4. observe that unbind and TCP connection tear down happened immediately > after step 3 > > > I also tested that search before idle timeout extends the timeout: > > 1. execute search from client > 2. execute search from client again before idle‑timeout > 3. observe that nothing happens > 4. execute search after idle‑timeout has passed when measuring the time from > step 2. > 5. observe that unbind and TCP connection tear down happened immediately > after step 4 > > > I also tried to find the function within back‑ldap code that compares the > idle timeout value. This is the only place in the code I found idle timeout > being compared > https://git.openldap.org/openldap/openldap/‑/blob/master/servers/slapd/back… > dap/bind.c#L1133 and it is in function ldap_back_getconn(). I attached gdb > to slapd and breakpoint to the function. Debugger shows that it does not > seem to get called unless there is activity from client to proxy i.e. not > during connection from proxy to remote LDAP remains idle. > > I tested only with recent releases and git master, not with very old > versions since they are bit harder to compile with modern distros. But I > have compared the code from a random historical release. It seems to be the > same as today. > > Quanah also replied "back‑ldap likely needs a task to check for idle > connections" so I'm bit puzzled if this has worked previously. Maybe > ldap_back_getconn() can be called in some other scenario also without having > traffic from client towards the proxy? > > ‑‑ > Tero

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