openldap-technical

openldap-technical@openldap.org

14 participants
9795 discussions

Re: help with mdb database recovery after crash
by Andrei Mikhailovsky 08 Feb '19

08 Feb '19

Thanks everyone for their contribution. I will follow the suggestions over the weekend and update the list on the progress. Kind regards ----- Original Message ----- > From: "Enes Kıdık" <enes.kidik(a)pardus.org.tr> > To: "Andrei Mikhailovsky" <andrei(a)arhont.com> > Sent: Thursday, 7 February, 2019 10:01:00 > Subject: Re: help with mdb database recovery after crash > Hello Andrei, > I am not posting this to openldap maillist but It may be useful to you. > > 3 years ago I was working on zimbra collaboration and had hard times with those > sparse files. > I found the links I read. Your situation seems different from mine but take a > shot. > > you may want to search how to copy an old backup of zimbra sparse file to new > location (after using mdb_copy copied file is no longer a a sparse file so > there may be another way like slapcat-slapadd) > https://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning_8.0 > https://www.openldap.org/lists/openldap-technical/201305/msg00229.html > https://linuxacademy.com/blog/linux/openldap-fixing-or-recovering-a-corrupt… > > Quannah is ldap-guru. He may give you a specific answer to solve your problem. > > Have a good day. I hope you solve it quickly. > Enes > > ----- Original Message ----- > From: "Howard Chu" <hyc(a)symas.com> > To: "Andrei Mikhailovsky" <andrei(a)arhont.com>, openldap-technical(a)openldap.org > Sent: Thursday, February 7, 2019 5:42:40 AM > Subject: Re: help with mdb database recovery after crash > > Andrei Mikhailovsky wrote: >> Hello everyone, >> >> I have a bit of an issue with my ldap database. I have a Zimbra community >> edition which uses openldap. A server crashed and I am unable to start the ldap >> services after the reboot. The description of my problem, after some digging >> about is: >> >> >> the initial error indicated problem with the ldap >> >> Starting ldap...Done. >> Search error: Unable to determine enabled services from ldap. >> Enabled services read from cache. Service list may be inaccurate. >> >> Having investigated the issue, I noticed the following errors in the zimbra.log >> >> *slapd[31281]: mdb_entry_decode: attribute index 560427631 not recognized* >> >> I also noticed that the /opt/zimbra/data/ldap/mdb/db/data.mdb is actually 81Gb >> in size and had reached the limit imposed by the ldap_db_maxsize variable. so >> over the weekend, the LDAP mdb file became no longer sparse. >> >> I tried following the steps described in >> https://syslint.com/blog/tutorial/solved-critical-ldap-primary-mdb-database… >> but with no success, as the slapcat segfaults with the following message. >> >> >> /opt/zimbra/common/sbin/slapcat -ccc -F /opt/zimbra/data/ldap/config -b "" -l >> /opt/zimbra/RECOVERY/SLAPCAT/zimbra_mdb.ldiff >> 5c583982 mdb_entry_decode: attribute index 560427631 not recognized >> Segmentation fault (core dumped) >> >> the mdb_copy produces a file of 420 mb in size, but it still contains the >> "mdb_entry_decode: attribute index 560427631 not recognized" error. >> I've also tried mdb_dump, but had the same issues after using the mdb_load >> command. >> >> I found a post ( http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8360 ) >> in the openldap community that the mdb gets corrupted if it reaches the maximum >> defined size. but no solution of how to fix it. > > That's from over 3 years ago and has subsequently fixed. If you're running on > such an old > release, there's likely not much that can be done. Ordinarily it's possible to > back up to > the immediately preceding transaction, in case the last transaction is > corrupted, but with > that particular bug it's likely that the corruption occurred in an earlier > transaction > and has been carried forward in all subsequent ones. >> >> any advice on getting the database recovered and working again? > > You could try using the preceding transaction and see if it's in any better > shape. The code > for this is not released in LMDB 0.9. You can compile the mdb.master branch in > git to obtain > it. Then use the "-v" option with mdb_copy and see if that copy of the database > is usable. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Locking down ciphers in OpenLDAP with GnuTLS
by Philip Colmer 08 Feb '19

08 Feb '19

I want to restrict the cipher suites used in OpenLDAP so that only TLS1.2 is supported. Looking at https://openldap.org/doc/admin24/tls.html, I first tried setting olcTLSCipherSuite to "HIGH" but the LDAP server gave an error 80 and then stopped accepted further connections until I restarted it. Since our OpenLDAP installation has been built with GnuTLS, I'm presuming that I have to explicitly list out the GnuTLS cipher suites I want to use. I've used gnutls-cli to list out the cipher suites that support PFS and then extracted the ones that are TLS1.2. So, just to confirm, do I need to provide a colon-separated list of each and every cipher suite or is there a GnuTLS shorthand that I can use? Regards Philip

3 4

[Q] RFC2307bis2 "An Approach for Using LDAP as a Network Information Service"
by Zeus Panchenko 07 Feb '19

07 Feb '19

greetings, We've found RFC2307bis2: "An Approach for Using LDAP as a Network Information Service" and now wondering, what've happened to it finally? Is it just expired and forgotten? Recently we've began to deploy netgroup usage in our network and found it impossible to do search by nisNetgroupTriple attribute due to it's SYNTAX and SUBSTR definition ... We've done "amendments" to nis.schema to fix that and they occured to be the same as the ones offered in RFC2307bis2 :) So, is there any further plans/ideas to do something with RFC2307bis2, please? -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)

2 1

Re: Antw: Re: slapd memory usage
by Howard Chu 07 Feb '19

07 Feb '19

Ulrich Windl wrote: >>>> Howard Chu <hyc(a)symas.com> schrieb am 07.02.2019 um 11:45 in Nachricht > <07438385-b8a5-92c8-3902-9d3084cbef6d(a)symas.com>: >> A. Schulze wrote: >>> >>> Howard Chu: >>> >>>>> Any idea why the memory usage is so different? >>>> >>>> If the only difference is that you set the open file limit to 1024, then it >> sounds >>>> like whatever your default file limit is is much larger. >>> >>> Hello Howard, >>> >>> yes, it's unlimited by default. Tons of other daemon also run without this >> limits here. >>> >>> But in contrast: all other daemons don't let explode the memory usage. >>> Maybe, it worth to find the difference? >> >> That *is* the difference. slapd allocates an array of connection info, one >> slot per >> file descriptor. Running with "unlimited" files is clearly a bad idea here. > > OTOH slapd could also allocate the table in chunks of 100 or 1000 descriptors (if ever needed that much) No. Such strategies invariably lead to failure under heavy load - precisely the time when you want extra resources to be available for use. Preallocating means we always have predictable and consistent runtime behavior. >> In general, running with larger limits than you actually need is a bad idea. > Yes, but allocating a huge table that is most likely never needed is also a bad idea IMHO. It would not be a huge table if you set your resource limits appropriately. >> This >> is elementary system administration. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ldap client failing
by sami's strat 30 Jan '19

30 Jan '19

I'm installing ldap client on CentOS 7 hosts. Some work, some do not. For those that don't work, I don't know why. The install / setup process I used was the same on all hosts. yum install nss-pam-ldapd openldap-clients -y authconfig --enableldap --enableldapauth --ldapserver=172.19.33.1 --ldapbasedn="dc=users,dc=domain,dc=com" --enablemkhomedir --update systemctl start nslcd getent passwd useraccount The last command fails. Vital signs on all hosts are fine, network, connectivity, ports, ntp, etc.. Where do I even begin troubleshooting the failure? Thanks in advance.

4 5

RE: OpenLDAP 2.4.45 possible denial of service vulnerability?
by Juergen.Sprenger＠swisscom.com 30 Jan '19

30 Jan '19

Hi Henrik, Many thanks for Your advice, - Yes, we started using mdb-backend and did not use it before. - LDAP tree is not very large, a slapcat dump has about 1.050 Million lines and less than 50'000 dn entries. - LDAP tree contains attributes 21661 of type aliasedObjectName - Yes, alias-dereferencing is used and set to always. Clients should not, but may do searches using "sub" instead of "one" . I will check whether using hdb will mitigate the problem. Jürgen -----Original Message----- From: Henrik Bohnenkamp [mailto:hbohnenkamp@united-internet.de] Sent: Mittwoch, 30. Januar 2019 12:23 To: Sprenger Jürgen, INI-ONE-CIS-SDI-HES <Juergen.Sprenger(a)swisscom.com> Subject: Re: OpenLDAP 2.4.45 possible denial of service vulnerability? On Wed, Jan 30, 2019 at 10:17:47AM +0000, Juergen.Sprenger(a)swisscom.com wrote: Hi Jürgen, if you can answer all of the following questions with "yes", you might have the problem described in ITS#8875/ITS#7657 (http://www.openldap.org/its/index.cgi/Incoming?id=8875;selectid=8875): - with the upgrade to 2.4.45, you started to use the mdb-backend, and did not use it before - your LDAP tree is large (> 1 Million entries) - the LDAP tree contains many alias objects (> 64k ) - the clients causing the trouble make searches with scope "sub", and alias-dereferencing set to "always" That's essential the 4 conditions that lead to a problem at my organisation similar to the one you described. Workaround was to go back to the hdb backend. Henrik -- Henrik Bohnenkamp

1 0

authz-regexp failures
by Dieter Klünter 29 Jan '19

29 Jan '19

Hi, I am facing some problems with authz-regexp configurations. These configurations run for ages on several systems. I only discovered recently, that some errors occured: # ldapwhoami -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth The appropriate lines in slapd.conf: authz-regexp "gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=config" There are still a few more authz-regexp rules that don't work anymore. Any ideas? -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

2 2

Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40
by Janne Peltonen 29 Jan '19

29 Jan '19

Hi! We've got a proxy OpenLDAP setup using the "ldap" proxy database (the newer "meta" backend had some issues, so I couldn't use that one). Most of the time, the proxy bind goes OK, but sometimes, the connection goes like this (proxy log, using ldaps): --clip-- Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 ACCEPT from IP=128.214.54.152:36460 (IP=0.0.0.0:636) Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 TLS established tls_ssf=256 ssf=256 Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 BIND dn="<removed>" method=128 Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 closed (connection lost) --clip-- On the backend, this appears to be the case that a new connection kind of overruns the old one; see what happens with connection 6983: --clip-- Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 ACCEPT from IP=128.214.222.155:46144 (IP=0.0.0.0:389) Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 ACCEPT from IP=128.214.222.155:46146 (IP=0.0.0.0:389) Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 STARTTLS Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=1 UNBIND Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 closed Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 STARTTLS Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 RESULT oid= err=0 text= Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 TLS established tls_ssf=256 ssf=256 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" method=128 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 RESULT tag=97 err=0 text= [SRCH and result lines] Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=3 UNBIND Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 closed --clip-- This doesn't seem to have any correlation to the amount of binds of server load, at least that I'm aware - and anyway, the servers are nowhere near at capacity - we only get ~2 binds per second. Normal connection would look like this: --clip-- Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 ACCEPT from IP=128.214.54.152:36362 (IP=0.0.0.0:636) Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 TLS established tls_ssf=256 ssf=256 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" method=128 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 RESULT tag=97 err=0 text= [SRCH and SEARCH RESULT lines] Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 op=219 UNBIND Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 fd=159 closed --clip-- So this far, it looks as if the problem was that if we accept a second connection for the same client before the proxy has had time to do a bind (or indeed, a STARTTLS for the bind) on the backend for the second connection. But we seem to be getting spurious Start TLS failed messages also without any competing connections. Here's one using ldap+STARTTLS but no other ACCEPTs anywhere near: --clip-- Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 ACCEPT from IP=128.214.173.135:43148 (IP=0.0.0.0:389) Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 STARTTLS Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 RESULT oid= err=0 text= Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 TLS established tls_ssf=256 ssf=256 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 BIND dn="ou=shibboleth,ou=login,dc=helsinki,dc=fi" method=128 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 RESULT tag=97 err=52 text=Start TLS failed Jan 17 17:46:22 ldap-r-1 slapd[28738]: conn=529684 fd=62 closed (connection lost) --clip-- on the proxy, and backend: --clip-- Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 ACCEPT from IP=128.214.222.155:48996 (IP=0.0.0.0:389) Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 STARTTLS Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 RESULT oid= err=0 text= Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 closed (TLS negotiation failure) --clip-- Succesful ldap+starttls connection on proxy: --clip-- Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 ACCEPT from IP=128.214.173.137:48700 (IP=0.0.0.0:389) Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 STARTTLS Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 RESULT oid= err=0 text= Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 TLS established tls_ssf=256 ssf=256 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" method=128 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 RESULT tag=97 err=0 text= [SRCH and SEARCH RESULT lines] Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=3 UNBIND Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 closed --clip-- Any ideas what could be causing these? It's a bit hard to pinpoint the problem, since it happens so rarely - we seem to get a couple dozen of these every hour to around 16 000 succesful binds, not really depending on system load. This is RHEL 7 and OpenLDAP 2.4.40. It may be the case that the same DN binding very often increases the probability of a Start TLS failed error, which I guess would be the first case (a new ACCEPT + BIND for a DN too soon after the previous one). But as I said, these seem to also sometimes appear even without any other connections being opened at the same time. (Although there might be some old connections open for the same DN.) --Janne Peltonen University of Helsinki

5 11

openldap proxy with uid/gid lookup cache
by vadud3＠gmail.com 28 Jan '19

28 Jan '19

How do I include uid/gid lookup caching to my openldap proxy server? $ cat slapd.conf ### Schema includes ########################################################### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema ## Module paths ############################################################## modulepath /usr/lib64/openldap/ moduleload back_ldap # Main settings ############################################################### pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args sizelimit unlimited TLSCertificateFile /root/data/certs/ldap.crt TLSCertificateKeyFile /root/data/certs/ldap.key ### Database definition (Proxy to AD) ######################################### database ldap readonly yes protocol-version 3 rebind-as-user yes uri "ldaps://ldap.example.com:1636" suffix "ou=People,dc=example,dc=net" ### Logging ################################################################### loglevel 0 (ignore the other similar email with no subjects.. apologize) -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

3 3

Copying SSHA userPassword from Oracle to OpenLDAP
by Nicholas Carl 23 Jan '19

23 Jan '19

Currently doing a targeted sync of userPassword field from one LDAP to another following this process. 1) Query using ldapsearch and grab userPassword field. 2) Deode string using base64 –d 3) Import resultant encrypted password into other ldap using ldapmodify. This process worked when the password decoded into {crypt} format, but after they upgraded and changed to {SSHA} format passwords, it no longer works. Also confirmed with Oracle LDAP admins that the decode matches our {SSHA} string. *Is there some additional configuration information I need to request from the oracle LDAP server administrators for server or client config in openldap?* # Querying other LDAP server $ ldapsearch -h oracleServer -D - -w - -b - "uid=-" | grep ^userPassword userPassword:: e1NTSEF9S3hNQVVoRGY0Y0ZMVXdVREZQb1VDMFNvRFdRb0c2TnNLRTVZUWc9PQ= $ ldapsearch -h oracleServer -D - -w - -b - "uid=-" | grep ^userPassword | base64 -d {SSHA}KxMAUhDf4cFLUwUDFPoUC0SoDWQoG6NsKE5YQg==base64: invalid input ## After importing decrypted into new server, the encrypted string matches. $ ldapsearch -h openLDAPServer -D - -w - "uid=-" | grep ^userPassword userPassword:: e1NTSEF9S3hNQVVoRGY0Y0ZMVXdVREZQb1VDMFNvRFdRb0c2TnNLRTVZUWc9PQ=

6 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical