openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

add new scheme to existing ldap
by SHarbich＠t-online.de 20 Dec '19

20 Dec '19

Hello, when I try to add a new scheme in the existing LDAP like this. I get the following error message: "root@dsme01:~# slapadd -v -l /tmp/ldapconvert/evolutionperson.ldif slapadd: line 1: database #1 (dc=example,dc=com) not configured to hold "cn=evolutionperson,cn=schema,cn=config"; did you mean to use database #0 (cn=config)? _#################### 100.00% eta none elapsed none fast!" Before, I created the evolutionperson.schema including all schemas as follows: "slapcat -f /tmp/ldapconvert/ldap.conf -F /tmp/ldapconvert -n0 -s "cn={19}evolutionperson,cn=schema,cn=config" > /tmp/ldapconvert/evolutionperson.ldif" The created file was adapted accordingly and only tried to add it as described above. Do I have to delete the entire LDAP database and recreate it and then reload the user-specific part? I would appreciate your support. Greetings from Stefan Harbich

2 1

Re: back-meta with overlapping DN spaces; bind operation does not find applicable target [Active Directory merge]
by Heiko Wundram 17 Dec '19

17 Dec '19

Hello list, sorry for top-posting: Outlook is a pain. Anyway, more to the point: I've experimented at bit more with this, and it seems that mode=legacy for the backend at least does/tries the search operation on the respective meta backends for finding the concrete backend that allows identity assertion of the incoming user (with properly rewritten DN), but does not authenticate that connection, i.e. tries to anonymously search on the backends to find the user object. I've not found a combination of parameters to authenticate the connection for search in meta_search_dobind_init, but from what I can tell from the source, the connection used for the initial bind should actually be authenticated with the idassert binddn and credentials (for bindmethod=simple without proxyAuthz). Apparently, it isn't. (again, the source isn't the clearest, and as there's no debugging information output by the actual functions called by meta_search_dobind_init, it's rather hard to check the actual control flow for me). I'm very hesitant to open the backends (which are active directory servers) up for anonymous accesses, which means that I'm still trying to get this to work (have two different active directory backends with different layouts unified under a single read-only proxy which allows authentication in both directories and delivers results from both). If there's anybody who has this operating successfully, I'd very much love a heads up to any configuration errors and/or problems in understanding I have to fix this. Have a pleasant day! --- Heiko. Von: openldap-technical <openldap-technical-bounces(a)openldap.org> Im Auftrag von Heiko Wundram Gesendet: Donnerstag, 12. Dezember 2019 17:58 An: openldap-technical(a)openldap.org Betreff: back-meta with overlapping DN spaces; bind operation does not find applicable target Hello list, I'm trying to get back-meta running with two backends who have distinct namespaces, but should be exposed in an overlapping DN space, and while search operations and result transformations work fine, I'm having trouble getting the bind operation to try both directories for the login (after bindDN rewrite rules have been applied). It seems that meta_search_dobind_init does not accept the DN as a candidate, unless the match is unique (either through the global URI namespace definition, or through subtree-exclude rules). Both configurations have an idassert-bind set up with mode none, and also use the pseudo-root to bind when resolving. The configuration is as follows: # Database binding to active directories # -------------------------------------- database meta suffix "<basesuffix>" protocol-version 3 norefs yes lastmod off rebind-as-user yes readonly yes # Primary database in old LDAP structure # -------------------------------------- uri "ldap://dc01/<basesuffix>" chase-referrals no default-target idassert-bind bindmethod=simple binddn="<binddn1>" credentials="<bindpw1>" mode=none subtree-exclude dn.subtree:"ou=subsubou,ou=subou,<basesuffix>" # Secondary database in new LDAP structure # ---------------------------------------- uri "ldap://dc02/ou=subou,<basesuffix>" chase-referrals no idassert-bind bindmethod=simple binddn="<binddn2>" credentials="<bindpw2>" mode=none When binding as a user under <basesuffix> and not under ou=subou, this works fine and selects the first target to authenticate the user data. When binding as a user under ou=subsubou,ou=subou, this also works fine, and selects the second target to authenticate the user; both apply the corresponding baseDN transformations that are set up for the corresponding target. The problem starts when binding as user under ou=subou: 5df270ec conn=1000 op=0 meta_back_getconn: candidates=2 conn=ANON-TLS inserted 5df270ec conn=1000 op=0 >>> meta_back_search_start[0] 5df270ec conn=1000 op=0 >>> meta_search_dobind_init[0] 5df270ec conn=1000 op=0 <<< meta_search_dobind_init[0]=0 5df270ec conn=1000 op=0 <<< meta_back_search_start[0]=0 5df270ec conn=1000 op=0 >>> meta_back_search_start[1] 5df270ec conn=1000 op=0 >>> meta_search_dobind_init[1] 5df270ec conn=1000 op=0 <<< meta_search_dobind_init[1]=0 5df270ec conn=1000 op=0 <<< meta_back_search_start[1]=0 5df270ec conn=1000 op=0 meta_back_search: ncandidates=0 cnd="**" 5df270ec conn=1000 op=0 meta_back_search: base="cn=someuser,ou=subou,<basesuffix>" scope=0: no candidate could be selected I've tried to follow meta_search_dobind_init as to which part of the code causes the candidate to be rejected, but I've not found any specific part which would cause this/make clear why both candidates aren't applicable. Setting acl-authcDN and acl-passwd for the target also shows the same behaviour. Is this a known restriction for back-meta, or am I missing some configuration? Thank you for any hints! --- Heiko.

1 0

LMDB encryption support?
by Jens Alfke 13 Dec '19

13 Dec '19

I'm evaluating LMDB, and one feature we consider important is file-level encryption. The memory-mapped, zero-copy nature of LMDB would seem to be incompatible with encryption, but there is a tantalizing post from Howard Chu two years ago: > • To: "OpenLDAP-devel(a)openldap.org" <OpenLDAP-devel(a)openldap.org> > • Subject: LMDB encryption support > • From: Howard Chu <hyc(a)symas.com> > • Date: Thu, 10 Aug 2017 16:55:57 +0100 > > I've recently added support for page-level encryption to LMDB 1.x using user-supplied callbacks: ( https://www.openldap.org/lists/openldap-devel/201708/msg00002.html <https://www.openldap.org/lists/openldap-devel/201708/msg00002.html> ) However, the API shown in the email is not present in mainline LMDB (0.9.24), nor can I find it in a branch in the Git repository. Was this an abandoned experiment? Or is it only available with a commercial license (as is SQLite's encryption extension?) (Whether or not this feature still exists, I'm curious about how it was implemented. It seems like it would either require some kind of kernel-level support for hooking into the VM pager to rewrite pages after they're faulted in, or else not using memory-mapping at all and going with a page-cache a la SQLite.) Thanks, —Jens

2 1

Postgres and Attributes
by Mark Murawski 13 Dec '19

13 Dec '19

Hi! Attachments: www.kobaz.net/misc/slapd.zip www.kobaz.net/misc/ldap.sql www.kobaz.net/misc/attributes.png Disclaimer: Let me first start out saying that this isn't my first run around the block. I understand that this is experimental and I accept the risks and issues that might come with back-sql. I started with the backend examples located in: servers/slapd/back-sql/rdbms_depend/pgsql ... and then started adding support for things like organizationUnit that are not included in the test db Attached is my ldap postgres database. Attached is my ldap /etc/ldap/slapd I'm aware that passwords/etc are in there, but it's not a big deal. It's just testing stuff on an internal system. The issue I'm having: - Attributes are not coming back when requesting ldap information or doing ldap search (Screenshot) Also noted is that the sample inetOrgPerson entries do not show any attributes like surname, despite them being stored in the postgres database in what looks like the correct format (exactly the same as the test db import) -- The organizationUnit has been added like this: 1-users-ou.ldif ----- dn: ou=users,dc=directory, dc=pbx, dc=local ou: users description: holds users of the directory objectClass: organizationalUnit ----- ldapadd -x -D "cn=admin,dc=directory, dc=pbx, dc=local" -w 'asdf' -v -f 1-users-ou.ldif Despite having specified 'description', this has not been added to the database as shown in the export. The organizational_unit table looks like this: id | ou | description ----+----+------------- 1 | | Looking at the postgres query logs, slapd has made no attempt whatsoever to set the description field, despite this field being mapped in the attributes as shown in the export. Also here for quick reference: Table: ldap_attr_mappings -[ RECORD 16 ]+ id | 20 oc_map_id | 5 name | description sel_expr | organizational_unit.description sel_expr_u | from_tbls | organizational_unit join_where | add_proc | UPDATE organizational_unit SET description=? WHERE id=? delete_proc | SELECT 1 FROM organizational_unit WHERE ou = ? AND ID=? param_order | 3 expect_return | 0 Can someone shed some light on what's wrong here?

2 2

LMDB file compaction
by Jens Alfke 12 Dec '19

12 Dec '19

I have some questions/concerns about LMDB file size and the management of free space inside the file. These aren't things I've actually run into yet (I'm still in the investigation phase) but I know LMDB will grow the file up to the maximum map size and not shrink it. First off, I'm aware that this is an FAQ. I've read the documentation, and I think I understand LMDB's behavior fairly well. I've also read this 2015 post* by Howard Chu: > This is ultimately the question you must answer - how much space will you actually allow your app to use? Once you have that figure, configure it once and forget about it. It is *STUPID* to ask the OS to allocate space for you and then ask it to deallocate space repeatedly. You wind up fragmenting the disk and killing performance. Either you have enough disk space for the app's needs, or you don't. This is a fine answer for a server-side use case (which is of course what LMDB was designed for.) But I know from experience that server-side programmers often forget that not everything runs on servers... It is *not at all* a good answer for most client-side uses, where storage is shared by many different applications from different vendors, the user cannot be required to pre-configure how much space an application will need, and an application generally has no idea how much it'll be asked to store. It's *especially* non-applicable to mobile applications (the use case I'm investigating.) Phones and tablets are very often storage-constrained, and it's not kosher for an app to be holding onto a lot of free space it's not using. I'm sure everyone reading this has had the experience of trying to free up storage space on their phone by going into various apps and deleting lots of photos / messages / songs / whatever. In the case of an LMDB-based app I would expect that deleting content from the database would return storage space to the operating system. If it didn't, my next step would be to delete the app. I'm aware that an LMDB database can be compacted by writing a copy. Unfortunately this requires that the disk have free space equal to the current used space of the database, and that's often not the case in the situations where a user most needs to free up space. It would be more efficient to compact the file in place by moving in-use pages at the end of the file into holes, and then truncating the file. Alternatively, if the filesystem supports sparse files then LMDB could mark free pages as 'holes' in the file; does it do that? But I'm not sure if the filesystems on iOS or Android support this. (I know APFS has sparse file support, but last I checked it did not have a system call to punch a hole in a file.) —Jens * https://www.openldap.org/lists/openldap-technical/201511/msg00102.html

1 0

back-meta with overlapping DN spaces; bind operation does not find applicable target
by Heiko Wundram 12 Dec '19

12 Dec '19

Hello list, I'm trying to get back-meta running with two backends who have distinct namespaces, but should be exposed in an overlapping DN space, and while search operations and result transformations work fine, I'm having trouble getting the bind operation to try both directories for the login (after bindDN rewrite rules have been applied). It seems that meta_search_dobind_init does not accept the DN as a candidate, unless the match is unique (either through the global URI namespace definition, or through subtree-exclude rules). Both configurations have an idassert-bind set up with mode none, and also use the pseudo-root to bind when resolving. The configuration is as follows: # Database binding to active directories # -------------------------------------- database meta suffix "<basesuffix>" protocol-version 3 norefs yes lastmod off rebind-as-user yes readonly yes # Primary database in old LDAP structure # -------------------------------------- uri "ldap://dc01/<basesuffix>" chase-referrals no default-target idassert-bind bindmethod=simple binddn="<binddn1>" credentials="<bindpw1>" mode=none subtree-exclude dn.subtree:"ou=subsubou,ou=subou,<basesuffix>" # Secondary database in new LDAP structure # ---------------------------------------- uri "ldap://dc02/ou=subou,<basesuffix>" chase-referrals no idassert-bind bindmethod=simple binddn="<binddn2>" credentials="<bindpw2>" mode=none When binding as a user under <basesuffix> and not under ou=subou, this works fine and selects the first target to authenticate the user data. When binding as a user under ou=subsubou,ou=subou, this also works fine, and selects the second target to authenticate the user; both apply the corresponding baseDN transformations that are set up for the corresponding target. The problem starts when binding as user under ou=subou: 5df270ec conn=1000 op=0 meta_back_getconn: candidates=2 conn=ANON-TLS inserted 5df270ec conn=1000 op=0 >>> meta_back_search_start[0] 5df270ec conn=1000 op=0 >>> meta_search_dobind_init[0] 5df270ec conn=1000 op=0 <<< meta_search_dobind_init[0]=0 5df270ec conn=1000 op=0 <<< meta_back_search_start[0]=0 5df270ec conn=1000 op=0 >>> meta_back_search_start[1] 5df270ec conn=1000 op=0 >>> meta_search_dobind_init[1] 5df270ec conn=1000 op=0 <<< meta_search_dobind_init[1]=0 5df270ec conn=1000 op=0 <<< meta_back_search_start[1]=0 5df270ec conn=1000 op=0 meta_back_search: ncandidates=0 cnd="**" 5df270ec conn=1000 op=0 meta_back_search: base="cn=someuser,ou=subou,<basesuffix>" scope=0: no candidate could be selected I've tried to follow meta_search_dobind_init as to which part of the code causes the candidate to be rejected, but I've not found any specific part which would cause this/make clear why both candidates aren't applicable. Setting acl-authcDN and acl-passwd for the target also shows the same behaviour. Is this a known restriction for back-meta, or am I missing some configuration? Thank you for any hints! --- Heiko.

1 0

Re: OATH TOTP LDAP schema?
by Côme Chilliet 11 Dec '19

11 Dec '19

Le mercredi 4 décembre 2019, 13:28:36 CET Quanah Gibson-Mount a écrit : > Although perhaps this isn't exactly what was being asked for. I.e., the > module provides the ability to enable TOTP use with OpenLDAP, whereas > perhaps you're looking for a way to store data in LDAP as a backend for a > TOTP system? Yes this is more what I was looking for. How does the module handle the storing, there is no specific schema for this? -- Côme Chilliet FusionDirectory - https://www.fusiondirectory.org

4 3

RE:SASL authentication
by Peter Sui 09 Dec '19

09 Dec '19

HI, I'm trying to do a sasl bind with mechanism external, gssapi,digest-md5, after many tries, still did not get it work. Is there any sample code any where? Thanks! Peter

2 1

Sync replication, with failing consumer
by Marc Roos 06 Dec '19

06 Dec '19

With sync replication, having a provider at state C (newest) and a consumer starting with rid=100 and state=A. After syncing provider and consumer both are in state C When then the consumer is killed, and a new consumer is started with the same rid=100 and again state A. Does this consumer sync data from the provider again? Or does the provider has data stored of the previous consumer and block syncing?

2 1

Re: OATH TOTP LDAP schema?
by Dave Macias 04 Dec '19

04 Dec '19

Ooohhh! :o This is exciting On Dec 4, 2019, 12:19 PM -0500, Quanah Gibson-Mount <quanah(a)symas.com>, wrote: > > > --On Wednesday, December 4, 2019 12:11 PM -0500 Dave Macias > <davama(a)gmail.com> wrote: > > > Is 2.5 ETA still "when it's ready"? ;) > > The 2.5 release branch has been sync'd up and please test. ;) > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com>

2 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