openldap-technical July 2017

openldap-technical@openldap.org

29 participants
73 discussions

RE: Using TLS
by Quanah Gibson-Mount 07 Jul '17

07 Jul '17

--On Monday, June 26, 2017 4:59 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > int opt; > opt = LDAP_OPT_X_TLS_NEVER; > ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &opt); > > -And- > > int new_ctx = 0; > ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &new_ctx); Hi Daniel, This case is specifically tested in my TLS test suite in test067. It works correctly, as expected. I would note that I use ldap_int_tls_config (RE24)/ldap_pvt_tls_config (2.5/master) for setting LDAP_OPT_X_TLS_REQUIRE_CERT rather than ldap_set_option. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Slave won't send referrals
by Jon C Kidder 07 Jul '17

07 Jul '17

Ok, this should be simple right? I have a 2.4.44 slave with olcUpdateRef pointing to the master. Replication works fine and the slave reflects any changes made to the master. The slave is also accepting modify operations without complaining and without returning a referral. I've compared my configuration with the configuration generated for test022. I have the needful extra stuff in my configuration and everything looks correct to me. I've attached the modify command line and result, the slave configuration, and the log of the operation for reference. Any insight into what I'm overlooking would be greatly appreciated!! Thanks, -Jon C. Kidder American Electric Power Complex - Middleware Engineering. zip renamed as txt to avoid mail scrubbing.

1 0

libgcrypt's RSA-1024 and RSA-2048 broken
by Howard Chu 06 Jul '17

06 Jul '17

http://thehackernews.com/2017/07/gnupg-libgcrypt-rsa-encryption.html?utm_so… I believe most deployments of GnuTLS now use nettle instead of libgcrypt. But if you're on an older Debian or Ubuntu, using their packaged OpenLDAP built with GnuTLS, you should check what version of GnuTLS and libgcrypt you're using. And you should seriously consider not using their package; rebuild from source with OpenSSL or get a package from LTB or Symas. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Q: index for operational attributes?
by Ulrich Windl 06 Jul '17

06 Jul '17

Hello! Should I really add an index for modifyTimestamp? I got "slapd[4021]: <= bdb_inequality_candidates: (modifyTimestamp) not indexed!" (No discussions on using BDB, please!) Regards, Ulrich

2 4

RE: client-pr option for meta backend
by Quanah Gibson-Mount 05 Jul '17

05 Jul '17

--On Wednesday, July 05, 2017 5:39 PM +0000 laurent2.perrin(a)orange.com wrote: > To sum up: > > Client ==> openLdap (meta backend): Control header is in the searchRequest > OpenLDAP (meta backend) ==> Active Directory: Control header is in the > searchRequest Active Directory ==> OpenLDAP (meta backend): Control > header is in the searchResDone OpenLDAP (meta backend) ==> Client: > Control header is not in the searchResDone > > This control Header should not be passed to client ? No idea. The backend and that code are both experimental, and the author has since retired from the project. What's really necessary is for someone to adopt back-ldap/meta and join the project so development on them can continue. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: client-pr option for meta backend
by Quanah Gibson-Mount 05 Jul '17

05 Jul '17

--On Wednesday, July 05, 2017 10:41 AM +0000 laurent2.perrin(a)orange.com wrote: > > > Hello, > > > > I have set up a meta backend with OpenLDAP 2.4.42 on an Ubuntu Server > 16.04. > > > > This is working with some ldapsearch but meta directory will be used by a > VMware vCenter. The vCenter LDAP client uses the pagedResultsControl, > which is disabled by default for the meta backend (according to the > slapd-meta documentation). Hi Luarent, The client-pr code is currently ifdef'd behind LDAP_DEVEL, which means it is not enabled by default. It appears there is a bug here, in that either the feature should be moved out from being behind LDAP_DEVEL or the documentation should be removed from the man page. If you need use of this feature, you need to define SLAPD_META_CLIENT_PR when compiling OpenLDAP. >From back-meta.h: #ifdef LDAP_DEVEL #define SLAPD_META_CLIENT_PR 1 #endif /* LDAP_DEVEL */ --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount 05 Jul '17

05 Jul '17

--On Wednesday, July 05, 2017 1:39 AM -0400 btb <btb(a)bitrate.net> wrote: > i've also increased accesslog data retention from 7 days to 14 days, as a > bit of a compensation for the infrequent writes, and i'll implement a > "no-op" cron job as well, as a fail safe. are then any pitfalls i may > not be considering with a 14 day accesslog retention period? is that too > long according to "typical" consensus? It really depends on your specific usage. It's defined as a configurable so it can be adjusted to match the reality of a given deployment. :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: redMod with single colon
by Ondřej Kuzník 05 Jul '17

05 Jul '17

On Wed, Jul 05, 2017 at 01:48:06PM +0200, Ulrich Windl wrote: > Ondrej Kuzník <ondra(a)mistotebe.net> schrieb am 28.06.2017 um 17:51 in >> Hi, >> this is intended and how the issue in ITS#6545 has been fixed. >> >> The operation you are looking at has removed some values, then added >> other values for the same attribute straight away as another modify >> within the same op. > > What would break if those "Og==" lines were omitted? ITS#6545: interrupted replication/potential desynchronisation, depending on the operation. See the related changes to the test suite (test063). Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

client-pr option for meta backend
by laurent2.perrin＠orange.com 05 Jul '17

05 Jul '17

Hello, I have set up a meta backend with OpenLDAP 2.4.42 on an Ubuntu Server 16.04. This is working with some ldapsearch but meta directory will be used by a VMware vCenter. The vCenter LDAP client uses the pagedResultsControl, which is disabled by default for the meta backend (according to the slapd-meta documentation). I tried to enable it with the "olcDbClientPr" option, with this ldif file: dn: olcDatabase={2}meta,cn=config changetype: modify add: olcDbClientPr olcDbClientPr: accept-unsolicited But I get this error message: modifying entry "olcDatabase={2}meta,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcDbClientPr> handler exited with -1026 Here is the configuration of the meta backend: dn: olcDatabase={2}meta objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {2}meta olcSuffix: dc=meta,dc=local olcLastMod: FALSE olcRootDN: cn=manager,dc=meta,dc=local olcRootPW:: e1NTSEF9S3VmQ2VFUEhUV2tyWWRkQnZLVUdkbEp4QSt6UDU2Zmk= structuralObjectClass: olcMetaConfig entryUUID: 7115068a-f1bb-1036-8e31-07775d6d5e9e creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20170630083957Z olcSizeLimit: 30000 olcLimits: {0}users size.prtotal=1000 pr.size=1000 entryCSN: 20170704141941.224315Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth Is something wrong with this type of configuration ? Regards, [cid:image001.gif@01CBF2E5.34FD28F0] Laurent PERRIN Service Infra aux Projets Orange Applications for Business SCE/OAB/DPO/DT/SF/CLOUDS tel. +33 4 37 24 62 85 Mob : 07 84 12 78 79 laurent2.perrin(a)orange.com<mailto:laurent2.perrin@orange.com> 139 rue Vendôme 69006 Lyon www.orange-business.com<http://www.orange-business.com/> [cid:image002.gif@01CBF2E5.34FD28F0] _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0

Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount 04 Jul '17

04 Jul '17

--On Thursday, June 29, 2017 1:41 PM -0400 btb <btb(a)bitrate.net> wrote: > > > On 6/29/17 11:15 AM, Quanah Gibson-Mount wrote: >> --On Thursday, June 29, 2017 2:12 AM -0400 btb <btb(a)bitrate.net> wrote: >> >>> i see, thanks. i tested this, and did a modify on each, but didn't see >>> replication resume. emulating the syncrepl connection with a manual >>> search against each master, there do seem to be accesslog entries now, >>> on both masters: >> >> You may have to restart the consumers (I did when I ran into this). > > i did try a restart on both, but they returned to the same state > >> Also, there are 2 sets of CSNs per master that you need to examine -- >> The CSNs in your database root (i.e., dc=example,dc=org) and your >> accesslog root. > > that would be these, right? > > dsa1 cn=accesslog: > 20161019002438.652359Z#000000#000#000000 > 20170521175113.974560Z#000000#002#000000 > 20170530214415.204052Z#000000#001#000000 > > dsa1 dc=example,dc=org: > 20170520031415.276678Z#000000#000#000000 > 20170530214231.171959Z#000000#002#000000 > 20170530214415.204052Z#000000#001#000000 > > dsa2 cn=accesslog: > 20170520031415.276678Z#000000#000#000000 > 20170521175113.974560Z#000000#002#000000 > 20170628034119.327974Z#000000#001#000000 > > dsa2 dc=example,dc=org: > 20170520031415.276678Z#000000#000#000000 > 20170619014933.531051Z#000000#002#000000 > 20170628034119.327974Z#000000#001#000000 > > why are there three per db, and which is suppose to match which? wow, that's a mess. So #000# is serverID 0, which would be for any entries prior to moving to MMR. The fact that you have different values for #000# on dsa1 accesslog vs the other 3 databases is disturbing. It would appear DSA1 is serverID 1, and its CSNs make sense: 20170530214415.204052Z#000000#001#000000 20170530214415.204052Z#000000#001#000000 However, there's someting serious wrong with dsa2 (assuming it is serverID 2): 20170521175113.974560Z#000000#002#000000 20170619014933.531051Z#000000#002#000000 As this implies the primary DB received a write on 2017/06/19 @ 01:49:33, but the accesslog has not recorded this change, as it says the last time there was a write op to the accesslog DB on #002# was 2017/05/21 @ 17:51:13, nearly a month earlier. So it doesn't seem to think you've done a write op directly against serverID 002. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2017