openldap-technical

openldap-technical@openldap.org

13 participants
9906 discussions

Monitor configuration... also for the manual
by Arno Lehmann 09 Feb '19

09 Feb '19

Hi all, I'm currently in the process of migrating LDAP data from a really outdated system to something a bit fresher. So, I started with the OpenLDAP as provided by Debian, and learned that a good part of the system management knowledge I had is outdated. So, I stared reading TFM. ... and stumbled over the section where I wanted to learn how to set up monitoring with the cn=config configuration scheme. Naturally, that was exactly the incentive I needed to actually start giving back something to the community. So, I ended up playing around a bit and googling a bit and scratching my head a lot, taking notes, and came up with something you might want to add into the manual -- see below. Unfortunately, the whole thing did not exactly work out as I intended, because the crucial step insists on failing. Namely, trying to create a monitor database fails, indicating there already is one in existence. However, I can't find any such beast: root@host:~/ldap# ldapsearch -Q -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(|(olcDatabase=monitor)(objectClass=olcMonitorConfig))' root@host:~/ldap# I have actually tried to add the above data using slapadd, with slapd shut down, and got an even more confusing error message: root@host:~/ldap# slapadd -n 0 -l addMonitorDB.ldif slapadd: could not add entry dn="olcDatabase=Monitor,cn=config" (line=1): autocreation of "olcDatabase={-1}frontend" failed _######### 46.91% eta none elapsed none spd 1.3 M/s Closing DB... So, what do I need to do to get my manual suggestion into working condition? (And also allow me to monitor my all fresh LDAP instance :-) Cheers, Arno -----8<--------------cut here... manual text below ------------->8------ 20.1. Monitor configuration via cn=config(5) To enable monitoring an OpenLDAP server, the "monitor" database needs to be available and configured, also allowing read acces to it. 20.1.1. Ensure the monitor backend is available The first step is to ensure the monitor database is part of the running slapd process. As database backends can be build into the main binary, or loaded dynamically, as configured, the initial step is to check if the module is built in, is already loaded, or, if not, add it to the configuration. 20.1.2. Check the binary for built-in modules By running root@host:~/ldap# slapd -VVV @(#) $OpenLDAP: slapd (May 23 2018 04:25:19) $ Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Included static backends: config ldif root@host:~/ldap# it is easy to check if the monitor backend database is built-in; in the above case, it is not. If it already is part of the slapd binary, the process goes to section 20.1.5 further below. 20.1.3. Check module loader configuration *Note* that the below examples use one particular scheme to access LDAP with administrative, i.e. full, privileges; things may be configured differently in other environments. (The example is correct for a stock Debian 9 installation, by the way.) Checking if the monitor backend is already configured to be loaded requires querying the LDAP configuration, in particular the module loader configuration: root@host:~/ldap# ldapsearch -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(objectClass=olcModuleList)' olcModuleLoad SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=module{0},cn=config olcModuleLoad: {0}back_mdb olcModuleLoad: {1}back_monitor root@host:~/ldap# In this example, we see the back_monitor module to be loaded. If a line referencing this module was not shown, the next step is described below. Otherwise, proceed at section 20.1.5. 20.1.4. Add the monitor module to the module loader configuration 20.1.4.1. Verify the necessary module exists. A careful administrator will ensure the needed module is actually available to be loaded. This is done by checking the needed file exists in the module loader's path. We assume the path to be correctly set up in the loaders configuration in the first place, trusting that the package builder prepared this step. Thus: root@host:~/ldap# ldapsearch -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(objectClass=olcModuleList)' olcModulePath SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=module{0},cn=config olcModulePath: /usr/lib/ldap root@host:~/ldap# ls -l /usr/lib/ldap/*monitor* lrwxrwxrwx 1 root root 26 May 23 2018 /usr/lib/ldap/back_monitor-2.4.so.2 -> back_monitor-2.4.so.2.10.7 -rw-r--r-- 1 root root 109408 May 23 2018 /usr/lib/ldap/back_monitor-2.4.so.2.10.7 -rw-r--r-- 1 root root 976 May 23 2018 /usr/lib/ldap/back_monitor.la lrwxrwxrwx 1 root root 26 May 23 2018 /usr/lib/ldap/back_monitor.so -> back_monitor-2.4.so.2.10.7 root@host:~/ldap# and voilà, things look good, the module shared object file is available, and things are prepared for different versions coexisting in the usual Unix/Linux way. (The author has no idea what to expect on a windows system.) If things did *not* look good, it would be time to check the distribution repositories for packages with OpenLDAP modules, or verify the build and installation process, both of which is out of scope of this chapter. 20.1.4.2. Adding the monitor backend to the loader configuration Assuming paths and binaries are all correct, it's now merely a matter of adding some attributes to the module loader's configuration. This can be done with just a few lines of LDIF: root@host:~/ldap# cat loadMonitor.ldif dn: cn=config,cn=module changetype: modify add: olcModuleLoad olcModuleLoad: back_monitor root@host:~/ldap# ldapmodify -H ldapi:/// -Y EXTERNAL -f loadMonitor.ldif should do all that is necessary. Error messages hopefully provide an indication of what went wrong in case there is a problem. 20.1.5. Verifying the monitor backend needs to be configured Of course, we start out being extra-careful, by checking that no monitor backend is already configured: root@host:~/ldap# ldapsearch -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(objectClass=olcDataBaseConfig)' olcDatabase objectClass SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb root@host:~/ldap# Carefully checking the output, it becomes clear no monitor database is available as yet, so we need to continue. 20.1.6. Adding a "monitor" database Again, a simple LDAP add operation will be sufficient: root@host:~/ldap# cat addMonitorDB.ldif dn: olcDatabase=monitor,cn=config objectClass: olcDatabaseConfig objectClass: olcMonitorConfig olcDatabase: monitor olcAccess: to dn.subtree=cn=monitor by users read root@host:~/ldap# Naturally, the ACL(s) may be adjusted as needed. root@host:~/ldap# ldapadd -H ldapi:/// -Y EXTERNAL -f addMonitorDB.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase=monitor,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: only one monitor database allowed (BETTER NOT PUBLISH THE FINAL TWO LINES...)

3 9

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 27 Jan '19

27 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical