openldap-technical June 2024

openldap-technical@openldap.org

14 participants
13 discussions

openldap TLSv1.0 is enabled
by Andre Rodier 16 May '25

16 May '25

Hello, I have configured OpenLDAP using SSL certificate, but I have a few issues. Here the TLS configuration, especially "olcTLSProtocolMin: 3.3" > # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. > # CRC32 c70363a6 > dn: cn=config > objectClass: olcGlobal > cn: config > olcArgsFile: /var/run/slapd/slapd.args > olcLogLevel: none > olcPidFile: /var/run/slapd/slapd.pid > olcToolThreads: 1 > structuralObjectClass: olcGlobal > entryUUID: 40ee991a-0efe-103d-855a-11ff3a5638b4 > creatorsName: cn=config > createTimestamp: 20221213065102Z > olcPasswordCryptSaltFormat: $6$%.16s > olcTLSCACertificateFile: /etc/ldap/certs/ldap.homebox.world.issuer.crt > olcTLSCertificateKeyFile: /etc/ldap/certs/ldap.homebox.world.key > olcTLSCertificateFile: /etc/ldap/certs/ldap.homebox.world.crt > olcTLSProtocolMin: 3.3 > entryCSN: 20221214054517.926245Z#000000#000#000000 > modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > modifyTimestamp: 20221214054517Z But if I try sslscan: I see TLSv1.0, TLSv1.1 and TLSv1.2 enabled. Why ? > root@main:/etc/ldap/changes# sslscan ldap.homebox.world:636 > Version: 2.0.7 > OpenSSL 1.1.1n 15 Mar 2022 > > Connected to 2001:19f0:7402:86e:5400:4ff:fe38:b9b4 > > Testing SSL server ldap.homebox.world on port 636 using SNI name ldap.homebox.world > > SSL/TLS Protocols: > SSLv2 disabled > SSLv3 disabled > TLSv1.0 enabled > TLSv1.1 enabled > TLSv1.2 enabled > TLSv1.3 enabled > > TLS Fallback SCSV: > Server supports TLS Fallback SCSV > > TLS renegotiation: > Secure session renegotiation supported > > TLS Compression: > OpenSSL version does not support compression > Rebuild with zlib1g-dev package for zlib support > > Heartbleed: > TLSv1.3 not vulnerable to heartbleed > TLSv1.2 not vulnerable to heartbleed > TLSv1.1 not vulnerable to heartbleed > TLSv1.0 not vulnerable to heartbleed > > Supported Server Cipher(s): > Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253 > Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253 > Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253 > Accepted TLSv1.3 128 bits TLS_AES_128_CCM_SHA256 Curve 25519 DHE 253 > Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve 25519 DHE 253 > Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits AES256-GCM-SHA384 > Accepted TLSv1.2 256 bits AES256-CCM > Accepted TLSv1.2 128 bits AES128-GCM-SHA256 > Accepted TLSv1.2 128 bits AES128-CCM > Accepted TLSv1.2 256 bits AES256-SHA > Accepted TLSv1.2 128 bits AES128-SHA > Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.1 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.1 256 bits AES256-SHA > Accepted TLSv1.1 128 bits AES128-SHA > Preferred TLSv1.0 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.0 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.0 256 bits AES256-SHA > Accepted TLSv1.0 128 bits AES128-SHA > > Server Key Exchange Group(s): > TLSv1.3 128 bits secp256r1 (NIST P-256) > TLSv1.3 192 bits secp384r1 (NIST P-384) > TLSv1.3 260 bits secp521r1 (NIST P-521) > TLSv1.3 128 bits x25519 > TLSv1.3 224 bits x448 > TLSv1.3 112 bits ffdhe2048 > TLSv1.3 128 bits ffdhe3072 > TLSv1.3 150 bits ffdhe4096 > TLSv1.3 175 bits ffdhe6144 > TLSv1.3 192 bits ffdhe8192 > TLSv1.2 128 bits secp256r1 (NIST P-256) > TLSv1.2 192 bits secp384r1 (NIST P-384) > TLSv1.2 260 bits secp521r1 (NIST P-521) > TLSv1.2 128 bits x25519 > TLSv1.2 224 bits x448 > > SSL Certificate: > Signature Algorithm: sha256WithRSAEncryption > RSA Key Strength: 2048 > > Subject: ldap.homebox.world > Altnames: DNS:ldap.homebox.world > Issuer: (STAGING) Artificial Apricot R3 > > Not valid before: Dec 13 05:34:29 2022 GMT > Not valid after: Mar 13 05:34:28 2023 GMT Thanks for your insights. Andre

6 13

Re: Replication issue during performance test with MMR configuration and LastBind enabled
by Falgon 16 Oct '24

16 Oct '24

Hello, I'm working on the same project as Meheni. Thanks for your answer, we'll try version 2.6 OpenLDAP using the lastbind-precision. However we have several questions for the current version we're using. Is this a known problem and referenced somewhere? (we haven't found it) Is it normal to find no replication error logs even in stats + sync mode? We ran some tests in sequential mode (300,000 accounts one after the other) and managed to reproduce the problem. -Denis Le mer. 11 oct. 2023 à 14:11, Quanah Gibson-Mount <quanah(a)fast-mail.org> a écrit : > > > --On Tuesday, October 10, 2023 9:30 PM +0200 Ziani Meheni > <mehani06(a)gmail.com> wrote: > > > > > > > Hello, we are working on a project and we've come across a problem with > > the replication after performance testing : > > You need to use OpenLDAP 2.6 and then set the: > > lastbind-precision > > value. I use 5 minutes. > > --Quanah >

4 8

Re: Facing issues with Symas LDAP upgrade from 2.4 to 2.5
by anil kumar pathuri 24 Jul '24

24 Jul '24

hi Quanah, Hope you are doing well. Thank you for your email. PFA This is what I did: Installed openldap 2.4.44 --> Upgraded to Symas OpenLDAP 2.4.57 --> Upgrading from Symas OpenLDAP 2.4.57 to Symas OpenLDAP 2.6.7 ***PS: I am not using slapd.conf, what should I do in this case. Regards, Anil P On Fri, 17 May 2024 at 01:57, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, May 16, 2024 7:55 PM +0000 anilkumar.pathuri7(a)gmail.com > wrote: > > > Hi Team, GM > > Successful while trying to upgrade from openLDAP 2.4.44 to > SymasLDAP2.4.57 > > > > Facing issues while trying to upgrade to 2.5.x and 2.6.x from > > SymasLDAP2.4.57 https://repo.symas.com/soldap2.5/upgrading/ > > > > Issues while trying to upgrade from SymasLDAP2.4.57 to SymasLDAP 2.5.17. > > 1. config error processing olcDatabase={2}mdb,cn=config > > UNKNOWN attributeDescription "OLCDBINDEX" inserted > > Providing a config snippet is not particularly useful. > > You also say issue going from 2.5.x to 2.6.x but then you say the error is > in going from 2.4.57 to 2.5.17. > > Your error generally indicates that you're missing a module load on the > MDB > backend module. > > --Quanah > >

7 13

FW: Accessing ppolicy attributes as non-admin in 2.4
by Windl, Ulrich 07 Jul '24

07 Jul '24

As I think the message had been blocked (I'm still receiving messages, but seem to be unable to send due to address mis-matching), I'm re-sending it. Please ignore if it had been delivered. From: Windl, Ulrich Sent: Thursday, June 20, 2024 9:53 AM To: openldap-technical <openldap-technical(a)openldap.org> Subject: Accessing ppolicy attributes as non-admin in 2.4 Hi! Yes, we are still running an old 2.4 OpenLDAP (mostly because it still has "hdb"), but anyhow: There's a request to search for accounts where the password will expire soon according to configured ppolicies. I wrote the code, realizing that a normal user cannot read other users policy attributes, while the admin user can. As the process should run automatically, I don't want to add admin credentials for that kind of reporting. Instead I added a new user role and tried to add access to the attributes, but somehow it does not work. I think I did not make an error, but ACL configuration can be tricky. So the question is: Can it be done in 2.4, and if so, what might be wrong in this config (lines unfolded, sorry): olcAccess: {0}to * by dn.exact="uid=syncrepl,ou=system,dc=..." read by group/organizationalRole/roleOccupant.exact="cn=LDAP-Manager,dc=roles,dc=..." write by * break olcAccess: {1}to dn.children="dc=roles,dc=..." attrs=roleOccupant by * none olcAccess: {2}to attrs=pwdAccountLockedTime,pwdAllowUserChange,pwdChangedTime,pwdCheckQuality,pwdExpireWarning,pwdFailureCountInterval,pwdGraceAuthNLimit,pwdGraceUseTime,pwdHistory,pwdInHistory,pwdLockoutDuration,pwdMaxFailure,pwdMaxRecordedFailure,pwdMinAge,pwdMinLength,pwdMustChange,pwdPolicySubentry,pwdRe\ set,pwdSafeModify,shadowExpire,shadowInactive,shadowLastChange,shadowMax,shadowMin,shadowWarning by dn.exact="uid=PP-Checker,ou=system,dc=..." read break olcAccess: {3}to attrs=userPassword,userPKCS12 by self write by * auth olcAccess: {4}to attrs=shadowLastChange by self write by * read olcAccess: {5}to attrs=pwdHistory,pwdGraceUseTime,pwdChangedTime by self read by * none olcAccess: {6}to * by * read The account in question is ="uid=PP-Checker,ou=system,dc=..." obviously, and the "cn=LDAP-Manager,dc=roles,dc=..." can access the attributes. The account is like this: dn: uid=PP-Checker,ou=system,dc=... objectClass: top objectClass: account objectClass: simpleSecurityObject structuralObjectClass: account uid: PP-Checker The Admin object looks like this: dn: cn=LDAP-Manager,dc=roles,dc=... objectClass: organizationalRole cn: LDAP-Manager description: Administrative Access to LDAP Directory roleOccupant: uid=me-for-example,ou=people,dc=... roleOccupant: uid=another,ou=people,dc=... structuralObjectClass: organizationalRole Any help on this is highly appreciated. If you think something else is wrong, also tell me please. Alternatively you could give an answer on https://superuser.com/q/1844359/964771 Kind regards, Ulrich

2 11

[2.5.16] Filter Replication Issue
by Pierre Marty 04 Jul '24

04 Jul '24

Hi, When using a filter on a replicated branch, it seems that deletion updates are still propagated... The cluster in use is a 4 nodes master-master with the following settings: olcsyncrepl: rid=4 provider="ldaps://url" type=refreshAndPersist retry="5 10 60 +" timeout=5 network-timeout=10 keepalive=60:10:5 schemachecking=off searchbase="dc=root,dc=com" scope=sub bindmethod=sasl saslmech=external tls_cacertdir=/usr/local/openldap/etc/openldap/certs tls_cert=/usr/local/openldap/etc/openldap/certs/cert.crt tls_key=/usr/local/openldap/etc/openldap/certs/cert.key tls_cipher_suite=HIGH tls_reqcert=demand filter="(!(objectclass=MyOwnClass))" The objectclass is as follow: dn: MyOwnClass=state,ou=initials,dc=root,dc=com AF-UID: state objectClass: MyOwnClass objectClass: top STATE: UP structuralObjectClass: MyOwnClassThe replication account does not possesses any access to this element :olcAccess: to dn.exact="MyOwnClass=state,ou=initials,dc=root,dc=com" by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn.exact="cn=status,ou=serviceaccounts,dc=root,dc=com" read by dn.exact="cn=confldap,ou=serviceaccounts,dc=root,dc=com" manage by * none Yet, when MyOwnClass=state,ou=initials,dc=root,dc=com is deleted the following logs appear: serverA : op=1 DEL dn="MyOwnClass=state,ou=initials,dc=root,dc=com" serverA : op=1 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7ff5a00157c0 serverB : op=0 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7f158c0015c8 serverB : syncrepl_del_nonpresent: rid=003 be_delete MyOwnClass=state,ou=initials,dc=root,dc=com (0) serverB : op=1 SRCH base="MyOwnClass=state,ou=initials,dc=root,dc=com" scope=2 dereIs it an expected behavior? When updating the value or renaming the object, no replication is noticed. Have a good day,-- Pierre Marty Ingénieur Logiciel / OSSA pmarty(a)linagora.com (+33) 067 530 3612 ------------------ ossa(a)linagora.com (+33) 080 005 4689 - 3 ------------------ GROUPE LINAGORA Villa Good Tech 37 Rue Pierre Poli 92130 Issy-les-Moulineaux (+33) 097 263 9776

3 2

Re: sync repl issue
by Luo, Frank 27 Jun '24

27 Jun '24

OK. Thanks. we just use the RPM package from OEL8. Do you know if 2.6 RPM is available on OEL8? On Fri, Jun 21, 2024 at 1:06 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > > --On Friday, June 21, 2024 1:35 PM -0400 "Luo, Frank" <luoy(a)miamioh.edu> > wrote: > > > sorry. it is 2.4.46 and I believe it is standard syncrepl ( I could > > not find syncdata in slapd.conf). > > Hi, > > The OpenLDAP 2.4 series has been deprecated for several years, and numerous > issues with replication have been fixed in the later release series. I > would strongly advise upgrading to a supported release, in particular the > OpenLDAP 2.6 series. You've most likely encountered one of the many known > and (later) fixed issues with syncrepl in the 2.4 series. > > Regards, > Quanah > > > >

4 5

Q: Reset a locked user's password
by Windl, Ulrich 23 Jun '24

23 Jun '24

Hi! I have a question related to policy and a user with an expired password and all grace logins consumed, like this: pwdChangedTime[0] 20231127075102Z pwdGraceUseTime[0] 20240429142254Z pwdGraceUseTime[1] 20240430112006Z pwdGraceUseTime[2] 20240527074731Z pwdGraceUseTime[3] 20240528114912Z pwdGraceUseTime[4] 20240528130249Z pwdFailureTime[0] 20240611082600.348275Z How can the user change his password? The user cannot log in anymoe, obviously. If the user could log in he would have admin privileges. I had the idea to delete the grace logins via ldapmodify, but the result (for version 2.4) was: ldap_modify: Constraint violation (19) additional info: pwdGraceUseTime: no user modification allowed So what are the options (for the user himself and for an admin)? Regards, Ulrich

3 5

Re: sync repl issue
by Luo, Frank 21 Jun '24

21 Jun '24

sorry. it is 2.4.46 and I believe it is standard syncrepl ( I could not find syncdata in slapd.conf). Thanks On Fri, Jun 21, 2024 at 10:52 AM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > > --On Friday, June 21, 2024 9:59 AM -0400 "Luo, Frank" <luoy(a)miamioh.edu> > wrote: > > > refreshAndPersist, mirrormode on for node 01 and 02 , off for node 03 and > > Hi, you didn't answer these two questions: > > Standard syncrepl or delta syncrepl? What version of OpenLDAP? > > Thanks! > > --Quanah > >

2 1

Re: sync repl issue
by Luo, Frank 21 Jun '24

21 Jun '24

refreshAndPersist, mirrormode on for node 01 and 02 , off for node 03 and 04 Thanks On Thu, Jun 20, 2024 at 7:22 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > > --On Thursday, June 20, 2024 4:48 PM -0400 "Luo, Frank" <luoy(a)miamioh.edu> > wrote: > > > Hi, all > > > > We have a 4 nodes set up, n01 and n02 have mirror mode on and they are > > provider and consumer to each other. n03's provider is n01 and n04's > > provider is n02. Each has contexcsn as followings so I think they are > > all in sync. > > > > However I have a node n04 missing some data (one entry I found so > > far). How to explain this and how to troubleshoot? Thanks a lot! > > What version of OpenLDAP? What kind of sync replication (standard, delta? > refreshonly, refreshAndPersist?) etc. > > --Quanah > >

2 1

sync repl issue
by Luo, Frank 20 Jun '24

20 Jun '24

Hi, all We have a 4 nodes set up, n01 and n02 have mirror mode on and they are provider and consumer to each other. n03's provider is n01 and n04's provider is n02. Each has contexcsn as followings so I think they are all in sync. However I have a node n04 missing some data (one entry I found so far). How to explain this and how to troubleshoot? Thanks a lot! Frank n01 contextCSN: 20180628172040.692013Z#000000#001#000000 contextCSN: 20180628172039.214361Z#000000#002#000000 contextCSN: 20240620192402.726831Z#000000#015#000000 contextCSN: 20240620193606.038191Z#000000#016#000000 n02 contextCSN: 20180628172040.692013Z#000000#001#000000 contextCSN: 20180628172039.214361Z#000000#002#000000 contextCSN: 20240620192402.726831Z#000000#015#000000 contextCSN: 20240620193606.038191Z#000000#016#000000 n03 contextCSN: 20180628172040.692013Z#000000#001#000000 contextCSN: 20180628172039.214361Z#000000#002#000000 contextCSN: 20240620192402.726831Z#000000#015#000000 contextCSN: 20240620193606.038191Z#000000#016#000000 n04 contextCSN: 20180628172040.692013Z#000000#001#000000 contextCSN: 20180628172039.214361Z#000000#002#000000 contextCSN: 20240620192402.726831Z#000000#015#000000 contextCSN: 20240620193606.038191Z#000000#016#000000

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2024