openldap-technical October 2023

openldap-technical@openldap.org

30 participants
28 discussions

We cannot connect to TLS/SSL ldaps using openldap's built-in tools
by 228844797＠qq.com 23 Oct '23

23 Oct '23

Hello developers, Can you help me see how to solve this problem We are working with the client that comes with openldap and cannot connect to TLS/SSL ldaps,But I was able to access it using ldap:389 The server configuration information is as follows: Linux System version：Ubuntu 22.04.3 LTS OpenLDAP version：2.6.6 openssl version：OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022) The slapd.ldif certificate is configured as follows: olcTLSCACertificateFile: /usr/local/openldap-2.6.6/cert/demoCA/newcerts/cacert.pem olcTLSCertificateFile: /usr/local/openldap-2.6.6/cert/demoCA/newcerts/slapd01-server.pem olcTLSCertificateKeyFile: /usr/local/openldap-2.6.6/cert/demoCA/private/slapd01-server-key.pem The server startup information is as follows: slapd -4 -F /usr/local/openldap-2.6.6/etc/openldap/slapd.d -h ldap:/// ldaps:/// ldapi:/// Configure the ldap.conf certificate on the client as follows: TLS_CACERT /usr/local/openldap-2.6.6/cert/demoCA/newcerts/ ####################################################################################################### Server local test failed: ldapwhoami -H ldaps://slapd.zxactions.com -d 1 The failure information is as follows: root@openldap-1:/usr/local/openldap-2.6.6/etc/openldap# ldapwhoami -H ldaps://slapd.zxactions.com -d 1 ldap_url_parse_ext(ldaps://slapd.zxactions.com) ldap_create ldap_url_parse_ext(ldaps://slapd.zxactions.com:636/??base) ldap_pvt_sasl_getmech ldap_search put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP slapd.zxactions.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.174.128:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL3 alert read:fatal:handshake failure TLS trace: SSL_connect:error in error TLS: can't connect: error:0A000410:SSL routines::sslv3 alert handshake failure. ldap_err2string ldap_sasl_interactive_bind: Can't contact LDAP server (-1) additional info: error:0A000410:SSL routines::sslv3 alert handshake failure ####################################################################################################### Failed to use the openssl tool: openssl s_client -connect slapd.zxactions.com:636 -debug The failure information is as follows: root@openldap-1:/usr/local/openldap-2.6.6/etc/openldap# openssl s_client -connect slapd.zxactions.com:636 -debug CONNECTED(00000003) write to 0x556ccbdb5c40 [0x556ccbdc5b30] (321 bytes => 321 (0x141)) 0000 - 16 03 01 01 3c 01 00 01-38 03 03 1a eb eb eb ad ....<...8....... 0010 - 52 f0 12 36 b2 cd ad 9c-6f c9 de 67 54 13 e3 47 R..6....o..gT..G 0020 - 23 ac 44 5c d9 51 2f d4-a5 0b cf 20 e6 f9 c1 6c #.D\.Q/.... ...l 0030 - e5 ce 18 9c ea f1 d6 67-a2 1f 71 3c 78 d4 c6 fb .......g..q<x... 0040 - 25 23 98 bd 38 90 1f 8c-13 94 b1 00 00 3e 13 02 %#..8........>.. 0050 - 13 03 13 01 c0 2c c0 30-00 9f cc a9 cc a8 cc aa .....,.0........ 0060 - c0 2b c0 2f 00 9e c0 24-c0 28 00 6b c0 23 c0 27 .+./...$.(.k.#.' 0070 - 00 67 c0 0a c0 14 00 39-c0 09 c0 13 00 33 00 9d .g.....9.....3.. 0080 - 00 9c 00 3d 00 3c 00 35-00 2f 00 ff 01 00 00 b1 ...=.<.5./...... 0090 - 00 00 00 18 00 16 00 00-13 73 6c 61 70 64 2e 7a .........slapd.z 00a0 - 78 61 63 74 69 6f 6e 73-2e 63 6f 6d 00 0b 00 04 xactions.com.... 00b0 - 03 00 01 02 00 0a 00 16-00 14 00 1d 00 17 00 1e ................ 00c0 - 00 19 00 18 01 00 01 01-01 02 01 03 01 04 00 23 ...............# 00d0 - 00 00 00 16 00 00 00 17-00 00 00 0d 00 2a 00 28 .............*.( 00e0 - 04 03 05 03 06 03 08 07-08 08 08 09 08 0a 08 0b ................ 00f0 - 08 04 08 05 08 06 04 01-05 01 06 01 03 03 03 01 ................ 0100 - 03 02 04 02 05 02 06 02-00 2b 00 05 04 03 04 03 .........+...... 0110 - 03 00 2d 00 02 01 01 00-33 00 26 00 24 00 1d 00 ..-.....3.&.$... 0120 - 20 92 75 81 9c 09 28 95-68 b4 eb b1 9e 2c d5 9b .u...(.h....,.. 0130 - e3 99 13 36 68 87 b5 72-4d d6 3e 60 0f 47 50 db ...6h..rM.>`.GP. 0140 - 15 . read from 0x556ccbdb5c40 [0x556ccbdbc913] (5 bytes => 5 (0x5)) 0000 - 15 03 03 00 02 ..... read from 0x556ccbdb5c40 [0x556ccbdbc918] (2 bytes => 2 (0x2)) 0000 - 02 28 .( 800B77514E7F0000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1584:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 321 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- read from 0x556ccbdb5c40 [0x556ccbd0d650] (8192 bytes => 0) ************************************************************************************************************************************* I can access it using ldap:389 root@openldap-1:/usr/local/openldap-2.6.6/etc/openldap# ldapsearch -x -D "cn=Manager,dc=my-domain,dc=com" -H ldap://slapd.zxactions.com -w 123456 -b "dc=my-domain,dc=com" -d 256 # extended LDIF # # LDAPv3 # base <dc=my-domain,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # my-domain.com dn: dc=my-domain,dc=com dc: my-domain o: www.zxactions.com objectClass: dcObject objectClass: organization # copy of my-domain, my-domain.com dn: ou=copy of my-domain,dc=my-domain,dc=com ou: copy of my-domain objectClass: top objectClass: organizationalUnit # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2

3 3

Openldap version / behavior wih duplicates
by maudez.eric＠neuf.fr 23 Oct '23

23 Oct '23

Hello, I notice a different behavior between versions OpenLDAP 2.4 and OpenLDAP 2.6 for synchronization management and duplicates. In the version OpenLDAP 2.4, there is no error when duplicates are found (different branch in openldap) during synchronizations (syncrepl) With version OpenLDAP 2.6, synchronizations are in error Do you know why?

2 3

ldap proxy, attribute rwm
by Krisztián Gáhor 17 Oct '23

17 Oct '23

I created an LDAP proxy using an LDAP backend to connect to our Active Directory server. Unfortunately, our AD server has incorrect usernames in the sAMAccountName attribute, so I would like to override this with the prefix of the value found in the userPrincipalName attribute (the part before @domain). Is this possible at all? Unfortunately, I haven't succeeded in doing this so far.

1 0

Key/value chunk sizes / alignment?
by Sam Dave 14 Oct '23

14 Oct '23

Hello, I have two LMDB databases, identical except one has key size 34 bytes and the other key size 33 bytes. (Both have same value sizes and same number of pairs). How can the file sizes on disk be exactly the same? Is this because of the 2-byte alignment mentioned here? https://github.com/AltSysrq/lmdb-zero/issues/8 I wonder if this 2-byte alignment was documented anywhere. This doesn't bother me btw. I was just expecting the file sizes to differ (got scared I had a bug in my program until I did an mdb_dump to see the real difference) Thanks, Samuel

2 2

Trying to create master/slave solution with syncrepl
by Christoph Pleger 13 Oct '23

13 Oct '23

Hello, I am trying to create an OpenLDAP master/slave solution with syncrepl, but I have not been successful so far. I followed the suggestions of this site, with another sync password: https://www.itzgeek.com/how-tos/linux/configure-openldap-master-slave-repli… One thing I made different, on the master server, I created the replication user with a userPassword: in SSHA-Format instead of clear text. Additionally, I set, following the suggestion of another website: olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq Now, I can see with tcpdump that the slave server contacts the master server and that the master server send replies, but no LDAP users are synchronized to the slave. Unfortunately, nothing about replication is logged to syslog, though I started slapd on both master and slave with options "-s Sync -c rid=001". Any idea what is wrong or how I can at least get some debgging output about what is happening on master and slave, related to replication? Regards Christoph

4 6

contextCSN via slapcat outdated, despite having set syncprov-checkpoint
by cYuSeDfZfb cYuSeDfZfb 13 Oct '23

13 Oct '23

Hi, We are running replication checks, including one where we compare "slapcat | grep contextCSN" output across our 4 different openldap 2.5 MRR servers. Relevant config (on each server identically through ansible) database mdb maxsize 10737418240 suffix "o=company,c=com" rootdn "cn=ldapadmin,o=company,c=com" rootpw {SSHA}h9xyz..... directory /var/symas/openldap-data overlay syncprov syncprov-checkpoint 100 1 Now using this config, we would expect the contextCSN to be faily up-to-date across all servers, however, this is not always the case. There are occasions where servers contextCSN become 'outdated', while others are up-to-date. If we query contextCSN though ldapsearch, the correct contextCSN is returned on all servers. This situation can remain for long, and restarting openldap solves it immediately. We could of course change our logging to query contextCSN through an ldapsearch, but we see advantages (no network, no authentication, etc, etc) in using slapcat as well. Is there anything we can do to update on-disk contextCSN more often..? We would expect " syncprov-checkpoint 100 1" to take care of this..? Have a nice weekend, everybody! MJ

2 2

Re: refresh and persistant not always persisting :-)
by cYuSeDfZfb cYuSeDfZfb 11 Oct '23

11 Oct '23

Hi Quanah, I feel stupid for not having googled "openldap keepalive", and instead write to the list. I have read so much (and seen so many samples) about replication configuration lately, that I thought I did everything correctly. Thanks for patiently pointing at what I should have been able to find out myself. MJ On Wed, 11 Oct 2023 at 16:29, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Wednesday, October 11, 2023 4:49 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > > > > > Hi, > > > > > > Of course I add many more details like detailed configs and logs, just > > ask. > > > > > > We have a 4-host MMR setup, that all replicate to the three others, > > relevant snippets from the config: > > > > We wondered what could cause this behaviour, and started thinking in the > > direction of long-lived tcp connections that perhaps are used in > > refreshAndPersist functionality. (much like in IMAP idle) > > > > > > Is anything special needed to make refreshAndPersistwork reliably through > > firewalls, and across subnets? Does refreshAndPersistwork use (some kind > > of) long-lived network connections..? Is there a kind of "keepalive" > > setting that we could try..? > > Read the section on keepalive settings. This is a common issue with > firewalls and why those settings were introduced. I usually use > keepalive=240:10:30 to go under the (usually default) 5 minute disconnect > most firewalls have. > > --Quanah > >

1 0

refresh and persistant not always persisting :-)
by cYuSeDfZfb cYuSeDfZfb 11 Oct '23

11 Oct '23

Hi, Of course I add many more details like detailed configs and logs, just ask. We have a 4-host MMR setup, that all replicate to the three others, relevant snippets from the config: * moduleload syncprov.la * different (and consistent) serverID's configured correctly on all hosts and then on each host the three other LDAP servers are defined like the below sample from ldapm01.company.com : syncrepl rid=212 provider=ldaps://ldapm02.company.com:636 bindmethod=simple binddn="cn=ldap_replicate,ou=Directory Access,o=company,c=com" credentials=xyz searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="1 2 3 4 5 +" attrs="*,+" tls_reqcert=demand syncrepl rid=232 provider=ldaps://ldaps01.company.com:636 bindmethod=simple binddn="cn=ldap_replicate,ou=Directory Access,o=company,c=com" credentials=xyz searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="1 2 3 4 5 +" attrs="*,+" tls_reqcert=demand syncrepl rid=242 provider=ldaps://ldaps02.company.com:636 bindmethod=simple binddn="cn=ldap_replicate,ou=Directory Access,o=company,c=com" credentials=xyz searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="1 2 3 4 5 +" attrs="*,+" tls_reqcert=demand MirrorMode True We observe that usually replication is quick and instant. But "sometimes" (yes, sometimes...) a replication line (rid) can become 'stuck', and suddeny, after an hour or so it syncs up again. Restarting openldap make it sync immediately. We notice that because we compare contextCSN's across our nodes to monitor replication. There is no significant load, firewall ports are open, but hosts are in different subnets: subnet A: ldapm01 / ldapm02, subnet B: ldaps01 / ldaps02 Of course 389/636 ports are open between the subnets. We wondered what could cause this behaviour, and started thinking in the direction of long-lived tcp connections that perhaps are used in refreshAndPersist functionality. (much like in IMAP idle) Is anything special needed to make refreshAndPersistwork reliably through firewalls, and across subnets? Does refreshAndPersistwork use (some kind of) long-lived network connections..? Is there a kind of "keepalive" setting that we could try..? Input would be appreciated. Also input like: you are looking in the wrong direction, better look into this or that. :-) Thanks!

2 1

pwdEndTime usage
by Volodymyr Lisnyi 11 Oct '23

11 Oct '23

Hello all, I updated our slapd daemon from 2.4 to 2.5 and want to use pwdEndTime operation attribute I read a lot of docs and can not find how I can add this attribute for all existing users. It is an internal operation attribute that was introduced in slapd version 2.5 (OpenLDAP 2.5+ now ships the ppolicy schema hard-coded in the overlay slapo-ppolicy) So as I see this attribute has no true/false or other flag (it is internal scheme attribute), which allows me to add it to dn: cn=passwordDefault,ou=Policies,dc=zone,dc=net or policy overlay olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config os is there any way I can enable it and update existing users with pwdEndTime attribute?

3 11

Re: [EXT] Re: regular yum symas-openldap-servers update breaks permissions on /var/symas/openldap-data
by cYuSeDfZfb cYuSeDfZfb 11 Oct '23

11 Oct '23

Hi Ulrich, I thought the same, but it seems yum/dnf do not have a post-install 'hook', like debian has with DPkg::Pre-Install-Pkgs & DPkg::Post-Invoke, that allows you to define commands/scripts to run before and after. Not sure how to do something similar on RHEL. I have now excluded openldap from auto updates, and added instructions on our manual update.instructions. Any ideas here..? On Wed, 11 Oct 2023 at 11:05, Windl, Ulrich <u.windl(a)ukr.de> wrote: > I wonder: > Couldn't some RPM "pre-script" remember the current permissions for some > RPM "post script" to restore them (after they were messed up)? > > -----Original Message----- > From: cYuSeDfZfb cYuSeDfZfb <cyusedfzfb(a)gmail.com> > Sent: Thursday, September 21, 2023 10:54 AM > To: Ondřej Kuzník <ondra(a)mistotebe.net> > Cc: openldap-technical(a)openldap.org; Dimitar Stoychev <dstoychev(a)symas.com > > > Subject: [EXT] Re: regular yum symas-openldap-servers update breaks > permissions on /var/symas/openldap-data > > Hi Ondřej, > > Thanks for your reply. > > Yes, we are putting our (single file) mdb straight in > /var/symas/openldap-data, using subdirs never crossed our minds. > > Anyway, we just have to document this behaviour in our upgrade > documentation. > > Must say: the behaviour, for us, is a little bit unexcpected. We didn't > expect rpm upgrades to "mess" with fs permissions, but we can simply work > around it. > > Thanks again for your reply, appreciated! > > > On Wed, 13 Sept 2023 at 12:25, Ondřej Kuzník <ondra(a)mistotebe.net <mailto: > ondra(a)mistotebe.net> > wrote: > > > On Tue, Sep 12, 2023 at 04:44:15PM +0200, cYuSeDfZfb cYuSeDfZfb > wrote: > > Hi, > > > > We're seeing this quite consistently. > > > > Before updating: > > [root@ldaps01 log]# ls -l > > /var/symas/ drwx------. 3 ldap ldap 50 Aug 28 16:28 openldap-data > > > > After updating: > > [root@ldaps01 log]# ls -l > > /var/symas/ drwx------. 3 root root 50 Aug 28 16:28 openldap-data > > > > And afterwards symas-openldap-server (running as ldap:ldap) no > longer > > starts, since permission denied on /var/symas/openldap-data. > > > > Reverting the permissions back to ldap:ldap solves it. But...WHY > is this > > happening. > > > > Are we somehow encouraged to run openldap as root..? > > > > Why would a post-install script reset permissions on > > /var/symas/openldap-data? > > Hi, > openldap-data is owned by the package and as such you'll have to > tell > rpm somehow (a trigger, ...) that you don't want it to mess with > it. > AFAIK there's work ongoing to make the directory 711 which should > sort > things for you. > > That's unless you're putting the databases directly into > /var/symas/openldap-data, we advise you create a subdirectory per > DB, > e.g. /var/symas/openldap-data/dc=example,dc=com or > /var/symas/openldap-data/cn=accesslog. > > Regards, > > -- > Ondřej Kuzník > Senior Software Engineer > Symas Corporation http://www.symas.com > Packaged, certified, and supported LDAP solutions powered by > OpenLDAP > > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical October 2023