openldap-technical September 2021

openldap-technical@openldap.org

25 participants
35 discussions

Question mark (?) in search filters
by Ángel L. Mateo Martínez 21 Sep '21

21 Sep '21

Hello, I'm configuring an application using my openldap and I'm seeing queries I didn't know them before. The queries are like this: filter="(|(objectClass=groupOfNames)(?objectClass=container)(objectClass=organization)(objectClass=organizationalUnit)(objectClass=domain)(?objectClass=domaincomponent)(?objectClass=builtinDomain))" This may be the first time I see the ? in the search filter of a query. But when I try to reproduce it with ldapsearch command I get: $ ldapsearch '(|(objectClass=groupOfNames)(?objectClass=container)(objectClass=organization)(objectClass=organizationalUnit)(objectClass=domain)(?objectClass=domaincomponent)(?objectClass=builtinDomain))' # extended LDIF # # LDAPv3 # base <dc=Telematica> (default) with scope subtree # filter: (|(objectClass=groupOfNames)(?objectClass=container)(objectClass=organization)(objectClass=organizationalUnit)(objectClass=domain)(?objectClass=domaincomponent)(?objectClass=builtinDomain)) # requesting: ALL # ldap_search_ext: Bad search filter (-7) I guess the problem in the query is because of the '?' operator. So, how can I reproduce it with ldapsearch? And... what does this '?' mean? Thanks, --- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868889150 Fax: 868888337

2 1

Re: Is there significance in overlay order in replicated environment
by Saša-Stjepan Bakša 20 Sep '21

20 Sep '21

> > > Yes, it matters. Syncprov first, then accesslog. After that order should > be immaterial. > > I would note that in OpenLDAP 2.5, a bit of the lastbind functionality has > been integrated into slapd so you may not need to deploy it separately. > > --Quanah > > > I thought so but wasn't sure. Thank you for your confirmation. Lastbind functionality integrated partially? Nice! Where can I find documentation about it or a description on how to extract data for each user? Saša

2 1

Syncrepl failing after a while
by Mircea Baciu 20 Sep '21

20 Sep '21

Hi, I have an issue with a consumer replication starting to fail until OpenLDAP is restarted. My setup consists of a pair of on-prem MirrorMode replicated providers (only one is active at a given time using a virtual IP managed by Keepalived), and one off-site (AWS) consumer. The providers use a dedicated port (LDAPS on 1636) for their own replication, as well as for the consumer to connect to them, so the consumer has access to both servers, regardless of where the providers' virtual IP is residing. All the connections happen over LDAPS, and the syncrepl configs have the tls_reqcert=allow option. The providers are always in sync and I'm able to switch make one or the other one the "active" one with ease. The consumer does the initial sync and stays in sync for a while, but I find it often (almost daily) out of sync. I see error messages on both the consumer and provider side: On the consumer (every minute): Sep 20 08:19:31 <consumer> slapd[1440]: slap_client_connect: URI=ldaps://<provider1>:1636/ DN="uid=replication,ou=sysaccounts,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 20 08:19:31 <consumer> slapd[1440]: do_syncrepl: rid=001 rc -1 retrying Sep 20 08:19:31 <consumer> slapd[1440]: slap_client_connect: URI=ldaps://<provider2>:1636/ DN="uid=replication,ou=sysaccounts,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 20 08:19:31 <consumer> slapd[1440]: do_syncrepl: rid=002 rc -1 retrying Sep 20 08:20:31 <consumer> slapd[1440]: slap_client_connect: URI=ldaps://<provider1>:1636/ DN="uid=replication,ou=sysaccounts,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 20 08:20:31 <consumer> slapd[1440]: do_syncrepl: rid=001 rc -1 retrying Sep 20 08:20:31 <consumer> slapd[1440]: slap_client_connect: URI=ldaps://<provider2>:1636/ DN="uid=replication,ou=sysaccounts,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 20 08:20:31 <consumer> slapd[1440]: do_syncrepl: rid=002 rc -1 retrying On the provider (every minute): Sep 20 08:19:31 <provider1> slapd[1057]: conn=11242 fd=14 ACCEPT from IP=<consumer IP>:45438 (IP=<provider1 IP>:1636) Sep 20 08:19:31 <provider1> slapd[1057]: conn=11242 fd=14 TLS established tls_ssf=256 ssf=256 Sep 20 08:19:31 <provider1> slapd[1057]: conn=11242 fd=14 closed (connection lost) Sep 20 08:20:31 <provider1> slapd[1057]: conn=11243 fd=14 ACCEPT from IP=<consumer IP>:45458 (IP=<provider1 IP>:1636) Sep 20 08:20:31 <provider1> slapd[1057]: conn=11243 fd=14 TLS established tls_ssf=256 ssf=256 Sep 20 08:20:31 <provider1> slapd[1057]: conn=11243 fd=14 closed (connection lost) Sep 20 08:19:31 <provider2> slapd[1051]: conn=215893 fd=18 ACCEPT from IP=<consumer IP>:41706 (IP=<provider2 IP>:1636) Sep 20 08:19:31 <provider2> slapd[1051]: conn=215893 fd=18 TLS established tls_ssf=256 ssf=256 Sep 20 08:19:31 <provider2> slapd[1051]: conn=215893 fd=18 closed (connection lost) Sep 20 08:20:31 <provider2> slapd[1051]: conn=215898 fd=18 ACCEPT from IP=<consumer IP>:41726 (IP=<provider2 IP>:1636) Sep 20 08:20:31 <provider2> slapd[1051]: conn=215898 fd=18 TLS established tls_ssf=256 ssf=256 Sep 20 08:20:31 <provider2> slapd[1051]: conn=215898 fd=18 closed (connection lost) There must be something wrong on the consumer side since when the issue starts, the consumer is not able to connect to either provider. Once I restart the consumer, it quickly resyncs and works just fine, for a while. The providers are OpenLDAP 2.4.44 (openldap-2.4.44-24.el7_9.x86_64), running on RHEL 7. The consumer is OpenLDAP 2.4.44 (openldap-2.4.44-24.el7_9.x86_64), running on CentOS 7. The consumer syncrepl config is: olcSyncrepl: {0}rid=001 provider=ldaps://<provider1>:1636/ searchbase="dc=example,dc=com" type=refreshAndPersist retry="60 +" timeout=1 bindmethod=simple binddn="uid=replication,ou=SysAccounts,dc=example,dc=com" credentials=<credentials> tls_reqcert=allow olcSyncrepl: {1}rid=002 provider=ldaps://<provider1>:1636/ searchbase="dc=example,dc=com" type=refreshAndPersist retry="60 +" timeout=1 bindmethod=simple binddn="uid=replication,ou=SysAccounts,dc=example,dc=com" credentials=<credentials> tls_reqcert=allow The "uid=replication,ou=SysAccounts,dc=example,dc=com" DN has full read-only permissions for the entire "dc=example,dc=com" tree. Any idea on what might be my issue here? Thank you, Mircea -- Mircea Baciu | Senior Unix Systems Administrator Simmons University | 300 The Fenway | Boston, MA 02115 | 617-521-2194

3 3

Re: Syncrepl failing after a while
by Mircea Baciu 20 Sep '21

20 Sep '21

Thank you, Quanah, I didn't know about the "keepalive" option for syncrepl. Now that you mentioned, I found some old 2017 discussion on this list with a very similar issue I have, where you mentioned this option. I see it in the slapd manual page but not on 2.4 (or 2.5) admin site: https://www.openldap.org/doc/admin24/replication.html I'll try adding it to the config and will definitely consider upgrading to a newer version in some fashion. Thanks, Mircea -- Mircea Baciu | Senior Unix Systems Administrator Simmons University | 300 The Fenway | Boston, MA 02115 | 617-521-2194 On Mon, Sep 20, 2021 at 11:12 AM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Monday, September 20, 2021 11:38 AM -0400 Mircea Baciu > <mircea.baciu(a)simmons.edu> wrote: > > > > The providers are OpenLDAP 2.4.44 (openldap-2.4.44-24.el7_9.x86_64), > > running on RHEL 7. > > The consumer is OpenLDAP 2.4.44 (openldap-2.4.44-24.el7_9.x86_64), > > running on CentOS 7. > > > Hello, > > The OpenLDAP 2.4.44 release is over 5 years old and numerous replication > related issues have been fixed since that time. Additionally, RedHat is > known to have made questionable modifications to libldap, particularly > around the TLS layer in RHEL7. > > I'd strongly advise you to upgrade to a current release of OpenLDAP. I > would note that Symas provides free drop-in replacement builds of OpenLDAP > for RHEL7 with optional support available > (<https://repo.symas.com/sofl/rhel7/>). > > Symas also provides free builds of the current OpenLDAP release series > (2.5) with optional support available > (<https://repo.symas.com/soldap/rhel7/>). > > I'd also note that your syncrepl stanza is missing the "keepalive" option, > which is usually essential when dealing with traffic through load > balancers. > > Regards, > Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Is there significance in overlay order in replicated environment
by Saša-Stjepan Bakša 20 Sep '21

20 Sep '21

Hi, I am moving my old LDAP setup which is now more than 8 years old to version 2.5.7 (Symas Ubuntu build). Now I use simple Master -> backup only sync configuration. On those systems I also use accesslog overlay. On new systems I would like to deploy a multi master with delta sync or maybe pure multi master since it is a small database with only few hundreds users. I have been using multi master on other systems for years without any (many) problems and those systems have more that 500 k users. Also I would like to use accesslog and lastbind overlays and maybe some other overlays in the future. My question is is there significance in which order I will add overlays to databases? Syncprov first then others or it does not have any impact. Br Saša

2 1

OpenLDAP 2.6.0 testing call
by Quanah Gibson-Mount 16 Sep '21

16 Sep '21

This is the first testing call for OpenLDAP 2.6.0 Release. Depending on the results, this may be the only testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. A list of items fixed and added in 2.6 can be found at: <https://bugs.openldap.org/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFI…> A major change with 2.6 is the ability to bypass syslog for logging (ITS#6949). This significantly improves slapd performance. Currently this is being adjusted so that lloadd also supports this new feature, but it can be tested with slapd at this time. Additionally, the following deprecated backends have been removed: back-ndb back-shell Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 14

How to create an entry, which is not returned on SEARCH
by Дилян Палаузов 15 Sep '21

15 Sep '21

Hello, How can I create an entry (in terms of ldif/ldapadd/ldapmodify), which is not returned on searches (apart from tweaking the olcAccess rules? https://www.openldap.org/devel/admin/replication.html says: > Because a general search filter can be used in the syncrepl specification, some entries in the context may be omitted from the synchronization content. The syncrepl engine creates a glue entry to fill in the holes in the replica context if any part of the replica content is subordinate to the holes. The glue entries will not be returned in the search result unless ManageDsaIT control is provided. Rationale: I want to create a directory, containing contacts under: cn=juridical persons,dc=me cn=natural persons,dc=me The LDAP clients shall query base dc=me with scope SUB. The LDAP clients shall see all subentries of Juridical Persons and all subentries of Natural Persons, but not the cn=juridical persons,dc=me cn=natural persons,dc=me and dc=me entries itself. As the latter entries do not represent Contacts (mail, phone, address), the entries shall not appear in address books. Greetings Дилян

3 2

openldap and oauth2
by Stefan Kania 14 Sep '21

14 Sep '21

Hello to all, short question. Is OpenLDAP supporting oauth2? If yes, can some one point me to a howto? Stefan

2 1

Checking synchronization status into cn=monitor in OpenLDAP 2.5
by David Coutadeur 08 Sep '21

08 Sep '21

Hi, I am trying to get the synchronization status of a given consumer for each of his declared provider. Synchronization status = Is this provider synchronized with the current consumer? (TRUE / FALSE) Currently, I can do that by comparing contextCSN stored into consumers and providers. I have noted that in OpenLDAP 2.5 there are new piece of information into cn=monitor: |dn: cn=Consumer 000,cn=Database 1,cn=Databases,cn=Monitor objectClass: olmSyncReplInstance structuralObjectClass: olmSyncReplInstance cn: Consumer 000 creatorsName: cn=monitor modifiersName: cn=monitor createTimestamp: 20210908075111Z modifyTimestamp: 20210908075111Z olmSRProviderURIList: ldap://localhost:3389 olmSRConnection: IP=127.0.0.1:40908 olmSRSyncPhase: Persist olmSRNextConnect: 00000101000000Z olmSRLastConnect: 20210908075211Z olmSRLastContact: 20210908082522Z olmSRLastCookieRcvd: rid=000,csn=20210908082522.652290Z#000000#000#000000 olmSRLastCookieSent: rid=000,sid=000,csn=20210907161949.876119Z#000000#000#000 000 entryDN: cn=Consumer 000,cn=Database 1,cn=Databases,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: FALSE| 1/ I haven't found any documentation about these attributes in OpenLDAP manual. Is there something in progress ? 2/ if I understand correctly the meaning of olmSRLastCookieRcvd, it should be the best candidate for computing the synchronization status. However, this attribut is empty at OpenLDAP startup, so I can't really rely on it. Do anyone see other means to get the synchronization status? Regards, David

2 1

Re: OpenLDAP 2.6.0 testing call
by Nick Folino 07 Sep '21

07 Sep '21

No issues on Fedora 34. Any docs on how to work with the new logging options? Nick On Tue, Sep 7, 2021 at 1:01 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > This is the first testing call for OpenLDAP 2.6.0 Release. Depending on > the results, this may be the only testing call. > > Generally, get the code for RE26: > > < > https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o… > > > > Extract, configure, and build. > > Execute the test suite (via make test) after it is built. Optionally, cd > tests && make its to run through the regression suite. > > A list of items fixed and added in 2.6 can be found at: > > < > https://bugs.openldap.org/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFI… > > > > A major change with 2.6 is the ability to bypass syslog for logging > (ITS#6949). This significantly improves slapd performance. Currently > this > is being adjusted so that lloadd also supports this new feature, but it > can > be tested with slapd at this time. > > Additionally, the following deprecated backends have been removed: > > back-ndb > back-shell > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2021