openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

Worse search performance on a branch than at the tree base
by Glover, Matthew 19 Sep '18

19 Sep '18

I'm having a performance problem with searches on a branch and I'm hoping someone can explain it. A search for "(uid=12345)" on basedn "dc=example,dc=com" with a subtree scope returns much more quickly than the same filter and scope on basedn "ou=People,dc=example,dc=com". To confirm this wasn't just a problem with my schema or configuration, I loaded Ubuntu 18 (slapd 2.4.45+dfsg-1ubuntu1), used ldctl to generate 100,000 inetOrgPerson records with uids from 00000 to 99999, loaded them in with ldapadd, then used ldctl to test performance of searches: Both tests were scope subtree, 20 seconds, hitting the test server as fast as possible with randomly generated filters of "(uid=<random uid from 00000 to 99999>)". basedn: dc=example,dc=com - 5455.30/sec - total: 109106 successful searches basedn: ou=People,dc=example,dc=com - 198.80/sec - total: 3976 successful searches Also, while testing against ou=People, the CPU load from slaps went through the roof. It feels rather like the index isn’t being used when the base isn’t the root. I can provide the ldif of my test users and the parameters I used for ldctl tests if desired. Thanks for any help you can offer, Matthew

2 2

groupOfMembers doesn't work with memberOf overlay
by tran dung 19 Sep '18

19 Sep '18

Hi I am using groupOfNames and memberOf overlay works fine. However, groupOfNames requires "member" attribute so in case a group doesn't have a member, I have to use a dummy user. Since groupOfMembers doesn't require "member" attribute, I replaced groupOfNames by groupOfMembers in ldif file and re-built ldap server. However, when I delete member attribute, corresponding menberOf isn't deleted. When I add member attribute, memberOf isn't added. Is this expected behavior of groupOfMembers or is something missing in memberOf overlay setting? Here is my memberOf overlay setting ------------------------------------- # Memberof overlay overlay memberof memberof-dangling drop memberof-refint true ------------------------------------- Best Regards ----------------------- Tran Dung

2 2

Insufficient acces in some cases
by Ervin Hegedüs 19 Sep '18

19 Sep '18

Hi, there is an interesting insufficient access problem... There are 3 (in dev environment 2) multimaster ldap node. There is a simple web frontend, written in PHP, where user can change its own password, or can get a link to set up a new pass if old one had lost. In some cases (some users) the user can't change the own password through PHP. When I change it from webserver with ldapmodify and a simple ldif file, it works as well. But when I try to modify the passwd through PHP, I got "Insufficient access" error, and these lines are in syslog: Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => access_allowed: search access to "uid=comp1_user1,ou=Users,ou=COMP1,dc=wificloud,dc=company,dc=hu" "objectClass" requested Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dn: [2] ou=djp,dc=wificloud,dc=company,dc=hu Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dnpat: [3] ou=(AH|Delta|Comp1|Comp2|Comp3),dc=wificloud,dc=company,dc=hu nsub: 1 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] matched Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] attr objectClass Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => match[dn0]: 26 60 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: m Sep 18 17:48:13 dev-ldap-01 slapd[12125]: p Sep 18 17:48:13 dev-ldap-01 slapd[12125]: 1 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: , Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: w Sep 18 17:48:13 dev-ldap-01 slapd[12125]: i Sep 18 17:48:13 dev-ldap-01 slapd[12125]: f Sep 18 17:48:13 dev-ldap-01 slapd[12125]: i Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: l Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: , Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: m Sep 18 17:48:13 dev-ldap-01 slapd[12125]: p Sep 18 17:48:13 dev-ldap-01 slapd[12125]: a Sep 18 17:48:13 dev-ldap-01 slapd[12125]: n Sep 18 17:48:13 dev-ldap-01 slapd[12125]: y Sep 18 17:48:13 dev-ldap-01 slapd[12125]: , Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: h Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u Sep 18 17:48:13 dev-ldap-01 slapd[12125]: (I replaced names and chars, so the match[dn0] numbers are not correct). Only few users can trigger this problem (don't know why), and only through PHP. What's the problem here? Thanks, a.

2 7

Re: Re: OpenLDAP instances crashes
by Saurabh Lahoti 17 Sep '18

17 Sep '18

Hi, Tried with the clone command & received below error: Initialized empty Git repository in /usr/app/ldap/ReOpenLDAP-mobiuniquemember/ReOpenLDAP/.git/ error: while accessing https://github.com/leo-yuriev/ReOpenLDAP.git/info/refs fatal: HTTP request failed What could be wrong here from my side..? ---- *Thanks & Kind Regards,* Saurabh LAHOTI. *Ideas enlighten Innovation**!!!* Please consider the environment before printing this mail..!! On Fri, 14 Sep 2018 at 12:19, Леонид Юрьев <leo(a)yuriev.ru> wrote: > Hi, Saurbh. > > I apologize, long time did not answer, was off-line. > But there would be no problem if you did everything exactly as I wrote. > > Once again: > git clone https://github.com/leo-yuriev/ReOpenLDAP.git -b > mobiuniquemember > cd ReOpenLDAP > ./bootstrap.sh > ./configure --enable-contrib --prefix=... [other relevant options...] > make > make install > > On the other hand, building from the source requires certain competencies. > For instance, you should be known about all implicit (git, make, > autotools, gcc, binutils...) pre-requirements tools and packages/libraries, > and be able to install it. > Also you should known about `configure` and about corresponding options. > > Leonid. > > > пт, 14 сент. 2018 г. в 12:40, Saurabh Lahoti <saurabh.astronomy(a)gmail.com > >: > >> Many thanks Brian for your kind help. >> >> Tried with the command mentioned, below is the output: >> >> root@souslik # sh -x ./bootstrap.sh >> + '[' '' = --dont-cleanup ']' >> + rm -rf '/usr/app/ldap/LdapTest/*' >> + git clean -x -f -d -e tests/testrun -e releasenotes.txt >> fatal: Not a git repository (or any of the parent directories): .git >> + failure cleanup >> + echo 'Oops, cleanup failed ;(' >> Oops, cleanup failed ;( >> + exit 2 >> >> Could you please guide further on this..? >> ---- >> >> *Thanks & Kind Regards,* >> Saurabh LAHOTI. >> *Mob: +32.499.82.37.88* >> *Ideas enlighten Innovation**!!!* >> Please consider the environment before printing this mail..!! >> >> >> >> >> >> On Thu, 13 Sep 2018 at 23:56, Brian Reichert <reichert(a)numachi.com> >> wrote: >> >>> On Thu, Sep 13, 2018 at 10:12:34PM +0200, Saurabh Lahoti wrote: >>> > Dear, >>> > >>> > What does below error mean..? >>> > >>> > fatal: Not a git repository (or any of the parent directories): .git >>> > Oops, cleanup failed ;( >>> > >>> > While running bootstrap.sh, above mentioned error was interpreted. >>> >>> I think the source for 'bootstrap.sh' is here: >>> >>> https://github.com/leo-yuriev/ReOpenLDAP/blob/master/bootstrap.sh >>> >>> I only see one invocation of 'git' in that script, and I don't see >>> why that would fail. >>> >>> Try running >>> >>> sh -x ./bootstrap.sh >>> >>> That will show the commands the script is running; they may provide >>> a clue as to what command was being run, and with what arguments. >>> >>> > ---- >>> > >>> > *Thanks & Kind Regards,* >>> > Saurabh LAHOTI. >>> > *Ideas enlighten Innovation**!!!* >>> > Please consider the environment before printing this mail..!! >>> > >>> > >>> > >>> > >>> > >>> > On Thu, 30 Aug 2018 at 08:04, Ulrich Windl < >>> > Ulrich.Windl(a)rz.uni-regensburg.de> wrote: >>> > >>> > > >>> Saurabh Lahoti <saurabh.astronomy(a)gmail.com> schrieb am >>> 29.08.2018 um >>> > > 14:45 >>> > > in >>> > > Nachricht >>> > > <CAB5-Mqq2Epvoz-U_=1zNoz-JVSE9e5mu=MWemjyTEM7QuXaZDQ(a)mail.gmail.com >>> >: >>> > > > Dear Leo, >>> > > > >>> > > > We tried the steps mentioned below using the ReOpenLDAP package >>> provided >>> > > by >>> > > > you. >>> > > > >>> > > > But, we're start at the very first step while running bootstrap.sh >>> & >>> > > > encountered below errors: >>> > > > >>> > > > root@pygarg # ./bootstrap.sh >>> > > > ./bootstrap.sh: line 39: git: command not found >>> > > > Oops, cleanup failed ;( >>> > > >>> > > I wonder: How could you "git clone" without git? >>> > > >>> > > > >>> > > > >>> > > > Could you please guide us further into this..? >>> > > > >>> > > > ---- >>> > > > >>> > > > *Thanks & Kind Regards,* >>> > > > Saurabh LAHOTI. >>> > > > *Ideas enlighten Innovation**!!!* >>> > > > Please consider the environment before printing this mail..!! >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > On Thu, 23 Aug 2018 at 23:17, ???????????? ?????????? < >>> leo(a)yuriev.ru> wrote: >>> > > > >>> > > >> Hi, Saurabh. >>> > > >> >>> > > >> Your custom overlay "mobiuniquemember" now intergated into >>> ReOpenLDAP >>> > > >> (mobiuniquemember branch). >>> > > >> Please check it: >>> > > >> >>> > > >> git clone https://github.com/leo-yuriev/ReOpenLDAP.git -b >>> > > mobiuniquemember >>> > > >> cd ReOpenLDAP >>> > > >> ./bootstrap.sh >>> > > >> ./configure --enable-contrib [other relevan options] >>> > > >> make install >>> > > >> >>> > > >> Regards, >>> > > >> Leonid. >>> > > >> >>> > > >> >>> > > >> ????, 22 ??????. 2018 ??. ?? 18:04, ???????????? ?????????? < >>> leo(a)yuriev.ru>: >>> > > >> >>> > > >>> You could submit source code of your custom overlay to >>> > > >>> https://github.com/leo-yuriev/ReOpenLDAP, i.e. pull-request >>> into the >>> > > >>> 'devel' branch. >>> > > >>> >>> > > >>> Then I will try fix it and merge-in, in success case you will be >>> able >>> > > to >>> > > >>> build and use it with ReOpenLDAP. >>> > > >>> >>> > > >>> >>> > > >>> Regards, >>> > > >>> Leonid. >>> > > >>> >>> > > >>> ????, 22 ??????. 2018 ??., 17:37 Saurabh Lahoti < >>> saurabh.astronomy(a)gmail.com >>> > > >: >>> > > >>> >>> > > >>>> Dear, >>> > > >>>> >>> > > >>>> What is you're recommendation to fix this problem on our >>> side..? It's >>> > > >>>> been haunting our operational activities on daily basis.. ?????? >>> > > >>>> ---- >>> > > >>>> >>> > > >>>> *Thanks & Kind Regards,* >>> > > >>>> Saurabh LAHOTI. >>> > > >>>> *Mob: +32.499.82.37.88* >>> > > >>>> *Ideas enlighten Innovation**!!!* >>> > > >>>> Please consider the environment before printing this mail..!! >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> On Fri, 17 Aug 2018 at 16:43, Brian Reichert < >>> reichert(a)numachi.com> >>> > > >>>> wrote: >>> > > >>>> >>> > > >>>>> On Thu, Aug 16, 2018 at 02:00:20PM +0200, Saurabh Lahoti wrote: >>> > > >>>>> > Dear, >>> > > >>>>> > >>> > > >>>>> > Today, received below error in /var/log/messages with >>> OpenLDAP >>> > > >>>>> instance >>> > > >>>>> > crashing. >>> > > >>>>> >>> > > >>>>> That looks like either: >>> > > >>>>> >>> > > >>>>> - You have a bad SIM (very unlikely) >>> > > >>>>> - You have a corrupted uniquemember.so.0.0.0 shared library. >>> > > >>>>> - You may have conflated OpenLDAP packages installed that have >>> a >>> > > >>>>> critical >>> > > >>>>> incompatibility amidst the installed binaries/libraries. >>> > > >>>>> >>> > > >>>>> It did write a core file; there are many tutorials about >>> exploring >>> > > >>>>> a core file to help understand why the segfault occurred. >>> > > >>>>> >>> > > >>>>> > >>> > > >>>>> > Aug 16 13:21:07 muledeer kernel: slapd[29253]: segfault at 0 >>> ip >>> > > >>>>> > 00007fbeddf3af09 sp 00007fb72effc480 error 4 in >>> > > >>>>> > uniquemember.so.0.0.0[7fbeddf3a000+2000] >>> > > >>>>> > Aug 16 13:21:08 muledeer abrt[24629]: Saved core dump of pid >>> 16470 >>> > > >>>>> > (/usr/app/ldap/openldap2.4.46/libexec/slapd) to >>> > > >>>>> > /var/spool/abrt/ccpp-2018-08-16-13:21:07-16470 (472973312 >>> bytes) >>> > > >>>>> > Aug 16 13:21:08 muledeer abrtd: Directory >>> > > >>>>> 'ccpp-2018-08-16-13:21:07-16470' >>> > > >>>>> > creation detected >>> > > >>>>> > Aug 16 13:21:08 muledeer abrtd: Executable >>> > > >>>>> > '/usr/app/ldap/openldap2.4.46/libexec/slapd' doesn't belong >>> to any >>> > > >>>>> package >>> > > >>>>> > and ProcessUnpackaged is set to 'no' >>> > > >>>>> > Aug 16 13:21:08 muledeer abrtd: 'post-create' on >>> > > >>>>> > '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' exited with >>> 1 >>> > > >>>>> > Aug 16 13:21:08 muledeer abrtd: Deleting problem directory >>> > > >>>>> > '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' >>> > > >>>>> > >>> > > >>>>> > >>> > > >>>>> > Could you please guide us in finding probable root of this >>> error..? >>> > > >>>>> > ---- >>> > > >>>>> > >>> > > >>>>> > *Thanks & Kind Regards,* >>> > > >>>>> > Saurabh LAHOTI. >>> > > >>>>> > *Ideas enlighten Innovation**!!!* >>> > > >>>>> > Please consider the environment before printing this mail..!! >>> > > >>>>> >>> > > >>>>> -- >>> > > >>>>> Brian Reichert <reichert(a)numachi.com> >>> > > >>>>> BSD admin/developer at large >>> > > >>>>> >>> > > >>>> >>> > > >>> > > >>> > > >>> > > >>> >>> -- >>> Brian Reichert <reichert(a)numachi.com> >>> BSD admin/developer at large >>> >>

1 0

Re: OpenLDAP instances crashes
by Saurabh Lahoti 14 Sep '18

14 Sep '18

Dear Leo, We tried the steps mentioned below using the ReOpenLDAP package provided by you. But, we're start at the very first step while running bootstrap.sh & encountered below errors: root@pygarg # ./bootstrap.sh ./bootstrap.sh: line 39: git: command not found Oops, cleanup failed ;( Could you please guide us further into this..? ---- *Thanks & Kind Regards,* Saurabh LAHOTI. *Ideas enlighten Innovation**!!!* Please consider the environment before printing this mail..!! On Thu, 23 Aug 2018 at 23:17, Леонид Юрьев <leo(a)yuriev.ru> wrote: > Hi, Saurabh. > > Your custom overlay "mobiuniquemember" now intergated into ReOpenLDAP > (mobiuniquemember branch). > Please check it: > > git clone https://github.com/leo-yuriev/ReOpenLDAP.git -b mobiuniquemember > cd ReOpenLDAP > ./bootstrap.sh > ./configure --enable-contrib [other relevan options] > make install > > Regards, > Leonid. > > > ср, 22 авг. 2018 г. в 18:04, Леонид Юрьев <leo(a)yuriev.ru>: > >> You could submit source code of your custom overlay to >> https://github.com/leo-yuriev/ReOpenLDAP, i.e. pull-request into the >> 'devel' branch. >> >> Then I will try fix it and merge-in, in success case you will be able to >> build and use it with ReOpenLDAP. >> >> >> Regards, >> Leonid. >> >> ср, 22 авг. 2018 г., 17:37 Saurabh Lahoti <saurabh.astronomy(a)gmail.com>: >> >>> Dear, >>> >>> What is you're recommendation to fix this problem on our side..? It's >>> been haunting our operational activities on daily basis.. 😓 >>> ---- >>> >>> *Thanks & Kind Regards,* >>> Saurabh LAHOTI. >>> *Mob: +32.499.82.37.88* >>> *Ideas enlighten Innovation**!!!* >>> Please consider the environment before printing this mail..!! >>> >>> >>> >>> >>> >>> On Fri, 17 Aug 2018 at 16:43, Brian Reichert <reichert(a)numachi.com> >>> wrote: >>> >>>> On Thu, Aug 16, 2018 at 02:00:20PM +0200, Saurabh Lahoti wrote: >>>> > Dear, >>>> > >>>> > Today, received below error in /var/log/messages with OpenLDAP >>>> instance >>>> > crashing. >>>> >>>> That looks like either: >>>> >>>> - You have a bad SIM (very unlikely) >>>> - You have a corrupted uniquemember.so.0.0.0 shared library. >>>> - You may have conflated OpenLDAP packages installed that have a >>>> critical >>>> incompatibility amidst the installed binaries/libraries. >>>> >>>> It did write a core file; there are many tutorials about exploring >>>> a core file to help understand why the segfault occurred. >>>> >>>> > >>>> > Aug 16 13:21:07 muledeer kernel: slapd[29253]: segfault at 0 ip >>>> > 00007fbeddf3af09 sp 00007fb72effc480 error 4 in >>>> > uniquemember.so.0.0.0[7fbeddf3a000+2000] >>>> > Aug 16 13:21:08 muledeer abrt[24629]: Saved core dump of pid 16470 >>>> > (/usr/app/ldap/openldap2.4.46/libexec/slapd) to >>>> > /var/spool/abrt/ccpp-2018-08-16-13:21:07-16470 (472973312 bytes) >>>> > Aug 16 13:21:08 muledeer abrtd: Directory >>>> 'ccpp-2018-08-16-13:21:07-16470' >>>> > creation detected >>>> > Aug 16 13:21:08 muledeer abrtd: Executable >>>> > '/usr/app/ldap/openldap2.4.46/libexec/slapd' doesn't belong to any >>>> package >>>> > and ProcessUnpackaged is set to 'no' >>>> > Aug 16 13:21:08 muledeer abrtd: 'post-create' on >>>> > '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' exited with 1 >>>> > Aug 16 13:21:08 muledeer abrtd: Deleting problem directory >>>> > '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' >>>> > >>>> > >>>> > Could you please guide us in finding probable root of this error..? >>>> > ---- >>>> > >>>> > *Thanks & Kind Regards,* >>>> > Saurabh LAHOTI. >>>> > *Ideas enlighten Innovation**!!!* >>>> > Please consider the environment before printing this mail..!! >>>> >>>> -- >>>> Brian Reichert <reichert(a)numachi.com> >>>> BSD admin/developer at large >>>> >>>

3 4

Failed to create more than 1024 LMDB environment objects
by Jeremy Chen 12 Sep '18

12 Sep '18

Hi I have been using lmdb (with java binding on Ubuntu 14.04+, or Centos 7) to manage daily data sets for a while and so far it works beautifully. Now I am trying to add multi-tenancy support with physical partitioning, but fails to create more than 1024 environments (1017 to be exact). The error msg is "Resource temporarily unavailable" (not sure if it's accurate since it's from the lmdbjni binding), and it will only generate a lock.mdb of 0 length in the failed environment. I tuned a few parameters, like reducing the map size to a few MB each, etc, but to no avail. Is this a hard limit? Or I could change something in lmdb source code to extend it? Thank you very much! Jeremy

1 1

multiple syncrepl statements for partial DIT replication
by Manuela Mandache 11 Sep '18

11 Sep '18

Hi, I just subscribed to ask this question, I found no answer in the archives - sorry if I haven't looked well enough. There are three branches in the DIT on the provider and only two of them must be replicated to the consumers. Can this be done by defining two syncrepl statements on the consumers, one for each branch to be replicated and each one having a different rid? I run OpenLDAP 2.4.40 on CentOS 7. I know this result can be obtained by defining the right ACLs for the replication account on the provider and giving the parent of the three branches in the syncrepl statement, I was wondering if there are other ways of achieving it. Thank you, Manuela Mandache

2 1

Replication issue? Data is different between master and consumer with same entryCSNs
by Dave Steiner 10 Sep '18

10 Sep '18

I've been noticing various data discrepancies between our LDAP master and LDAP consumers. We are running OpenLDAP v2.4.44. We have two masters running "mirromode TRUE" and all updates go through a VIP that points to the first one unless it's not available (doesn't happen very often except for during patches and restarts). We have 13 consumers that replicate through that same VIP. Here's an example of our syncrepl for a client: syncrepl rid=221 type=refreshAndPersist schemachecking=on provider="ldap://ldapmastervip.rutgers.edu/" bindmethod=sasl saslmech=EXTERNAL starttls=yes tls_reqcert=demand tls_protocol_min="3.1" searchbase="dc=rutgers,dc=edu" attrs="*,+" retry="10 10 20 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog network-timeout=30 keepalive=180:3:60 I check the contextCSN attributes on all the instances every day and they are all in sync (except during any major changes, of course). But I occasionally notice discrepancies in the data.... even though the contextCSNs and entryCSNs are the same. For example (note hostnames have been changed): $ ldapsearch ... -H ldap://ldapmaster.rutgers.edu uid=XXXX postalAddress createTimestamp modifyTimestamp entryCSN dn: uid=XXXX,ou=People,dc=rutgers,dc=edu createTimestamp: 20121220100700Z postalAddress: Business And Science Bldg$227 Penn Street$Camden, NJ 081021656 entryCSN: 20180505002024.083133Z#000000#001#000000 modifyTimestamp: 20180505002024Z $ ldapsearch ... -H ldap://ldapconsumer3.rutgers.edu uid=XXXX postalAddress createTimestamp modifyTimestamp entryCSN dn: uid=XXXX,ou=People,dc=rutgers,dc=edu createTimestamp: 20121220100700Z postalAddress: BUSINESS AND SCIENCE BLDG$227 PENN STREET$CAMDEN, NJ 081021656 entryCSN: 20180505002024.083133Z#000000#001#000000 modifyTimestamp: 20180505002024Z So I'm trying to figure out why this happens (config issue, bug, ???) and second, if I can't use the contextCSN to report that everything is fine, what else can I do besides trying to compare ldif dumps. thanks, ds -- Dave Steiner steiner(a)rutgers.edu IdM, Enterprise Application Services ASB101; 848.445.5433 Rutgers University, Office of Information Technology

4 6

olcSecurity: tls=1 and olcLocalSSF= : what value should I use?
by Jean-Francois Malouin 06 Sep '18

06 Sep '18

Sorry if this is long and naive, I'm making my way with OpenLDAP. I have this annoying problem of local access over ldapi:/// of a configured mdb database using its rootDN. Some details: (I typically use ldapvi to access/modify/edit config as I'm an old wolf with vi hard-wired in my brain!) (Same could be done using native OpenLDAP utilities ldapadd/search/delete/etc: just replace the ldapvi '-h' option with '-H' to specify the protocol/host/port). Binding using EXTERNAL mech over local ldapi:/// works correctly for 'cn=config'. For example, here I made a mod to olcLogLevel for 'cn=config': ~# ldapvi -Y EXTERNAL -h ldapi:/// -b 'cn=config' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 24 entries read add: 0, rename: 0, modify: 1, delete: 0 Action? [yYqQvVebB*rsf+?] y Done. Server logs for slapd show the binding with ssf=71: Sep 6 11:40:52 slapd[677]: conn=48667 fd=17 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND dn="" method=163 Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 However for the configured mdb database 'olcDatabase={1}mdb,cn=config' I have set olcSecurity: tls=1 to force binding with StartTLS. Here the relevant config piece for it: ('--out' makes ldapvi behave like ldapsearch). ~# ldapvi --out -Y EXTERNAL -h ldapi:/// -b 'olcDatabase={1}mdb,cn=config' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcRootDN: cn=admin,dc=example,dc=com olcRootPW: {SSHA}XXXXXXXXXXXXXXXXXXXX olcSecurity: tls=1 ... However this setting prohibits me from binding to it using ldapi:/// with EXTERNAL mech with its rootDN 'cn=admin,dc=example,dc=com' as I then get the message: ~# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -D 'cn=admin,dc=example,dc=com' -b 'dc=example,dc=com' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 Confidentiality required (13) Additional information: TLS confidentiality required I can however do a simple bind over StartTLS with the rootDN of the database either over localhost or a remote client: ~# ldapsearch -LLL -Z -x -w xxxxxxxx -H ldap://localhost -D 'cn=admin,dc=example,dc=com' -b 'dc=example,dc=com' slapd logs show: Sep 6 11:54:40 slapd[677]: conn=48699 fd=17 ACCEPT from IP=127.0.0.1:53542 (IP=0.0.0.0:389) Sep 6 11:54:40 slapd[677]: conn=48699 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 6 11:54:40 slapd[677]: conn=48699 op=0 STARTTLS Sep 6 11:54:40 slapd[677]: conn=48699 op=0 RESULT oid= err=0 text= Sep 6 11:54:40 slapd[677]: conn=48699 fd=17 TLS established tls_ssf=256 ssf=256 Sep 6 11:54:40 slapd[677]: conn=48699 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128 Sep 6 11:54:40 slapd[677]: conn=48699 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 So ssf=265... I guess I need to modify either 'olcSecurity: tls=1' in the database config or add/insert the proper value for 'olcLocalSSF=' in the cn=config. What value should I use in order to still force StartTLS over simple binding and allow read/write/modify local access on the ldapi:/// listener. Regards! jf

2 2

duplicated naming context when using syncrepl proxy
by Jochen Keutel 05 Sep '18

05 Sep '18

Hallo, I'm using OpenLDAP on Debian 9 (2.4.44) and started to configure replication: szenario syncrepl proxy (push based replication, see 18.3.5 in OpenLDAP Admin Guide - "primary directory also contains back-ldap databases"). Configuring the LDAP backend leads unfortunately to a root DSE showing the same name context twice: namingContexts: dc=keutel,dc=de namingContexts: dc=keutel,dc=de Is this a known problem? Esp. this stops PHPLDAPAdmin from working: It prints a lot of PHP arrays in this case. I've set "hidden on" for this backend but the problem remains. My configuration: 1. slapd.conf on server1 (master): database ldap hidden on suffix "dc=keutel,dc=de" rootdn "cn=admin,dc=keutel,dc=de" uri ldaps://server2/ lastmod on restrict all acl-bind bindmethod=simple binddn="cn=replication,dc=keutel,dc=de" credentials=secret syncrepl rid=001 provider=ldaps://server1/ binddn="cn=replication,dc=keutel,dc=de" bindmethod=simple credentials=secret searchbase="dc=keutel,dc=de" type=refreshAndPersist retry="5 5 300 5" 2. converting this to dynamic config using slaptest gives the following entry: dn: olcDatabase={2}ldap objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcHidden: TRUE olcSuffix: dc=keutel,dc=de ... 3. starting slapd with this dynamic configuration 4. reading rootDSE: attribute namingContexts occurs twice with the same value. How can this be solved? Regards Jochen.

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical