openldap-technical

openldap-technical@openldap.org

9897 discussions

RE: [EXT]:Re: Openldap client is not populating GID name instead of it just getting GID with empty Group name
by Quanah Gibson-Mount 23 Mar '21

23 Mar '21

--On Tuesday, March 23, 2021 6:39 PM +0000 "Ballem, Narayanan" <Narayanan.Ballem(a)Staples.com> wrote: > No, F5 is not closing the connections as I see connection on LDAP > servers which are coming via F5 on both the sites and also secondary site > server under F5 as well which are working fine when client connections > are coming via F5. What logging level do you have set on the OpenLDAP server side? I assume you're doing something like using back-ldap to proxy the connection from OpenLDAP to AD? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: [EXT]:Re: Openldap client is not populating GID name instead of it just getting GID with empty Group name
by Quanah Gibson-Mount 23 Mar '21

23 Mar '21

--On Friday, March 19, 2021 1:39 PM +0000 "Ballem, Narayanan" <Narayanan.Ballem(a)Staples.com> wrote: > > HI , > > Thanks for your time and response. > Looks like I missed this email. > > I don't see issue with AD here, Let me explain bit more > > We have 2 (1 master , 1 slave) servers in each site and those are under > F5 LB with TCP enabled. > > Under F5 setup > Primary site servers takes load around 3K Ldap clients > Secondary site servers take around 50K Ldap clients > > The problem which I am seeing with primary site server directly by > passing F5 layer when we test with 5-10 clients it's working as expected > no issue with GID name fetching however when we enabled servers under F5 > with all the clients we are seeing GID fetching issue. And we are not > offloaded any cert in F5 it just TCP so no issue with F5 here. > Similarly secondary site servers are working fine with F5 or directly > without any issue and Backend AD syncing is working fine in both the > sites. > > Both the sites configuration are intact except systems are in different > locations. > > The only difference I see is no of clients are high in primary site and > no errors in ldap server logs , I am not sure my ldap servers not able to > take more than 100 clients. I am guessing some tuning might required. Are you sure the F5 isn't silently closing connections? This is a common problem with F5's. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

SHA-256 Password Support and OpenLDAP2-2.4.46 SLES15SP2
by Dario García Díaz-Miguel 23 Mar '21

23 Mar '21

Hello, We have a question related with the pw-sha2 module. We have deployed OpenLDAP2.4.46-9.31.1 on SLES15 SP2 from the official Suse Repository and we are able to use {CRYPT} {MD5} {SMD5} {SSHA} and {SHA}. We are awared that in order to support SHA-256 we have to load the contrib module named pw-sha2 which it was included on SLES12SP5 but is totally missing on SLES15SP2 package. This means that we would need to compile it, but due to limitations of the project we are working on we are not allowed to compile anything external. So I checked the changelog and I found that support was added on 2.4.32 release. Is it possible that the openldap2 package could have been compiled with the module features itself and I just need to add some kind of attribute or entry to my LDAP directory in order to enable it? We have tried to use Apache Directory Studio instead of slappasswd and we have set up a password to SHA256 but the bind won't work. Instead, CRYPT-SHA256 works so I can't figure out why. I suppose I'm totally misunderstanding this and the compilation of the module is required, but a little light ray of hope is there. Thank you so much. Regards. P Please consider the environment before printing this e-mail.

6 13

warning in SLAPO_PPOLICY(5) regarding ppolicy_hash_cleartext
by Christopher Paul 23 Mar '21

23 Mar '21

Hello, I read the warning in SLAPO_PPOLICY(5) regarding ppolicy_hash_cleartext: "It is recommended that when this option is used that compare, search, and read access be denied to all directory users". Am I correct to presume that this means that the compare, search, read access be denied for directory users' _own_ (self) userPassword attrs, right? Because compare, search, read access to _other_ users' userPassword is rightfully denied typically by any sensible access control ruleset. (Right?) And if this document does mean to say that compare, search, and read access should be denied for directory users' _own_ (self) userPassword attrs, can someone please explain why, if users can read their userPassword, it would be worse for it to be encrypted than plain text? Many thanks, Chris Paul Rex Consulting, Inc email: chris.paul(a)rexconsulting.net web: http://www.rexconsulting.net <http://www.rexconsulting.net> phone, toll-free: +1 (888) 403-8996 ext 1

3 3

-DSLAPD_MAX_FILTER_DEPTH=xxx
by Michael Ströder 22 Mar '21

22 Mar '21

HI! Looking at comments in ITS#9251 I wonder if and how one should set -DSLAPD_MAX_FILTER_DEPTH= when building OpenLDAP downstream packages. To me the default of 5000 looks way too high. It would be really helpful to have a metric of maximum filter depth sent in by clients in cn=monitor. Ciao, Michael.

2 1

OpenLDAP as AD Proxy: OpenLDAP returning seemingly random number of results?
by Doyon, Jean-François 22 Mar '21

22 Mar '21

Hello, I have been working on implementing OpenLDAP as an AD proxy. I now have a setup that I am happy with over all, except for one strange behaviour: When browsing AD via the proxy, I do not get all the results in a given OU. Notes: * The OUs never contain more than 200-250 entries, well below both AD and OpenLDAP's default limits? * Different LDAP clients end up displaying different amounts of results, though the amount seems to be consistent within a given client. So for OU X ldp.exe shows Y results always, but Apache Directory Studio shows Z results, always. * When doing a search, if I ask to return only specific attributes, the number of results returned shrinks. So when I search on objectClass=* on a given OU I get X results, if I request one attribute only, the list returned shrinks a little bit, if I add another attribute, the list shrinks again! * If I use those exact same clients to connect to AD directly, with all other things being equal, there is no such issue, and all expected results are shown. I never configure any special client limits, paging, etc. on either connection (AD or OpenLDAP). * I am using a binary build of 2.4.49 for Windows. * Authentication is done via local database with a different DN, there is no rebind-as-user. * There are ACLs on the proxy to restrict access to certain OUs. It seems as if I am hitting some sort of limit, as suggest but the fact that when I make a more complex search, the number of results shrinks ... but this does not appear to be a number of results or time limit, and either way I am well under 1000 results and under 60 seconds (The default limits I think?). So ... what's going on? Anyone have any idea? I'm stumped ... Thanks! Jean-François Doyon Gestionnaire, Opérations et sécurité des T.I. Commissariat aux langues officielles jean-francois.doyon(a)clo-ocol.gc.ca<mailto:jean-francois.doyon@clo-ocol.gc.ca> / Tél. : 613-218-0547 Manager, I.T. Operations and security Office of the Commissioner of Official Languages jean-francois.doyon(a)ocol-clo.gc.ca<mailto:jean-francois.doyon@ocol-clo.gc.ca> / Tel: 613-218-0547

1 0

data.mdb grows faster with more frequent commits
by Alec Matusis 22 Mar '21

22 Mar '21

We have an environment with no flags that contains a database with no flags. The database is append only, no deletions or modifications. It is written using a single RW transaction, in the absence of any RO transactions. We observe that when we commit and recreate the RW transaction every 2000 insertion ops, the data.mdb file size on disk is 2x larger than when committing every 64000 insertion ops. The mdb_copy -c utility shrinks the large 2k ops commit file to almost the same file size as the 64k commit one. mdb_stat -e on the data.mdb shows that when we have more commits and bigger file, we have more pages used by the same proportion. In production we will have several large DBs (>1TB) on an NVMe card and we do not have the 2x space for periodic mdb_copy -c compactifications (and we cannot stop the writing process). We also need to commit every 2000 write ops, because there will be short-lived RO transactions that need to see the DB updates every 2000 writes. 1. Why is the file size on disk dependent on the commit frequency? (I suppose because with less frequent commits it can allocate data between pages more efficiently)? 2. What can we do to reduce data.mdb, if we must commit frequently? Can we use any environment, transaction or db flags, or anything else? We are on Linux 5.4.0 / ext4 fs. The DB that grows 2x faster with more frequent commits has bytearr key -> u32 val structure (the byterarray key is between 31 and 36 bytes). Another DB that has a reverse u32 key -> bytearr structure oonly grows 10% larger in the more frequent commits regime.

2 3

OpenLDAP client api documentation
by frpinci＠cisco.com 17 Mar '21

17 Mar '21

Hi, Is there any documentation explaining how to write an LDAP client using the OpenLDAP library? If not, what is the best approach to find out what functions to use and what options should be set for a certain auth method? I am writing a client but I am having issues with ldaps. Without documentation it is hard for me to tell if I am missing something or doing something wrong. Thanks, Francesco

2 1

SLE/openSUSE packages OpenLDAP 2.4.58
by Michael Ströder 16 Mar '21

16 Mar '21

On 3/16/21 7:53 PM, project(a)openldap.org wrote: > OpenLDAP 2.4.58 is now available for download as detailed on our download page: > > https://www.openldap.org/software/download/ As usual you can find SLE and openSUSE packages here: https://build.opensuse.org/package/show/network:ldap/openldap2 Ciao, Michael.

1 0

Symas OpenLDAP for Linux 2.4.58 Released
by Quanah Gibson-Mount 16 Mar '21

16 Mar '21

The latest version of Symas OpenLDAP for Linux is now available for RHEL7, RHEL8, Ubuntu18 LTS, and Ubuntu 20 LTS. <https://repo.symas.com/sofl/> for installation instructions. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical