openldap-technical

openldap-technical@openldap.org

2 participants
9852 discussions

Re: Antw: [EXT] Re: slow memberOf queries in 2.5 with dynlist overlay
by Paul B. Henson 03 Jun '22

03 Jun '22

On 5/30/2022 11:53 PM, Ulrich Windl wrote: > I wonder: Would forcing a core dump help in that situation, or would a > gprof-compile be helpful? Unfortunately I can't reproduce it; it just happens randomly on my production boxes, less frequently since I increased the amount of memory on them. I'm not sure I could run a debug or profiling build in production for an extended amount of time waiting for it to happen. And with my luck it would be a heisenbug anyway 8-/. > Maybe one could track down the page fault to some code (function) using tools > from the valgrind family (Cachegrind, callgrind, etc.) > http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.va…

1 0

OpenLDAP 2.6.2 on RHEL8: add password policy
by Real Villafan, Elizabeth (US 392K) 01 Jun '22

01 Jun '22

Hello, I'm upgrading from openldap 2.4 running on RHEL7 up to 2.6.2 and RHEL8 on new hardware, apparently the way to configure password policy now is by configuring the slapd.conf file rather than loading the ppolicy schema. How do I modify that file properly? I read https://www.openldap.org/doc/admin26/overlays.html#Password%20Policies on section 12.10.2. Password Policy Configuration, what does it mean to "Instantiate the module in the database"? do you have a sample slapd.conf file I can refer to? Thank you, Liz

2 3

2.5 LTS release with OpenSSL 3.0
by barry.greenberg＠oracle.com 01 Jun '22

01 Jun '22

Is there any information about the release of OpenLDAP 2.5.x that includes support for OpenSSL 3.0? I see that it's now supported in 2.6.2 but we'd prefer to stay on the 2.5 branch for the foreseeable future. Thanks.

1 0

slow memberOf queries in 2.5 with dynlist overlay
by Paul B. Henson 30 May '22

30 May '22

I'm still trying to figure out why my servers sometimes get into a state where queries requesting the memberOf attribute take an exceedingly long time to process, for example: Feb 13 19:46:05 ldap-02 slapd[13564]: conn=297643 fd=104 ACCEPT from PATH=/var/symas/run/ldapi (PATH=/var/symas/run/ldapi) Feb 13 19:46:05 ldap-02 slapd[13564]: conn=297643 op=0 BIND dn="cn=ldaproot,dc=cpp,dc=edu" method=128 Feb 13 19:46:05 ldap-02 slapd[13564]: conn=297643 op=0 BIND dn="cn=ldaproot,dc=cpp,dc=edu" mech=SIMPLE bind_ssf=0 ssf=71 Feb 13 19:46:05 ldap-02 slapd[13564]: conn=297643 op=0 RESULT tag=97 err=0 qtime=0.000006 etime=0.000050 text= Feb 13 19:46:05 ldap-02 slapd[13564]: conn=297643 op=1 SRCH base="dc=cpp,dc=edu" scope=2 deref=0 filter="(uid=henson)" Feb 13 19:46:05 ldap-02 slapd[13564]: conn=297643 op=1 SRCH attr=memberOf Feb 13 19:46:42 ldap-02 slapd[13564]: conn=297643 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000012 etime=36.955710 nentries=1 text= How is the qtime calculated? It is nice and short, despite the wall clock reading over 30 seconds :(. Usually I have to reboot the server completely to clear this up, but this time I just had to restart it, and then the queries were lickity split again: Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 fd=40 ACCEPT from PATH=/var/symas/run/ldapi (PATH=/var/symas/run/ldapi) Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 op=0 BIND dn="cn=ldaproot,dc=cpp,dc=edu" method=128 Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 op=0 BIND dn="cn=ldaproot,dc=cpp,dc=edu" mech=SIMPLE bind_ssf=0 ssf=71 Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 op=0 RESULT tag=97 err=0 qtime=0.000009 etime=0.000088 text= Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 op=1 SRCH base="dc=cpp,dc=edu" scope=2 deref=0 filter="(uid=henson)" Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 op=1 SRCH attr=memberOf Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000013 etime=0.213149 nentries=1 text= Over 30 seconds elapsed time to .2 seconds? I'd like to see the .2 all the time :). When the server gets like this, there's a very high read IO load, 200-300Mb/s, compared to generally less than 1Mb/s when things are working right. It almost seems like it's doing a full disk scan searching for members every time. Any suggestions on what to dig into? Thanks...

5 16

rewriting non-DN attribute values with rwm?
by Kartik Subbarao 29 May '22

29 May '22

I'd like to rewrite the following entry: dn: uid=user(a)olddomain.com,dc=olddomain,dc=com uid: user(a)olddomain.com mail: user(a)olddomain.com to appear and behave like this: dn: uid=user(a)newdomain.com,dc=newdomain,dc=com uid: user(a)newdomain.com mail: user(a)newdomain.com I can get the DN rewritten with slapd-relay and rwm-suffixmassage, and can use rwm-rewriterule with the searchFilter and searchEntryDN contexts to return the entry when querying for mail=user(a)newdomain.com. But I can't figure out how to rewrite the *values* of the uid and mail attributes in the returned entry to user(a)newdomain.com. What is the best way to achieve this? Thanks, -Kartik

2 2

result not in cache
by Stefan Kania 29 May '22

29 May '22

I'm testing the openldap cache module pcache with OpenLDAP 2.6 on Debian11 (symas-packages). The proxy has the following config: (I'm testing caching so no security is set) -------------- include /opt/symas/etc/openldap/schema/core.schema include /opt/symas/etc/openldap/schema/cosine.schema include /opt/symas/etc/openldap/schema/nis.schema include /opt/symas/etc/openldap/schema/inetorgperson.schema pidfile /var/symas/run/slapd.pid argsfile /var/symas/run/slapd.args loglevel any modulepath /opt/symas/lib/openldap moduleload back_mdb.la moduleload argon2.la moduleload back_ldap moduleload pcache sizelimit 500 tool-threads 1 database ldap suffix "dc=example,dc=net" uri "ldap://ldap-server.example.net" rootdn "cn=admin,dc=example,dc=net" protocol-version 3 rebind-as-user overlay pcache pcachePersist TRUE pcache mdb 100000 2 1000 100 pcacheAttrset 0 mail postaladdress telephonenumber givenname pcacheAttrset 1 uid employeetype pcacheTemplate (sn=) 0 3600 pcacheTemplate (&(sn=)(givenName=)) 0 3600 pcacheTemplate (&(departmentNumber=)(secretary=*)) 0 3600 directory /var/symas/cache index objectclass eq index uid,cn,sn,mail,givenname pres,eq,sub -------------- The following host are involved: ldap-server<----->ldap-proxy<----->ldap-client The ldap-client can only access the ldap-proxy. (ldap.conf ist pointing to the ldap-proxy) Now I do a: ldapsearch -x '(&(sn=Kania)(givenName=Stefan))' givenname The first time I can see that the proxy is asking the ldap-server and is giving the result to the ldap-client. Each time I repeat the command on the ldap-client, only the log from the ldap-proxy is showing the access from the ldap-client. The ldap-client is getting the result from the proxy. I can even shutdown the ldap-server and the client is still getting the result from the proxy. Up to this point I understand the log but if I set "loglevel any" I see: ------------ access_allowed: result not in cache (givenName) ------------ But I think the result IS in the cache otherwise I would not get the result with the ldap-server turned off. So why do I get this messages?

2 1

Made a change to cn=schema,cn=config, can't revert?
by Sander Smeenk 25 May '22

25 May '22

Hi, I'm trying to add an 'olcAttributeType' to an already existing LDAP schema. I wrote this LDIF, which was wrong as it turns out: | dn: cn=schema,cn=config | changetype: modify | add: olcAttributetypes | olcAttributetypes: ( bitHttpAttribute:26.2008.07.29.1 NAME | 'testEntry' DESC 'Test' EQUALITY integerMatch SYNTAX | LDAPInteger SINGLE-VALUE ) This changed my 'dn: cn=schema,cn=config' from: | dn: cn=schema,cn=config | objectClass: olcSchemaConfig | cn: schema | structuralObjectClass: olcSchemaConfig | entryUUID: 9faa0e66-41f5-1032-82e1-974d55020d34 | creatorsName: cn=config | createTimestamp: 20130425131311Z | entryCSN: 20130425131311.204787Z#000000#000#000000 | modifiersName: cn=config | modifyTimestamp: 20130425131311Z To: | dn: cn=schema,cn=config | objectClass: olcSchemaConfig | cn: schema | structuralObjectClass: olcSchemaConfig | entryUUID: 9faa0e66-41f5-1032-82e1-974d55020d34 | creatorsName: cn=config | createTimestamp: 20130425131311Z | olcAttributeTypes: {0}( bitHttpAttribute:26.2008.07.29.1 NAME | 'testEntry' DESC 'Test' EQUALITY integerMatch SYNTAX | LDAPInteger SINGLE-VALUE ) | entryCSN: 20220525132055.795116Z#000000#000#000000 | modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth | modifyTimestamp: 20220525132055Z Which is not what i wanted but it happened, so now i want it gone. But it seems i can't remove that olcAttributeTypes entry? This LDIF won't work: | dn: cn=schema,cn=config | changetype: modify | delete: olcAttributeTypes Yielding: | # ldapmodify -Y EXTERNAL -H ldapi:/// -f kak.ldif | [..] | modifying entry "cn=schema,cn=config" | ldap_modify: Other (e.g., implementation specific) error (80) When i put in the exact olcAttributeType line i want to remove (instead of all of 'em) like this: | dn: cn=schema,cn=config | changetype: modify | delete: olcAttributeTypes | olcAttributeTypes: ( bitHttpAttribute:26.2008.07.29.1 NAME 'testEntry' DESC 'Test' EQUALITY integerMatch SYNTAX LDAPInteger SINGLE-VALUE ) Now the same ldapmodify command yields: | # ldapmodify -Y EXTERNAL -H ldapi:/// -f kak.ldif | [..] | modifying entry "cn=schema,cn=config" | ldap_modify: Operations error (1) Can anyone explain what i am doing wrong and how to revert my change to the 'cn=schema,cn=config' dn? Thanks a bunch! Regards, -Sander. -- | I did a theatrical performance about puns. It was a play on words. | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2

2 3

consumer state is newer than provider
by Rallavagu Kon 24 May '22

24 May '22

Hello All, Running OpenLDAP version 2.4.58 on Ubuntu 20.04 in multicaster mode. Replication Configuration: olcSyncrepl: {0}rid=101 provider=ldaps://<host1>:10636 binddn="<binddn>" bindm ethod=simple credentials=<creds> searchbase="dc=company,dc=com" type =refreshAndPersist interval=00:00:00:30 retry="5 5 60 +" timeout=1 keepalive= "240:10:30" olcSyncrepl: {1}rid=102 provider=ldaps://<host2>:10636 binddn="<binddn>" bindm ethod=simple credentials=<creds> searchbase="dc=company,dc=com" type =refreshAndPersist interval=00:00:00:30 retry="5 5 60 +" timeout=1 keepalive= "240:10:30" olcSyncrepl: {2}rid=103 provider=ldaps://<host3>:10636 binddn="<binddn>" bindm ethod=simple credentials=<creds> searchbase="dc=company,dc=com" type =refreshAndPersist interval=00:00:00:30 retry="5 5 60 +" timeout=1 keepalive= "240:10:30" olcSyncrepl: {3}rid=104 provider=ldaps://<host4>:636 binddn="<binddn>" bindmethod=si mple credentials=<creds> searchbase="dc=company,dc=com" type=refresh AndPersist interval=00:00:00:30 retry="5 5 60 +" timeout=1 keepalive="240:10: 30" olcMirrorMode: TRUE # {1}syncprov, {2}mdb, config dn: olcOverlay={1}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpCheckpoint: 100 10 Under normal conditions, all operations perform normally in terms of replication consistency. However, when performing a stream of “ADD” operations eventually producer/consumer go out of sync where consumer thinks it has latest state than producer. All the write operations including ADD are pointed to a producer node (not load balancing the writes). Introduced 30 second delay to “ADD” operations (for the sake of testing) and experiencing the same behavior. The issue is manifesting after adding around 4k entries (sometimes even sooner). Here are the log snippets. May 4 23:06:47 openldap-service-0 slapd[199]: do_syncrep2: rid=102 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform May 4 23:06:47 openldap-service-0 slapd[199]: do_syncrep2: rid=102 (53) Server is unwilling to perform May 4 23:06:37 openldap-service-1 slapd[199]: conn=1046 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Checked for the clock synchronization and verified that all instances have NTP enabled. Wondering where and what I should be looking for. Thanks in advance.

2 3

slapo-syncprov on read-only consumers
by Michael Ströder 21 May '22

21 May '22

HI! Is it still highly recommended to configure slapo-syncprov on read-only consumers? Background: I have a tier of read-only consumers with "lastbind on" and slapo-ppolicy configured, but no chaining to the writeable providers (e.g. no ppolicy_forward_updates). All providers and consumers are 2.6.2. In case of a simple bind to this read-only consumer it makes local modification to the user's entry (pwdFailureTime and pwdLastSuccess) and it's ok for me that this is local to this consumer. But with slapo-syncprov configured on the consumer slapd generates a new entryCSN with server ID 0 which results in a contextCSN value with SID 0. This is what I'd like to avoid. Hence my above question. Ciao, Michael.

1 0

Query on CVE-2022-29155
by Venkat Kandhari -X (khvenkat - INFOSYS LIMITED＠Cisco) 18 May '22

18 May '22

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical