openldap-technical

openldap-technical@openldap.org

1 participants
9989 discussions

RE: Issues deploying openldap 2.6.4 Proxy on RHEL 8.7
by Vikram Sharma 04 May '23

04 May '23

Hello Support, Please see the screenshot for more information. [cid:image001.png@01D97E87.92DA8720] Warm Regards, Vikram Sharma Vikram.Sharma(a)investec.co.in<mailto:Vikram.Sharma@investec.co.in> Investec Global Services (India) Pvt. Ltd. Tel: +91 22 68497512 Mob: +91 9930600995 From: Vikram Sharma Sent: 04 May 2023 11:22 To: openldap-technical(a)openldap.org Cc: Amit Kulkarni <Amit.Kulkarni(a)investec.co.in>; Wyvern Bozec-Pearce <Wyvern.Bozec-Pearce(a)investec.co.uk> Subject: Issues deploying openldap 2.6.4 Proxy on RHEL 8.7 Hello Support, We are trying to deploy Openldap proxy from the available package from the openldap site version 2.6.4 on the Red Hat Enterprise Linux version 8.7 ootpa. We are aware that Red Hat enterprise 8.7 support openldap clients however, installing openldap-server is not supported. We are referring to the support tech link https://computingforgeeks.com/install-configure-openldap-server-centos/ to deploy openldap 2.6.4 however, when the deployment installation is completed following steps we are unable to start slapd service as slapd.d file is missing can we get some guidance on this please? Download site - https://www.openldap.org/software/download/OpenLDAP/openldap-release/ Install Procedure ------------------------------------------------------------------------------------------- #login as root user sudo su - #update required as pre-requisite sudo dnf update -y #restart once update is completed. sudo reboot #install the required dependencies sudo dnf install wget vim cyrus-sasl-devel libtool-ltdl-devel openssl-devel libdb-devel make libtool autoconf tar gcc perl perl-devel -y #create a non-privileged system user for OpenLDAP. sudo useradd -r -M -d /var/lib/openldap -u 55 -s /usr/sbin/nologin svcldapusr #Download the openldap tgz file from site https://www.openldap.org/software/download/OpenLDAP/openldap-release/ Transfer the file via Winscp and extract tar xzf openldap-$VER.tgz #Install OpenLDAP on RHEL 8 sudo mv openldap-$VER /opt # Change your working directory to OpenLDAP source. cd /opt/openldap-$VER #Install Development Tools: sudo dnf groupinstall "Development Tools" -y #Compile the source files sudo ./configure --prefix=/usr --sysconfdir=/etc --enable-debug --with-tls=openssl --with-cyrus-sasl --enable-dynamic --enable-crypt --enable-spasswd --enable-slapd --enable-modules --enable-rlookups #Upon successful compilation, you should see an output that says: "Please run "make depend" to build dependencies" #Run make depend to build OpenLDAP dependencies. sudo make depend #Compile OpenLDAP. sudo make #Install OpenLDAP on RHEL 8: sudo make install #A successful installation creates configuration files at /etc/openldap. The following files are available after installation: $ ls /etc/openldap certs ldap.conf ldap.conf.default schema slapd.conf slapd.conf.defaul Warm Regards, Vikram Sharma Vikram.Sharma(a)investec.co.in<mailto:Vikram.Sharma@investec.co.in> Investec Global Services (India) Pvt. Ltd. Tel: +91 22 68497512 Mob: +91 9930600995 Investec Bank plc is authorised and regulated by the UK Financial Services Authority. Registered in England and Wales (No. 489604). Registered office at 30 Gresham St, London EC2V 7QP. Investec Asset Finance Plc is a subsidiary of Investec Bank plc. Registered in England and Wales (No. 2179313). Registered office at Reading International Business Park, Reading RG2 6AA. We may monitor e-mail traffic data and the content of email. Calls may be monitored and recorded. If we collect personal information, the personal information we have collected from you will be shared with fraud prevention agencies who will use it to prevent fraud and money-laundering and to verify your identity. If fraud is detected, you could be refused certain services, finance or employment. For further details on how your information will be used by Investec and these fraud prevention agencies, and your data protection rights, please refer to our Fraud Prevention Notice https://www.investec.com/en_gb/legal/UK/fraud-prevention-notice.html This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This e-mail is subject to terms available at the following link: www.investec.co.uk/emaildisclaimer. By communicating electronically with us, you consent to these terms.

2 1

Unable to filter only group name
by BANDANI MAHARANA 03 May '23

03 May '23

Hi team, I am facing problem with filtering the group names in Ad server using openldap libraries. I am using ldap search api to get the list of group. My requirement is, with the provided input, i need to display all the available group similar to the entered group name. For example, if user types dev, it should display all the group names starting with dev. Like develop, development Kindly suggest how to achieve this. Thank you Bandani

2 1

idea for possible RFE: universally unique connection IDs
by Christopher Paul 29 Apr '23

29 Apr '23

Hello OpenLDAP-Technical, I would like to seek comments on an idea I have had for a while. Does anyone agree with me that it would be nice if connection IDs were uuids? Because when your slapd restarts, your monitoring system has no good way to track one "conn=1000" from another one (or from one server to another), and so forth. Would there be any downsides to this? Are there any upsides to re-using integers starting at 1000? I can think of one: with incrementing integers, you can tell the order of the connections with them. Thanks, Chris Paul | Rex Consulting | https://www.rexconsulting.net

2 1

Constructed attributes?!
by Marco Gaiarin 26 Apr '23

26 Apr '23

There's some way, in OpenLDAP, to have attributed 'calculated on the fly' like the AD 'Constructed Attributes'? For a sake of an example, an attribute 'userStatus: disabled' if userPassword start with an '!'? Thanks. -- Di questa cavolo di pianura, di questa gente senza misura, che gia` confonde la notte e il giorno, e la partenza con il ritorno, e la richezza con i rumore, ed il diritto con il favore (F. De Gregori)

1 0

Write bottlenecks
by Sam Dave 26 Apr '23

26 Apr '23

Hi, My write pipelines have a bottleneck at the bottom (LMDB writing). Work piles on top up-front, waiting for LMDB writes to complete. Therefore the earlier work cannot really parallelize as much as it could if I could somehow make the writes go faster. Are there any tips/tricks around this? I wonder if it could pay off to parallelize the writes into a few LMDB environments - and merge them in the end. This could have the advantage of more parallelization on the up-front work, but disadvantage of the final merging work. Regards, Sam

1 0

leave
by Alceu Rodrigues de Freitas Junior 21 Apr '23

21 Apr '23

leave

1 0

openldap 2.3 and user passwords
by aurfalien 21 Apr '23

21 Apr '23

Hello list and Happy Friday. First and foremost I am not an OpenLDAP admin, well I guess that I am now for the purposes of this email. I’ve been thrust into an environment running an older version of openldap on CentoOS 5 and have been tasked to simply allow users in changing their passwords via passwd. Once a user has logged in on their respective workstation and types passwd we get this; Changing password for user johndoe. Current Password: New password: Retype new password: passwd: Authentication token manipulation error This tells me that I need to allow them self write access to userPassword Attribute of the LDAP database? However after reading a decent amount of literature, it's suggesting to use olcAccess but as far as I can tell this does not apply to my specific environment. All of the openldap data looks to be in /var/lib/ldap versus what I’ve been reading of /etc/openldap/slapd.d. The /etc/openldap/slapd.conf has this section which looks like what I should focus on; # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! It sounds like I should start here and see if this solves the issue. However where and how do I modify the default access control policy for this environment in allowing users to modify there userPassword attribute? Like I had mentioned, all of the reading thus far suggests olcAccess however my database is not in that format? Again very very new here and am forced to work with openldap 2.3 on a Centos 5 server for now. This is not to say that I would fair any better in a newer environment due to my lack of any real knowledge in this subject matter. At any rate thank you in advance. Humbly yours, - aurf

1 0

Use of olcTLSECName directive returns ‘wrong attibuteType’ error
by Lemons, Terry 20 Apr '23

20 Apr '23

Hi I’m attempting to modify the TLS ciphers that are used in an openldap2-2.4.41-22.16.1.x86_64 environment in our lab, running on SLES 12 SP5. I’ve used the following command to set the cipher list value to the returned value of ‘openssl ciphers HIGH’: ldpdd041:/tmp # cat set-ciphersuite.ldif dn: cn=config changetype: modify add: olcTLSCipherSuite olcTLSCipherSuite: HIGH ldpdd041:/tmp # ldapmodify -H ldapi:// -Y EXTERNAL -f set-ciphersuite.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldpdd041:/tmp # openssl ciphers HIGH ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DH-DSS-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DH-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DH-RSA-AES256-SHA256:DH-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DH-RSA-AES256-SHA:DH-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DH-RSA-CAMELLIA256-SHA:DH-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-GCM-SHA384:ADH-AES256-SHA256:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DH-DSS-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DH-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DH-RSA-AES128-SHA256:DH-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DH-RSA-AES128-SHA:DH-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:DH-RSA-CAMELLIA128-SHA:DH-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-GCM-SHA256:ADH-AES128-SHA256:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA ldpdd041:/tmp # So I had expected to see that all of these ciphers were being offered for use by the OpenLDAP server; instead, I see that only a subset of the list is offered: sslyze ldpdd041.hop.lab.emc.com:636 . . . * TLS 1.0 Cipher Suites: Attempted to connect using 80 cipher suites. The server accepted the following 4 cipher suites: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 256 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 128 TLS_RSA_WITH_AES_256_CBC_SHA 256 TLS_RSA_WITH_AES_128_CBC_SHA 128 The group of cipher suites supported by the server has the following properties: Forward Secrecy INSECURE - Not Supported Legacy RC4 Algorithm OK - Not Supported * TLS 1.1 Cipher Suites: Attempted to connect using 80 cipher suites. The server accepted the following 4 cipher suites: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 256 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 128 TLS_RSA_WITH_AES_256_CBC_SHA 256 TLS_RSA_WITH_AES_128_CBC_SHA 128 The group of cipher suites supported by the server has the following properties: Forward Secrecy INSECURE - Not Supported Legacy RC4 Algorithm OK - Not Supported * TLS 1.2 Cipher Suites: Attempted to connect using 156 cipher suites. The server accepted the following 8 cipher suites: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 256 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 128 TLS_RSA_WITH_AES_256_GCM_SHA384 256 TLS_RSA_WITH_AES_256_CBC_SHA256 256 TLS_RSA_WITH_AES_256_CBC_SHA 256 TLS_RSA_WITH_AES_128_GCM_SHA256 128 TLS_RSA_WITH_AES_128_CBC_SHA256 128 TLS_RSA_WITH_AES_128_CBC_SHA 128 I believe I know why the DHE-based ciphers are not being offered: I haven’t enabled use of the olcTLSDHParamFile directive. Rather than mess around with generating the DH param file, etc., I’d like to use ECDHE-based ciphers. According to p. 160 of https://www.openldap.org/doc/admin24/OpenLDAP-Admin-Guide.pdf, the ‘TLSECName’ directive allows an ECDHE curve to be specified. When I tried to enable use of the directive, I received a ‘wrong attibuteType’ error: ldpdd041:/tmp # cat set-ecname.ldif dn: cn=config changetype: modify add: olcTLSECName olcTLSECName : secp384r1 ldpdd041:/tmp # ldapmodify -H ldapi:// -Y EXTERNAL -f set-ecname.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 ldapmodify: wrong attributeType at line 4, entry "cn=config" ldpdd041:/tmp # Does OpenLDAP 2.4.41 not support this directive? Thanks tl Terry Lemons Senior Principal Software Engineer, Dell EMC Dell Technologies | Data Management Terry.Lemons(a)dell.com<mailto:Terry.Lemons@dell.com> Internal Use - Confidential

3 5

Re: Argon2-Support or secure hashing
by Braiam 14 Apr '23

14 Apr '23

On Thu, Apr 13, 2023 at 12:19 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > This is an annoying bit about the Debian/Ubuntu builds as > they strip that information out of the binary. I was curious about that, and Debian doesn't strip that information[1]: ldapadd -V ldapadd: @(#) $OpenLDAP: ldapmodify 2.5.13+dfsg-5 (Feb 8 2023 01:56:12) $ Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> (LDAP library: OpenLDAP 20513) I don't have an Ubuntu box at hand but their devel branch has the same patch[2] applied. If I trust that the datetime on the version string is the build date time, and since they use reproducible builds, I would guess that the base version is 2.5.6, from this changelog [3]. -- Braiam [1]: https://salsa.debian.org/openldap-team/openldap/-/blob/master/debian/patche… [2]: https://git.launchpad.net/ubuntu/+source/openldap/tree/debian/patches [3]: https://git.launchpad.net/ubuntu/+source/openldap/tree/debian/changelog?h=u…

4 6

How to get detailed connection error information?
by Jordan Brown 14 Apr '23

14 Apr '23

How can I get detailed information about connection errors - host not found, timed out, connection refused, various TLS errors, et cetera? -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

4 10

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical