February 2021 - openldap-technical

Index seems to return wrong amount of candidate causing really poor search performance

by chrichardso27＠gmail.com

Hi, Considering the following assumptions; - OpenLDAP version 2.4.51 - attributes objectClass and abc are indexed based on equality - the EQUALITY of attribute abc is based on distinguishedNameMatch - The database contains roughly 2 million entries - 2 entries have defined the attribute abc with a dn value cn=foo,dc=bar and objectClass=someClass - 2 entries have defined the attribute abc with a dn value cn=bar,dc=baz and objectClass=someClass Now, the issue started with really slow search performance using objectClass=someClass & abc=cn=foo,dc=bar as filter criteria. Debugging a while seems to indicate that the objectClass filter returns roughly 2 million entries as candidates. Now, one would expect that the second filter would return only the 2 potential candidates from the abc index, or a subset of the whole database but this is not the case. The second filter also returns nearly the whole database entries as potential candidates and causes really slow query performance. Interestingly, this only occurs when attribute abc has value cn=foo,dc=bar, but for some reason for the entry having attribute abc with value cn=bar,dc=baz the query returns immediately. In both cases, the actual entries matching the search return immediately but for the problematic search "(&(objectClass=someClass)(abc=cn=foo,dc=bar))", the completion of the search takes a long time (around 15 seconds to be precise). The issue started suddenly and wasn't a degradation of query performance over time. Few things I have tried - Rebuilt the whole database again - Reindex the existing database again - Testing with bdb and mdb as backends - Increased cache sizes for bdb to hold the whole database in cache - For bdb adjust the page size of the indexes according to suggestion by db_tuner - Change the order of the filters None of these made any difference. At the moment, there does not seem to be any good options to try. Any ideas or help would be greatly appreciated!

1 year, 7 months

6
18
0 / 0

openldap client library connection caching?

by Rallavagu Kon

All, Deployed OpenLDAP 2.4 in production (with replication) mainly serving saslauthd and sendmail on Linux with client library 2.4.49. We are experiencing sporadic errors "ldap_simple_bind() failed -1 (Can't contact LDAP server).”. This issue happens on both saslauthd and on openldap when replicating to other service. However, upon investigation we have found that this error is not disruptive as both services (saslauthd and openldap server) have “retry” options built-in and subsequent request (immediately after a failure) receives successful response. Also, noticed that this issue manifests when communication occurs via ELB (AWS) and no connect issues were manifested when clients are directly pointed to openldap server (all connections are TLS). This makes me infer (suspect) that openldap client library might be caching (or tcp alive etc.) the connection which is not working well with ELB (Elastic Load Balancer). Wondering if the connection is really cached and is there a configuration parameter that I can try and tune the behavior (tried to chase this down looking into the source code of client library but could not locate it, perhaps I need to look more but wondering if someone else in the community has any experience in this regard). Thank You.

2 years

3
3
0 / 0

OpenLDAP 2.5.2 Beta binary builds for testing

by Quanah Gibson-Mount

Symas is pleased to provide binary builds of the OpenLDAP 2.5.2 beta for testing purposes only on the following select platforms. Builds install into /opt/openldap25/ with state files stored in /var/opt/openldap25/ so as to be entirely self contained. No init scripts are provided and it is expected that end testers are familiar with OpenLDAP configuration. Please file any software (not packaging) related issues found at https://bugs.openldap.org/ Platforms: Ubuntu 20.04 LTS RHEL8 and binary compatible distributions (note: requires EPEL) Fedora 34 -------------------------------------------------- Ubuntu 20.04 LTS installation instructions: sudo add-apt-repository ppa:symas/openldap25 sudo apt-get update sudo apt install openldap-clients openldap-server -------------------------------------------------- -------------------------------------------------- RHEL8 installation instructions: dnf install 'dnf-command(copr)' dnf install epel-release dnf copr enable symas/openldap25 yum install openldap25-libs openldap25-clients openldap25-server -------------------------------------------------- -------------------------------------------------- Fedora 34 installation instructions: dnf install 'dnf-command(copr)' dnf copr enable symas/openldap25 yum install openldap25-libs openldap25-clients openldap25-server -------------------------------------------------- Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 years

2
5
0 / 0

OpenLDAP TLS encrypted connection

by SHarbich＠t-online.de

Hi, i wanted to activate the TLS / SSL encryption for my OpenLDAP server. After I created the certificates and wanted to paste the information into the backend, I got the following error message: ... root@dsme01:~# ldapadd -x -D cn=admin,cn=config -W -f /etc/ldap/tls.ldif Enter LDAP Password: modifying entry "cn=config" modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) ... The first entry was accepted. But not the second and third. Here is my ldif file: ... root@dsme01:~# cat /etc/ldap/tls.ldif ########################################################### # CONFIGURATION for Support of TLS ########################################################### # Add TLS supported access to user passwords for LDAP clients # to the LDAP config. dn: cn=config changetype: modify add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/ManagementCA.cacert.pem dn: cn=config changetype: modify add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap.intern.example.com.key.pem dn: cn=config changetype: modify add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap.intern.example.com.crt.pem ... I have saved the files as follows and given them rights. ... root@dsme01:~# ls -la /etc/ssl/private | grep ldap. -rw------- 1 openldap openldap 1675 Feb 25 08:12 ldap.intern.example.com.key.pam ... root@dsme01:~# ls -la /etc/ssl/certs | grep ldap. -rw------- 1 openldap openldap 1424 Feb 25 08:13 ldap.intern.example.com.crt.pem -rw------- 1 openldap openldap 1330 Feb 25 09:00 ManagementCA.cacert.pem ... Why am I not getting the key and cert file added? How do I get the olcTLSCACertificateFile deleted again? Thank you for your help. Greetings from Stefan Harbich

2 years, 1 month

1
0
0 / 0

LDAP-proxy with meta-backend

by Stefan Kania

Hi, I would like to set up a OpenLDAP proxy with meta-backend. I have a test environment with two windows 2019 ADs and one OpenLDAP-server configured as proxy. At the beginning all the authentication are med with admin-accounts, it's the first step just testing. Here is my slapd.conf: ----------------------- Include /etc/ldap/schema/core.schema Include /etc/ldap/schema/corba.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/java.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/collective.schema include /etc/ldap/schema/pmi.schema include /etc/ldap/schema/ppolicy.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args # Load dynamic backend modules: modulepath /usr/lib/ldap moduleload rwm.la moduleload back_meta.la moduleload back_ldap.la loglevel 4095 ####################################################################### # MDB database definitions ####################################################################### database meta suffix "dc=example,dc=de" rootdn "cn=admin,dc=example,dc=de" rootpw secret uri "ldap://192.168.56.201/ou=firma-01,dc=example,dc=de" readonly yes lastmod off suffixmassage "ou=firma-01,dc=example,dc=de" "ou=firma-01,dc=dom01,dc=example,dc=net" map attribute uid sAMAccountName idassert-bind bindmethod=simple binddn="cn=administrator,cn=Users,dc=dom01,dc=example,dc=net" credentials="Passw0rd" idassert-authzFrom "*" uri "ldap://192.168.56.202/ou=firma-02,dc=example,dc=de" readonly yes lastmod off suffixmassage "ou=firma-02,dc=example,dc=de" "ou=firma-02,dc=dom02,dc=example,dc=com" map attribute uid sAMAccountName idassert-bind bindmethod=simple binddn="CN=Administrator,CN=Users,DC=dom02,dc=example,DC=com" credentials="Passw0rd" idassert-authzFrom "*" ----------------------- on my proxy I can do a "ldapsearch -x " and I can see all the wanted entries from both ADs. This is my ldap.conf on the proxy: ----------------------- BASE dc=example,dc=de URI ldap://192.168.56.210 ----------------------- 192.168.56.210 is my proxy. But now I would like to connect a client to the proxy to get the entries. The ldap.conf file is the same as on the proxy. But what ever I try I got now result. ---------------------- root@proxy-client:~# ldapsearch -x -D cn=admin,dc=example,dc=de -W -LLL No such object (32) root@proxy-client:~# ldapsearch -x -LLL No such object (32) ---------------------- What am I missing? Thank's for any help Stefan

2 years, 1 month

2
2
0 / 0

A bit of help for a master migration.

by Frédéric Goudal

Hello, I’m in the way to replace our main ldap server with the moe nest recent version. As the OS of the current one is quite old we will host it on a new computer. For now the architecture is the following : master-ldap with two local replica via syncprov and another replica with a proxy sync (suffix on the master with a ldap backend) so we jump the internal firewall. The master-ldap is the only one in read/write so all the modifications are done here. What I plan is the following : - add the new ldap server - setup a multi-master replication with the old master - move the replica from the old one to the new one - move the write operations from the old one to the new one - disconnect the old one. Does anybody see a flaw in this plan ? f.g.

2 years, 1 month

1
0
0 / 0

Re: Replication in MMR setup

by Quanah Gibson-Mount

--On Monday, February 8, 2021 10:26 PM -0800 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > > Hi, > > > In an MMR setup (between two servers) if contextCSN on both the servers > is the same, are there any chances that entries count can still differ? Yes, if you started with an older version of OpenLDAP than 2.4.57, and if you use standard syncrepl, and/or you've hit a REFRESH. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 years, 1 month

1
0
0 / 0

Converting OpenLDAP schema to Active Directory LDF

by Kevin Olbrich

Hi! Is there any known tool to help with converting an openldap schema to AD LDF / LDIF? I need to integrate FreeRADIUS (extended attributes) directly into AD: https://github.com/FreeRADIUS/freeradius-server/blob/master/doc/schemas/l... In the past, I just created the attributes one by one using the schema manager on windows with values matching the original schema as much as possible. Can this be simplified? Thank you! Kind regards Kevin

2 years, 1 month

1
0
0 / 0

Caching proxy (slapo-pcache) - configuration to cache everything?

by Harsh, Daniel (NonEmp)

Hello, I am looking to configure OpenLDAP as a caching proxy to a non-OpenLDAP backend. The idea is to deploy this proxy in various sites that may have spotty network connectivity to provide some level of availability should the upstream LDAP service be unavailable. Unfortunately, my requirements preclude a more elegant solution using replication/sync, so the next best idea I can come up with is a caching proxy idea. Is it possible to configure the proxy to cache all queries without having to define separate pcacheTemplate directives for each possible search filter that a client could use? Regards, Dan ________________________________ This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

2 years, 1 month

1
0
0 / 0

How to restrict access to operational attributes?

by Uwe Sauter

Good morning, I'm trying to restrict access to the operational attributes that are provided by the ppolicy overlay (e.g. pwdChangedTime, pwdHistory). When I add the following to my ACL configuration file and try to verify the configuration an error occurs: #### ACL access to attrs=pwdHistory by * none ######## #### slaptest output 601cf554 /etc/openldap/acl.conf: line 96: unknown attr "pwdHistory" in to clause 601cf554 <access clause> ::= access to <what> [ by <who> [ <access> ] [ <control> ] ]+ <what> ::= * | dn[.<dnstyle>=<DN>] [filter=<filter>] [attrs=<attrspec>] <attrspec> ::= <attrname> [val[/<matchingRule>][.<attrstyle>]=<value>] | <attrlist> <attrlist> ::= <attr> [ , <attrlist> ] <attr> ::= <attrname> | @<objectClass> | !<objectClass> | entry | children <who> ::= [ * | anonymous | users | self | dn[.<dnstyle>]=<DN> ] [ realanonymous | realusers | realself | realdn[.<dnstyle>]=<DN> ] [dnattr=<attrname>] [realdnattr=<attrname>] [group[/<objectclass>[/<attrname>]][.<style>]=<group>] [peername[.<peernamestyle>]=<peer>] [sockname[.<style>]=<name>] [domain[.<domainstyle>]=<domain>] [sockurl[.<style>]=<url>] [dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]] [ssf=<n>] [transport_ssf=<n>] [tls_ssf=<n>] [sasl_ssf=<n>] <style> ::= exact | regex | base(Object) <dnstyle> ::= base(Object) | one(level) | sub(tree) | children | exact | regex <attrstyle> ::= exact | regex | base(Object) | one(level) | sub(tree) | children <peernamestyle> ::= exact | regex | ip | ipv6 | path <domainstyle> ::= exact | regex | base(Object) | sub(tree) <access> ::= [[real]self]{<level>|<priv>} <level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+ <control> ::= [ stop | continue | break ] dynacl: <name>=ACI <pattern>=<attrname> slaptest: bad configuration file! #################### My questions: * How can I restrict access to operational attributes? Does this depend on the specific overlay? * Is this a bug in the ppolicy overlay? One might consider the pwd* attributes confidential but at the same time allowing anonymous queries might be necessary. * Is there anything I miss (besides still using configuration files – they are way easier to handle)? Best, Uwe

2 years, 1 month

5
13
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical February 2021