- openldap-technical - openldap.org

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

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

04 Dec '19

Is 2.5 ETA still “when it’s ready”? ;) On Dec 4, 2019, 12:09 PM -0500, Quanah Gibson-Mount , wrote: > > > --On Wednesday, December 4, 2019 12:01 PM -0500 Dave Macias > <davama(a)gmail.com> wrote: > > > Does anyone knows if there is a publicly accessible schema for this? > > OpenLDAP already has a module providing this in OpenLDAP master that will > be released as a part of the upcoming 2.5 series. Definitely no need to > re-invent the wheel. ;) > > <https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;f=contrib/s…> > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com>

2 1

Symas OpenLDAP For Linux: RHEL8/CentOS8 now available
by Quanah Gibson-Mount 04 Dec '19

04 Dec '19

Symas is now providing free drop in builds for RHEL8/CentOS8 that provide the latest OpenLDAP 2.4.48 release. They can be obtained from: <https://repo.symas.com/sofl/rhel8/> As noted before, these binary packages are free to use. Support options are also available for production deployments (See <https://symas.com/linux-openldap-support/>). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

OATH TOTP LDAP schema?
by Côme Chilliet 04 Dec '19

04 Dec '19

Hello, We are working on implementing TOTP support in our application based on LDAP, and are looking for an LDAP schema for this. I found https://oath-ldap.stroeder.com but I can’t seem to find out the LDAP schema for this, allowing to store user tokens. Does anyone knows if there is a publicly accessible schema for this? -- Côme Chilliet FusionDirectory - https://www.fusiondirectory.org

3 2

Adding ACL to an Attribute
by Drukpa Kunley 03 Dec '19

03 Dec '19

Hi all, SYSTEM: NethServer-7.6.1810, a distro using Centos7.6.1810 OpenLDAP: openldap-2.4.44-21.el7_6.x86_64 Extra package: Self Service Password I am using Self Service Password with question/answer method to change the password. I store the answer in an attibute named: info. $answer_objectClass = "extensibleObject"; $answer_attribute = "info"; The original Account provider is LDAP which I want to replace with Active Directory. All the user have to choose a question/answer before I replace LDAP with AD as the Account provider. While LDAP is still the Account provider, anybody with console access to the server can see the question/answer using the command: # ldapsearch -D cn=libuser,dc=directory,dc=nh -w `cat /var/lib/nethserver/secrets/libuser` -h 127.0.0.1 # toto, People, directory.nh dn: uid=toto,ou=People,dc=directory,dc=nh ... objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson objectClass: extensibleObject shadowLastChange: 18220 userPassword:: cm9ibTEyMDQ0OQ== info: {car}Honda I created a Virtual Machine to test the scenario with 3 users. In NethServer, the original Account provider is LDAP. I did a script to extract the users and their answers to file.ldif I remove LDAP. I install Active Directory module. I import the users/groups to AD. In the importation, AD creates new passwords for the imported users. I add a section to Self Service Password for AD. I modify AD with info.ldip to include the answer. # /usr/bin/systemd-run -M nsdc -q -t /usr/bin/ldbmodify -H /var/lib/samba/private/sam.ldb /var/lib/samba/private/file.ldif Modified 3 records successfully # The users can then modify their password responding to the same question/answer they had with LDAP. All is working perfectly. PROBLEM: I cannot encrypt the answer in LDAP because when I import the users to Active Directory, it cannot reads the encrypted answer. I think that AD is using another way to encrypt/decypt? If I don't encrypt the answer, the importation to AD is working correctly. While still using LDAP as Account provider and before I change it to Active Directory, I would like to add an additional ACL so nobody can read the answer stored in "info". After googling a lot I found a way to describe the ACL. I hope it is the right way. access to attrs=info by self write by anonymous auth by group="cn=domain admins,ou=Groups,dc=directory,dc=nh" write by * none How can I create the content of newacl.ldif file to be able to add that ACL to OpenLDAP (ldapmodify -Y EXTERNAL -H ldapi:/// -f /temp/newacl.ldif) Thank you, Drukpa

2 1

Is there a way to set a preference on entries with multiple userPassword attributes?
by Jeremy Diaz 03 Dec '19

03 Dec '19

Hello, Currently I have ldap entries with 2 userPassword attributes. One is a regular SHA password which the other one delegates to sasl. However this results in all entries binding through sasl rather than locally. I need some entries to default to sasl and other entries to default to SHA but still failover to the other password entry. Is this possible through openldap? Thanks, Jeremy -- Jeremy Diaz Rex Consulting, Inc 5652 Florence Terrace, Oakland, CA 94611 email: jeremy.diaz(a)rexconsulting.net web: [ http://www.rexconsulting.net/ | http://www.rexconsulting.net ] phone, toll-free: +1 (888) 403-8996 EXT: 5 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. has been a California Corporation since 2001.

2 2

acl help access to 'own' attributes
by Marc Roos 30 Nov '19

30 Nov '19

Can anyone help how I should make the acls that allows users[2] access attributes of ldap entries[1] that have themselves listed in the attribute value sendmailMTAMapValue Something like: Access to children? ou=xxxx,ou=dddd,ou=cccc,dc=bbbb,dc=aaaa,dc=local filter=(sendmailMTAMapValue=VAR1) attrs=sendmailMTAKey by uid=VAR1,ou=yyyy,ou=dddd,ou=cccc,dc=bbbb,dc=aaaa,dc=local read [1] dn: sendmailMTAKey=test(a)example.com,ou=xxxx,ou=dddd,ou=cccc,dc=bbbb,dc=aaaa, dc=local objectClass: sendmailMTA objectClass: sendmailMTAMap objectClass: sendmailMTAMapObject objectClass: ritAdditionalInfo sendmailMTAMapName: virtuser sendmailMTACluster: mail sendmailMTAKey: test(a)example.com sendmailMTAMapValue: testuser [2] uid=testuser,ou=yyyy,ou=dddd,ou=cccc,dc=bbbb,dc=aaaa,dc=local

3 6

Does copying lock.mdb and data.mdb give syncrep errors?
by Marc Roos 29 Nov '19

29 Nov '19

Can I just copy the mdb databases to a different server, or are there 'unique' values inside?

2 1

own dynamic posix-group
by Stefan Kania 26 Nov '19

26 Nov '19

Hello, I try to set up my own posix-group to get a dynamic posix-group to use it to give filesystempermission. So I did the following: 1. Create to new objectclasses: ------------ objectclass (1.3.6.1.4.1.23456.1.2.1 NAME 'stkaPosixGroup' DESC 'advanced PosixGroup for dynamic use' SUP top AUXILIARY MUST ( cn $ gidNumber ) MAY ( userPassword $ memberUid $ description ) ) objectclass (1.3.6.1.4.1.23456.1.2.2 NAME 'stkaPosixAccount' DESC 'advanced PosixAccount for dynamic use' SUP posixAccount AUXILIARY MAY ( memberUID )) ------------ YES I know 23456 is not my ODI. It's still a test! 2. Then I configured the dynlist-overlay in slad.conf ------------ overlay dynlist dynlist-attrset groupOfURLs MemberURL ------------ 3. I created a new dynamic group: ------------ dn: cn=dynposix,ou=groups,dc=example,dc=net objectClass: groupOfURLs objectClass: stkaPosixGroup gidNumber: 5000 cn: dynposix memberURL: ldap:///dc=example,dc=net?memberuid?sub?(title=admin) ------------ 4. I added the new objectclass stkaPosixAccout to my users: ------------ dn: cn=Stefan Kania,ou=users,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: stkaPosixAccount loginShell: /bin/bash homeDirectory: /home/skania uid: skania cn: Stefan Kania userPassword:: e1NTSEF9cVk4eDVEaVhmYTZxbEw4MDBnRTlkazdtVDd2TzVocUI= uidNumber: 10000 gidNumber: 10000 sn: Kania givenName: Stefan memberUid: skania title: admin ------------ 5. I set the attribute "title" for two users to "admin" and got ------------ root@ldapserver:/# ldapsearch -x -D cn=admin,dc=example,dc=net -W -LLL 'cn=dynposix' dn: cn=dynposix,ou=groups,dc=example,dc=net objectClass: groupOfURLs objectClass: stkaPosixGroup gidNumber: 5000 cn: dynposix memberURL: ldap:///dc=example,dc=net?memberuid?sub?(title=admin) memberUid: skania memberUid: ktom ------------ So my users are member of the group. 5. I use the sssd as ldap-client so I changed the configuration to: ------------ [sssd] config_file_version = 2 services = nss, pam domains = EXAMPLE [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] reconnection_retries = 3 offline_credentials_expiration = 2 offline_failed_login_attempts = 3 offline_failed_login_delay = 5 [domain/EXAMPLE] ldap_schema=rfc2307 ldap_uri = ldap://ldapserver.example.net:389 ldap_search_base=dc=example,dc=net ldap_default_bind_dn=uid=sssd-user,ou=users,dc=example,dc=net ldap_default_authtok=geheim id_provider=ldap auth_provider=ldap chpass_provider = ldap ldap_chpass_uri = ldap://ldapserver.example.net:389 cache_credentials = True ldap_tls_cacertdir = /etc/ssl/zertifikate/demoCA ldap_tls_cacert = /etc/ssl/zertifikate/demoCA/cacert.pem ldap_id_use_start_tls = True ldap_group_object_class = stkaPosixGroup enumerate = true ------------ I added the line "ldap_group_object_class = stkaPosixGroup" I Know "enumerate = true" is not a good idea but it's still a test ;-) Now the tests: --------- getent group . . dynposix:*:5000: . . -------- The group will be listed but non of the members. So I did the following: -------- root@ldapserver:~# ldapsearch -x -D cn=admin,dc=example,dc=net -W -LLL 'cn=dynposix' dn: cn=dynposix,ou=groups,dc=example,dc=net objectClass: groupOfURLs objectClass: stkaPosixGroup gidNumber: 5000 cn: dynposix memberURL: ldap:///dc=example,dc=net?memberuid?sub?(title=admin) memberUid: skania memberUid: ktom -------- There are two memberUid entries. Now I did another test searching for "memberuid" -------- root@ldapserver:~# ldapsearch -x -D cn=admin,dc=example,dc=net -W -LLL 'memberuid=*' attrs dn dn: cn=Stefan Kania,ou=users,dc=example,dc=net dn: cn=Kater Tom,ou=users,dc=example,dc=net -------- As you can see, I only get the two users but not my group "dynposix" listed. When i do a "id ktom" I got: -------- root@ldapserver:~# id ktom uid=10001(ktom) gid=10000 groups=10000 -------- Also no group "dynposix" It looks like it is not possible to search for the attribute "memberUid" if it's assigned to a groupOfUrls. Does anyone has an idea where did something wrong? -- Stefan Kania

2 2

switching to containers, slapd tuning?
by Marc Roos 23 Nov '19

23 Nov '19

I have now setups with vm's with a local slapd and nscd for caching authentication requests. If I separate these processes eg. different container for slapd, different container for the application that does system authentication. I will not be able to share cache memory etc. I was wondering if I would ever be able to come near this performance with direct communication between slapd and the application (thus without something like nscd) and how to tune slapd.

1 0

SSL / TLS 1.0 - exposed in SSF?
by Aaron Bennett 22 Nov '19

22 Nov '19

Hi, I'm looking to determine if clients connecting to my OpenLDAP directory are using obsolete protocols (such as SSL, TLS 1.0, etc). Are the connection details exposed in the SSF value of the connection, or exposed elsewhere the log? Best, Aaron --- Aaron Bennett Manager of Systems Administration Clark University ITS

2 3

Re:Re: It seems that the Tls cipher settings in ldap client and server not work.
by Quanah Gibson-Mount 22 Nov '19

22 Nov '19

--On Thursday, November 14, 2019 11:17 AM +0800 莫亚男 <nanmor(a)126.com> wrote: > > > Hi Quanah, > > > Sorry for reply so late. We download the package and self-built. > we used below commands: > env CPPFLAGS=-I/usr/local/src/openssl-1.1.1/include > LDFLAGS=-L/usr/local/ssl/lib ./configure > make depend > make > make install Hi Nancy, Please keep replies on the technical list. Which OpenSSL 1.1.1 release are you linking to? Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

Page Leak?
by Andrew Spott 20 Nov '19

20 Nov '19

I apologize if this is the wrong place to ask this, let me know if there is someplace better. So, when doing a `mdb_copy -c`, I've run into the error message: mdb_copy: copying failed, error -30784 (MDB_INCOMPATIBLE: Operation and DB incompatible, or DB flags changed) When looking at the mdb_copy man page, it says that mdb_copy with compaction might fail if the database has a 'page leak'. Since that appears to be what has happened... can anyone tell me what that means? Does this mean that the data could be corrupted? How do I fix this? Thanks! -Andew

2 6

Mailman list?
by Zinski, Steve 19 Nov '19

19 Nov '19

We are in the process of migrating from a sendmail/virtuser environment to proofpoint/ldap mail routing. This means we have to add the inetLocalMailRecipient class to all of our users along with mail/mailLocalAddress/mailRoutingAddress attributes. We also need to create routing records for our mailman mailing list aliases (i.e., list-admin, list-bounces, list-request, list-subscribe, etc.). What is the best way to add these addresses to ldap? I was thinking about adding a “mailman” container (regular users go in “people”) but I don’t know what structural object class to use for each mailman entry. Do I use person (or inetOrgPerson)? I want to do this right, so any best-practice tips would be welcome. Any help would be appreciated. Thanks, Steve

1 0

slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
by Jean-Francois Malouin 16 Nov '19

16 Nov '19

Hi, Since I started adding clients to authenticate users through LDAP I'm getting those messages in the servers log: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16 Clients use nss-ldapd 0.9.9 with nslcd and nscd for caching. Servers are running OpenLDAP 2.4.47 on Debian/Stretch 9.11. A quick search shows those are related to deref control. I don't have that overlay loaded on the servers, only slapo-memberof, slapo-syncprov, slapo-refint and slapo-ppolicy So I wonder if, first, are they harmfull? Or will they get eventually as the number of clients will start to increase in the very near future? thanks, jf

2 3

Acl on userPassword on a specfic base
by Marc Roos 12 Nov '19

12 Nov '19

I have problems authenticating against this acl[0] with nslcd, if I use[1] authentication is fine. I have the impression the dn.exact is not able to access the password attribute, because getent shows the other attributes. How should I rewrite this so the dn.exact is able to read the password attributes from dn.subtree? [0] olcAccess: {0} to dn.exact="" by * read olcAccess: {1} to dn.exact="cn=Subschema" by * read olcAccess: {2} to attrs=userPassword,shadowLastChange by ssf=256 self read by ssf=256 anonymous auth by * none continue olcAccess: {3} to dn.subtree="ou=gggg,ou=ffff,ou=eee,dc=ccc,dc=bbb,dc=aaa" by dn.exact="cn=system,ou=dddd,dc=ccc,dc=bbb,dc=aaa" ssf=64 read olcAccess: {4} to * by * none [1] olcAccess: {0} to dn.exact="" by * read olcAccess: {1} to dn.exact="cn=Subschema" by * read olcAccess: {2} to attrs=userPassword,shadowLastChange by ssf=256 self read by ssf=256 anonymous auth by * none olcAccess: {3} to * by ssf=64 users read by * none

2 1

It seems that the Tls cipher settings in ldap client and server not work.
by 莫亚男 12 Nov '19

12 Nov '19

Hi Friends, My open-ldap server is Version: 2.4.46 OS: redhat7 I set the parameter about cipher suite in client(ldap.conf) and server (slapd.conf) and restart the service, the tcp/ip log, find the cipher not changed. In ldap.conf: TLS_CIPHER_SUITE ALL:!TLSv1.3 In slapd.conf: TLSCipherSuite !TLSv1.3 openssl provide those cipher suites: [root@ ~]# openssl ciphers -v 'TLSv1.3' TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD when openldap worked as a client, it send 4 cipher suites to server in TLS1.3 client hello. Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303) Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) When openldap worked as a server, it used TLS_AES_256_GCM_SHA384 to connect in TLS server hello. And when i set one specific cipher in client, TLS_CIPHER_SUITE TLS_CHACHA20_POLY1305_SHA256 It also send same four suites in client hello. Could you help me to have a look? thanks.

2 1

syncprov overlay and autogroup
by Martin Pittamitz 04 Nov '19

04 Nov '19

Good day I have recently added a syncprov configuration and consumer node to our OpenLDAP setup. On our master we use the overlays "memberOf" and "autogroup". Now a specific error occurs on the consumer node, where "group1" has objectClass "groupOfURLs": > Oct 29 16:39:18 user slapd[26309]: autogroup_modify_entry attempted to > modify group's <cn=group1,ou=groups,dc=example,dc=net> member attribute > Oct 29 16:39:18 user slapd[26309]: send_ldap_result: conn=-1 op=0 p=3 > Oct 29 16:39:18 user slapd[26309]: send_ldap_result: err=19 matched="" > text="attempt to modify dynamic group member attribute" > Oct 29 16:39:18 user slapd[26309]: syncrepl_null_callback : error code > 0x13 > Oct 29 16:39:18 user slapd[26309]: syncrepl_entry: rid=001 be_modify > cn=group1,ou=groups,dc=example,dc=net (19) > Oct 29 16:39:18 user slapd[26309]: syncrepl_entry: rid=001 be_modify > failed (19) > Oct 29 16:39:18 user slapd[26309]: do_syncrepl: rid=001 rc 19 quitting Can anyone point me in the right direction here? Is autogroup simply incompatible with such a syncprov setup? Best regards, Martin

2 3

Q: slapd[1668]: connection_input: conn=143303 deferring operation: too many executing
by Ulrich Windl 31 Oct '19

31 Oct '19

Hi! I have this question: Is there a monitoring count for events like this?: slapd[1668]: connection_input: conn=143303 deferring operation: too many executing Regards, Ulrich Windl

1 0

Garbled objectClass
by Saša-Stjepan Bakša 24 Oct '19

24 Oct '19

Is there any good reason that I see one of my custom objectClass garbled like this below. It happens when I am reading content from file. From GUI tool it looks as it should. olcObjectClasses:: ezZ9KCAxLjMuNi4xLjQuMS4zNTI2OS4zLjI0NS4yLjcgTkFNRSAncGNyZ lBhY2thZ2UnIERFU0MgJ0NvbW1vbiBwYWNrYWdlIGRlc2NyaXB0aW9uIOKAkyBzZXJ2aWNlIHBh cmFtZXRlcnMgZGVmaW5lZCBieSBNTk8nIFNVUCB0b3AgU1RSVUNUVVJBTCBNVVNUICggcGNyZlB hY2thZ2VUaXRsZSAkIHBhY2thZ2VMaWZldGltZVR5cGUgKSBNQVkgKCBwYWNrYWdlQWN0aXZhdG lvbkRhdGUgJCBwYWNrYWdlRXhwaXJ5RGF0ZSAkIHBhY2thZ2VDeWNsZSAkIHRvdGFsTWF4aW11b VZvbHVtZSAkIHRvdGFsTWF4aW11bVRpbWUgJCBtb25pdG9yaW5nS2V5ICQgdG90YWxNYXhpbXVt QW1vdW50ICQgY3ljbGVNdWx0aXBsaWVyICkgKQ== Others are normal and human readable.

6 7

Antw: Garbled objectClass
by Ulrich Windl 24 Oct '19

24 Oct '19

>>> Ulrich Windl schrieb am 24.10.2019 um 08:12 in Nachricht <5DB140BA.E78 : 161 : 60728>: >>>> Saša-Stjepan Bakša <ssbaksa(a)gmail.com> schrieb am 23.10.2019 um 16:52 in > Nachricht > <CANk+c=2QFqT8uNdJDTdv_A_1j-r4H5+w3k+j1XdVhX9iZ3SVXA(a)mail.gmail.com>: > > Is there any good reason that I see one of my custom objectClass garbled > > like this below. It happens when I am reading content from file. From GUI > > tool it looks as it should. > > > > olcObjectClasses:: ezZ9KCAxLjMuNi4xLjQuMS4zNTI2OS4zLjI0NS4yLjcgTkFNRSAncGNyZ > > lBhY2thZ2UnIERFU0MgJ0NvbW1vbiBwYWNrYWdlIGRlc2NyaXB0aW9uIOKAkyBzZXJ2aWNlIHBh > > cmFtZXRlcnMgZGVmaW5lZCBieSBNTk8nIFNVUCB0b3AgU1RSVUNUVVJBTCBNVVNUICggcGNyZlB > > hY2thZ2VUaXRsZSAkIHBhY2thZ2VMaWZldGltZVR5cGUgKSBNQVkgKCBwYWNrYWdlQWN0aXZhdG > > lvbkRhdGUgJCBwYWNrYWdlRXhwaXJ5RGF0ZSAkIHBhY2thZ2VDeWNsZSAkIHRvdGFsTWF4aW11b > > VZvbHVtZSAkIHRvdGFsTWF4aW11bVRpbWUgJCBtb25pdG9yaW5nS2V5ICQgdG90YWxNYXhpbXVt > > QW1vdW50ICQgY3ljbGVNdWx0aXBsaWVyICkgKQ== > > > > Others are normal and human readable. > > That BASE64 says: > {6}( 1.3.6.1.4.1.35269.3.245.2.7 NAME 'pcrbase64: invalid input Sorry, that was due to indent of BASE64. It says: {6}( 1.3.6.1.4.1.35269.3.245.2.7 NAME 'pcrfPackage' DESC 'Common package description – service parameters defined by MNO' SUP top STRUCTURAL MUST ( pcrfPackageTitle $ packageLifetimeType ) MAY ( packageActivationDate $ packageExpiryDate $ packageCycle $ totalMaximumVolume $ totalMaximumTime $ monitoringKey $ totalMaximumAmount $ cycleMultiplier ) ) > >

1 0

LDAP loadbalancer with URL redirect
by Olivier - 20 Oct '19

20 Oct '19

Hi, I have two different LDAP ldap://ldap1 and ldap://ldap2 behind a same public IP 10.0.0.1 Is there a solution to make a reverse proxy with redirection ? I mean if a LDAP request arrive to 10.0.0.1 with URI target "ldap://ldap1" , the request is redirected to server ldap1. Thanks.

3 2

Retrieve deleted user accounts
by Michael Starling 15 Oct '19

15 Oct '19

Is there any OpenLDAP control equivalent to the Microsoft's >> LDAP_SERVER_SHOW_DELETED_OID = "1.2.840.113556.1.4.417" ? I would like to pull a list of user accounts that have been deleted along with the corresponding date/time. Mike

5 4

TLS Connectivity
by Howard.Gillison＠gvltec.edu 12 Oct '19

12 Oct '19

Good morning to you, I have a question regarding the user of LDAP_* calls while programming in C. I am on an Oracle/Sun Solaris machine running Solaris 11.3. I am writing my code via Oracle Solaris Studio version 12.4. I do have OpenLdap v2.4.30 installed on my machine. ( /user/lib/slapd -VV returns: @(#) $OpenLDAP: slapd 2.4.30 (Feb 9 2017 12:37:50) $ @ul11sru-build:/builds/ul11u3sru-gate/components/openldap/build/sparcv7/servers/slapd) NOTE: the services are NOT up and running. I have no ldap server running on this machine. I am simply writing code using the LDAP_* service calls. In previous releases, there were some calls available to the effect of LDAP_START_TLS or LDAP_START_SSL and some others. All of those calls are now gone and as far as I can tell, not available in any form. With that said, my current code runs correctly and executes if I use port 389 to talk to an Active Directory Server. There is no problem, and I get back a valid response from my code, and I have gone through a pretty substantial set of testing to verify that the code is indeed accurate and valid. I even raided a site that had a sample code set for a bind and copied/modified that and tested it as well. My code and my raided code work correctly. If, however, I change the default port to be port 636, the code fails when I attempt to bind via LDAP_SIMPLE_BIND_S. The specific error code returned to me is an Error Code 91 and the LDAP_ERR2STRING result is: "Can't connect to the LDAP server". The Error Code implies that the system is down - OR - it is not available. If I change the default port back to 389, the code works. My conclusion is that I am having difficulty with the remote Active Directory Server "trusting" my server. I have OpenSSL on my machine, and I have the Private Certificate from the remote Active Directory Server installed along with the appropriate CA certificates and L1R chain. If I issue an "openssl s_client -showcerts -connect tbdca.gvl.gtech.pri:636" I do get a valid connection and get the following output result: CONNECTED(00000004) depth=2 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms<http://www.entrust.net/legal-terms>, OU = "(c) 2012 Entrust, Inc. - for authorized use only", CN = Entrust Root Certification Authority - G3 verify return:1 depth=1 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms<http://www.entrust.net/legal-terms>, OU = "(c) 2014 Entrust, Inc. - for authorized use only", CN = Entrust Certification Authority - L1R verify return:1 depth=0 C = US, ST = South Carolina, L = Greenville, O = Greenville Technical College, CN = gtech.pri verify return:1 The certificate named gtech.pri is the Certificate loaded on the Active Directory Domain Controllers. It is a Private SSL certificate with Subject Alternative Names. I forget precisely where I read this and I've tried to locate the document again - but perhaps one of you may know. It seems that the document was indicating that in order to connect to the Active Directory server, the CN and DN of the certificates had to exactly match. (I can't find the document now, so I can't recall the wording. If that is the case, it makes a private certificate rather worthless and makes a SAN certificate worthless from the outset - but OpenSSL does in fact verify the connection) Since there are no longer any LDAP_START_* for security, I have a dilemma of sorts. I have noticed in the ldap.conf man pages that it is possible to create a .ldaprc file in a user's local directory. Given that I could do that, will it work? Will that give me the access capability that I'm seeking? (again, I am NOT running an LDAP server on this machine. I'm simply coding a program in C that will make a connection to an Active Directory Server and it must be a secure connection) There are several parameters inside of the ldap.conf file that can point back to the certificate base and the certificate directory. There has to be some sort of mechanism to do this since the LDAP_START_TLS commands and so forth have been removed. Many thanks for your input and thanks for your patience in reading this! All the best, Howard This electronic mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. To the best of our ability and knowledge, this mail message has been scanned and is free of viruses and malware.

3 2

No version information available
by Leo Führinger 08 Oct '19

08 Oct '19

Hello, I've installed the newest version 2.4.48 of openldap on Ubuntu 18.04: vergrößern ./configure --with-cyrus-sasl --with-tls=openssl --enable-overlays=mod --enable-backends=mod --disable-perl --disable-ndb --enable-crypt --enable-modules --enable-dynamic --enable-syslog --enable-debug --enable-local --enable-spasswd --disable-sql --enable-mdb make depend make #test make test > test_results.txt grep '>>>>>.*failed' test_results.txt #install make install If I run the scritp 'sudo sh updateOpenldap.sh' which includes the command ldapdelete -x -r -D cn=admin,dc=aesettlingen,dc=ddnss,dc=de -w geheim ou=benutzer,dc=schule,dc=ddnss,dc=de >> updateOpenldap.log 2>> updateOpenldap.errorlog everything works fine. If I use a cronjob via crontab */1 * * * * /bin/bash /home/ldap/convertADtoOpenldap/updateOpenldap.sh I get the errors: ldapdelete: /usr/local/lib/liblber-2.4.so.2: no version information available (required by ldapdelete) ldapdelete: /usr/local/lib/libldap-2.4.so.2: no version information available (required by ldapdelete) LDAP vendor version mismatch: library 20448, header 20445 Here the content of /usr/lib/ vergrößern 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 root@ldapserver:/# ls -lah /usr/lib/lib* lrwxrwxrwx 1 root root 21 Mai 14 09:07 /usr/lib/libDeployPkg.so.0 -> libDeployPkg.so.0.0.0 -rw-r--r-- 1 root root 31K Mai 14 09:07 /usr/lib/libDeployPkg.so.0.0.0 lrwxrwxrwx 1 root root 15 Dez 19 2018 /usr/lib/libgjs.so.0 -> libgjs.so.0.0.0 -rw-r--r-- 1 root root 820K Dez 19 2018 /usr/lib/libgjs.so.0.0.0 lrwxrwxrwx 1 root root 20 Mai 14 09:07 /usr/lib/libguestlib.so.0 -> libguestlib.so.0.0.0 -rw-r--r-- 1 root root 23K Mai 14 09:07 /usr/lib/libguestlib.so.0.0.0 lrwxrwxrwx 1 root root 16 Mai 14 09:07 /usr/lib/libhgfs.so.0 -> libhgfs.so.0.0.0 -rw-r--r-- 1 root root 160K Mai 14 09:07 /usr/lib/libhgfs.so.0.0.0 lrwxrwxrwx 1 root root 31 Sep 16 17:37 /usr/lib/libldap-2.4.so.2 -> /usr/local/lib/libldap-2.4.so.2 lrwxrwxrwx 1 root root 17 Sep 4 2018 /usr/lib/libnetpbm.so.10 -> libnetpbm.so.10.0 -rw-r--r-- 1 root root 143K Apr 23 2016 /usr/lib/libnetpbm.so.10.0 lrwxrwxrwx 1 root root 18 Mai 14 09:07 /usr/lib/libvgauth.so.0 -> libvgauth.so.0.0.0 -rw-r--r-- 1 root root 84K Mai 14 09:07 /usr/lib/libvgauth.so.0.0.0 lrwxrwxrwx 1 root root 19 Mai 14 09:07 /usr/lib/libvmtools.so.0 -> libvmtools.so.0.0.0 -rw-r--r-- 1 root root 609K Mai 14 09:07 /usr/lib/libvmtools.so.0.0.0 and /usr/local/lib/ vergrößern 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 root@ldapserver:/# ls -lah /usr/local/lib/lib* lrwxrwxrwx 1 root root 22 Okt 3 18:11 /usr/local/lib/liblber-2.4.so.2 -> liblber-2.4.so.2.10.11 -rw-r--r-- 1 root root 222K Okt 3 18:11 /usr/local/lib/liblber-2.4.so.2.10.11 -rw-r--r-- 1 root root 223K Sep 12 2018 /usr/local/lib/liblber-2.4.so.2.10.8 -rw-r--r-- 1 root root 223K Sep 11 2018 /usr/local/lib/liblber-2.4.so.2.10.9 -rw-r--r-- 1 root root 375K Okt 3 18:11 /usr/local/lib/liblber.a -rw-r--r-- 1 root root 827 Okt 3 18:11 /usr/local/lib/liblber.la lrwxrwxrwx 1 root root 22 Okt 3 18:11 /usr/local/lib/liblber.so -> liblber-2.4.so.2.10.11 lrwxrwxrwx 1 root root 22 Okt 3 18:11 /usr/local/lib/libldap-2.4.so.2 -> libldap-2.4.so.2.10.11 -rw-r--r-- 1 root root 1,4M Okt 3 18:11 /usr/local/lib/libldap-2.4.so.2.10.11 -rw-r--r-- 1 root root 1,4M Sep 12 2018 /usr/local/lib/libldap-2.4.so.2.10.8 -rw-r--r-- 1 root root 1,4M Sep 11 2018 /usr/local/lib/libldap-2.4.so.2.10.9 -rw-r--r-- 1 root root 2,8M Okt 3 18:11 /usr/local/lib/libldap.a -rw-r--r-- 1 root root 876 Okt 3 18:11 /usr/local/lib/libldap.la lrwxrwxrwx 1 root root 24 Okt 3 18:11 /usr/local/lib/libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.10.11 -rw-r--r-- 1 root root 1,6M Okt 3 18:11 /usr/local/lib/libldap_r-2.4.so.2.10.11 -rw-r--r-- 1 root root 1,6M Sep 12 2018 /usr/local/lib/libldap_r-2.4.so.2.10.8 -rw-r--r-- 1 root root 1,6M Sep 11 2018 /usr/local/lib/libldap_r-2.4.so.2.10.9 -rw-r--r-- 1 root root 3,1M Okt 3 18:11 /usr/local/lib/libldap_r.a -rw-r--r-- 1 root root 899 Okt 3 18:11 /usr/local/lib/libldap_r.la lrwxrwxrwx 1 root root 24 Okt 3 18:11 /usr/local/lib/libldap_r.so -> libldap_r-2.4.so.2.10.11 lrwxrwxrwx 1 root root 22 Okt 3 18:11 /usr/local/lib/libldap.so -> libldap-2.4.so.2.10.11 Does somebody has any idea? Thanks a lot! Leo

2 2

not getting ldap proxy to AD working... please help
by Drikus Brits 08 Oct '19

08 Oct '19

Heya experts. I need some guidance. I am having difficulty deploying my requirements. I need to deploy a couple of U18 servers/containers. These servers all needs to authenticate with LDAP accounts that is active and in a certain group on AD, but the IT team doesn't want to allow IPs and ports from servers across the network and so I have to set up a ldap proxy that will speak to AD on behalf of all the other machines eg jumphost. The windows AD cannot be modified to add extra groups eg posixAccount, uidNumber, gidNumber, loginShell, homeDirectory etc. I can successfully run a ldapsearch from the proxy machine to the AD and query a user based on the sAMAccountName and am getting successful results back from AD. However, when the jumphost (proxy set as ldap authhost) tries to authenticate with the proxy, then I see the request coming in from the jumphost to ldap proxy, and see the ldap proxy sending the request to the windows AD, but it forwards the same details as it sent to the local to the remote; eg objectClass=posixAccount, uid=testuser. This doesn't exist on the AD and so returns no result. I've tried to do rewrites and according to the packet captures, saw that the rewrite was working somewhat. I was able to rewrite uid to sAMAccountName, but not sure what to rewrite the posixAccount to.... So ideally what I'd like to see happening is that : 1) user logs onto jumphost with username "testuser" 2) user lookup & authentication goes to ldap_proxy 3) ldap_proxy send request to AD to check if user exists and is active and match against the password 4) upon username=exists, is=active, password=ok return the result to ldap_proxy 5) ldap_proxy returns the necessary to jumphost eg; a) posixAccount b) homeDirectory c) loginShell I've tried following a couple of different options to make it work, but right now I'm not sure which option is the correct one eg; (mdb config + ldap backend) or (meta + ldap backend ) or ( ldap + pcache ) and whether to rewrite or not to rewrite. From my understanding, I am looking for something that sounds like a meta setup that combines the local and remote data...is my understanding correct? I've seen this working at a previous employer but not sure whether their AD was modified and that is why it was working there, or whether the solution is workable without having to force the IT guys' hand and add extra vars.. I've scouted the openldap mailing list as well for answers but there is a plethora of no replies and some replies that somewhat matches what I'm trying to do... Any guidance would be super appreciated

2 2

Lazy quantifiers in regex ACLs??
by Jon C Kidder 02 Oct '19

02 Oct '19

Does the regex engine in OpenLDAP not support lazy quantifiers? Why does the ACL processing in this log show only one capture group as if the lazy quantifier in the first capture group isn't recognized? Every tester I plug this regex into produces 2 capture groups which is what I need. I need to carve off the leading OU as one capture group and capture the remaining chain of OUs as the second group then re-use both in my ACLs. Any suggestions for creating a regex that would produce the desired capture groups for use in my ACLs? 5d94aa15 => dnpat: [18] (ou=.+?,)?(ou=.+,)?ou=Delegated,ou=ApplicationData,dc=global,dc=aep,dc=com$ nsub: 2 5d94aa15 => acl_get: [18] matched 5d94aa15 => acl_get: [18] attr entry 5d94aa15 => match[dn0]: 0 95 ou=testapplication,ou=bolt,ou=concourse,ou=delegated,ou=applicationdata,dc=global,dc=aep,dc=com 5d94aa15 => match[dn1]: 0 40 ou=testapplication,ou=bolt,ou=concourse,

2 2

Change OID of existing custom Attribute
by Tobias Hachmer 30 Sep '19

30 Sep '19

Hello, running here OpenLDAP 2.4.42 on Ubuntu 16.04 with a hdb Database. Some old admin have added 2 custom attributes to the standard nis.schema, years ago. For this OIDs from nis schema has been chosen (1.3.6.1.1.1.1.2.x). I would like to fix that: Is it possible to move these custom Attributes to our custom Schema, while changing OIDs, also? Or do we have to clear the data DB, move the attrs and reimport a data backup? Thanks in advance, Tobias

3 9

N-Way Multimaster with syncrepl and delta-repl - LDAP Server not able to start after configuring
by Oliver Dörr 26 Sep '19

26 Sep '19

Hi, I already found two mail threads regarding my post but they do not help. I'm trying to setup a N-Way Multi-Master configuration following https://openldap.org/doc/admin24/replication.html section 18.3.3 with two masters.(su40v314 / su40v315) Using my process list I have started my server su40v314 with root 35523 1 0 Sep25 ? 00:00:02 /opt/symas/lib64/slapd -u root -g ldapadmi -h ldap://0.0.0.0:8653/ ldaps://0.0.0.0:8652/ -F /solshg/test2/etc So I believe that olcServerID should be olcServerID: 1 ldaps://su40v314:8652/ olcServerID: 2 ldaps://su40v315:8652/ but when I restart the server I get Sep 26 11:05:40 su40v314 slapd[129788]: read_config: no serverID / URL match found. Check slapd -h arguments. Same behaviour, if I change the HOST_LIST to "ldap://su40v314:8653/ ldaps://su40v314:8652/" Any ideas what I missed? Regards Oliver

2 1

How do I add the 'dialupAccess' attribute ....
by Paul Pathiakis 24 Sep '19

24 Sep '19

Quanah, Thank you for everything. It all works. :) (Something very strange had occurred with the 389 port being in a strange state that forced me to, finally, reboot as there was nothing running and even netstat, netcat and everything else said somethign was running but ps -elf said slapd wasn't there. *shrug*) My latest problem: I have the freeradius schema in my schemas. I verified this: ls -sal /etc/openldap/slapd.d/cn=config/cn=schema/cn={12}freeradius.ldif I also verified that the attribute that I want to access, dialupAccess is in there with a grep for it on that file. I'm trying to figure out how to make this attribute part of my user profiles so that I can check to see if this is set to 'yes' or 'no' for VPN access. dn: cn={12}freeradius objectClass: olcSchemaConfig cn: {12}freeradius...olcAttributeTypes: {56}( 1.3.6.1.4.1.11344.4.3.1.57 NAME 'dialupAccess' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) .. I can see this is an object class of olcSchemaConfig but how do I add that to my user profiles? THank you! Paul

2 2

MDB indices operations (MIT Kerberos with OpenLDAP backend)
by Дилян Палаузов 22 Sep '19

22 Sep '19

Hello, https://www.openldap.org/software/man.cgi?query=slapd-mdb&apropos=0&sektion… (man slapd-mdb) is not clear about indices. Is olcDbIndex A eq olcDbIndex B eq the same as olcDbIndex A,B eq and is the latter the same as oldDbIndex B,A eq ? In the SQL word these are different things and while Postgresql is supposed to handle "index A,B" and "index B,A" as equivalent, it does not, so a query has to be tuned to make use of existing indices. The particular use-case is the OpenLDAP backend of MIT Kerberos and the indices it needs for this query, as discussed at https://github.com/krb5/krb5/pull/974#issuecomment-531167854. The debug output of OpenLDAP, when there is no objectClass eq index, but a krbPrincipal eq index, is: Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SRCH base="cn=X.NET,cn=krbContainer" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=krbtgt/X.NET(a)X.NET))" Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewable age krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbPrincipalAuthInd krbExtraData krbObjectReferences krbAllowedToDelegateTo krbPwdHistory Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf <= mdb_equality_candidates: (objectClass) not indexed Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SEARCH RESULT tag=101 err=0 nentries=1 text= Does it need one index on objectClass, one index on krbPrincipal, or one index on "first objectClass, then krbPrincipal"? If no mdb_candidate output can be triggered, does it mean, that creating an index is pointless? Moreover, it is not clear when changing the oldDbIndex on a database regenerates the index, and when running slapindex is necessary. My reading of https://www.openldap.org/doc/admin24/tuning.html , Section 21.3.2. “What to watch out for”, is that the output “mdb_equality_candidates” means inefficient searches. But a different interpretation is possible: This equality_candidates may be targeted at the simple case, where the search filter is just one equality test, and where an index could significantly reduce the number of candidates to be loaded and checked. For a krb5 LDAP KDB get_principal operation, the filter expression is (&(|(objectclass=krbprincipalaux)(objectclass=krbprincipal))(krbprincipalname=...)), so the objectClass equality test is intersected with a krbPrincipalName equality test. If the Kerberos LDAP DB is large and isn't shared with a lot of other LDAP data, almost every object in the database will match one of the objectClass equality tests, but only one will match the krbPrincipalName test. In that scenario, an objectClass index is useless, as it doesn't reduce the number of candidates significantly, while the krbPrincipalName index is useful. In fact, it is possible for the objectClass index to slow down the search, relative to having only a krbPrincipalName index--slapd might have to read in a large list of krbprincipal objects, then intersect that with a one-element list of objects matching the krbPrincipalName. While that would be much faster than loading and checking every principal object, it would still be O(n) in space and time rather than O(1). Regards Дилян

3 3

Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount 19 Sep '19

19 Sep '19

--On Thursday, September 19, 2019 10:26 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Thank you, i mean what are the other benefits (like performance) of > using delta replication over full replication other than the ITS#8125 This is covered in the admin guide already: <https://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl%20repl…> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

header tag value
by Gustavo Rios 19 Sep '19

19 Sep '19

Hi folks. i am studying the ldap protocol and i have some doubts. I wonder what is the header tag value for the unbind request message. For the bind request the header value is 0x30. May someone here tell me the value for the unbind request tag header? Thanks in advance. -- Pag Bem Fácil Ltda www.pagbemfacil.com.br

1 0

Consistency issue (probably with me)
by Paul Pathiakis 18 Sep '19

18 Sep '19

Hi all, I just went through all of this previously. I documented everything. I don't believe (yeah... believe) I changed anything. I verified that my firewall rules are correct (although this is all local) I just shutdown slapd with: systemctl stop slapd I did: rm -rf /var/lib/ldap/* /etc/openldap/slapd.d/* Changed my password with slappasswd and put the new one in my slapd.conf . Re-initialized everything with: slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d Got that the configuration passed. Checked slapd.d and /var/lib/ldap. Both had expected values/files. Did: chown -R ldap:ldap /etc/openldap/slapd.d /var/lib/ldap systemctl start slapd Tried to add my memberof.ldif file with: ldapadd -f /etc/openldap/memberof.ldif -v -D "cn=config" -H ldap://newldap.hq.example.com -W -c Got prompted for the password and got an "invalid credentials (49)" (I tried re-doing this multiple times with simple passwords....but same issue...) slapd -d -1 shows me: 5d8267a3 config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context 5d8267a3 backend_startup_one: starting "dc=hq,dc=example,dc=com" 5d8267a3 mdb_db_open: "dc=hq,dc=example,dc=com" 5d8267a3 mdb_db_open: database "dc=hq,dc=example,dc=com": dbenv_open(/var/lib/ldap). 5d8267a3 mdb_monitor_db_open: monitoring disabled; configure monitor database to enable 5d8267a3 slapd starting 5d8267a3 daemon: added 4r listener=(nil) 5d8267a3 daemon: added 7r listener=0x565118e8b500 5d8267a3 daemon: added 8r listener=0x565118e8b330 5d8267a3 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267a3 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267a3 daemon: activity on 1 descriptor 5d8267a3 daemon: activity on: 5d8267a3 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267a3 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 daemon: activity on 1 descriptor 5d8267b8 daemon: activity on: 5d8267b8 slap_listener_activate(7): 5d8267b8 daemon: epoll: listen=7 busy 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 >>> slap_listener(ldap:///) 5d8267b8 daemon: listen=7, new connection on 12 5d8267b8 daemon: added 12r (active) listener=(nil) 5d8267b8 conn=1000 fd=12 ACCEPT from IP=192.168.2.60:39984 (IP=0.0.0.0:389) 5d8267b8 daemon: activity on 2 descriptors 5d8267b8 daemon: activity on: 12r 5d8267b8 daemon: read active on 12 5d8267b8 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 connection_get(12) 5d8267b8 connection_get(12): got connid=1000 5d8267b8 connection_read(12): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: 30 27 02 01 01 60 22 02 0'...`". ldap_read: want=33, got=33 0000: 01 03 04 09 63 6e 3d 63 6f 6e 66 69 67 80 12 62 ....cn=config..b 0010: 6f 73 74 6f 6e 2d 65 6e 67 69 6e 65 65 72 69 6e 0020: 67 g ber_get_next: tag 0x30 len 39 contents: ber_dump: buf=0x7f21bc001e00 ptr=0x7f21bc001e00 end=0x7f21bc001e27 len=39 0000: 02 01 01 60 22 02 01 03 04 09 63 6e 3d 63 6f 6e ...`".....cn=con 0010: 66 69 67 80 12 62 6f 73 74 6f 6e 2d 65 6e 67 69 fig.. 0020: 6e 65 65 72 69 6e 67 neering 5d8267b8 op tag 0x60, time 1568827320 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable 5d8267b8 conn=1000 op=0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x7f21bc001e00 ptr=0x7f21bc001e03 end=0x7f21bc001e27 len=36 0000: 60 22 02 01 03 04 09 63 6e 3d 63 6f 6e 66 69 67 `".....cn=config 0010: 80 12 62 6f 73 74 6f 6e 2d 65 6e 67 69 6e 65 65 . 0020: 72 69 6e 67 ring ber_scanf fmt (m}) ber: ber_dump: buf=0x7f21bc001e00 ptr=0x7f21bc001e13 end=0x7f21bc001e27 len=20 0000: 00 12 62 6f 73 74 6f 6e 2d 65 6e 67 69 6e 65 65 . 0010: 72 69 6e 67 ring 5d8267b8 >>> dnPrettyNormal: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 5d8267b8 <<< dnPrettyNormal: <cn=config>, <cn=config> 5d8267b8 conn=1000 op=0 BIND dn="cn=config" method=128 5d8267b8 do_bind: version=3 dn="cn=config" method=128 5d8267b8 send_ldap_result: conn=1000 op=0 p=3 5d8267b8 send_ldap_result: err=49 matched="" text="" 5d8267b8 send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 14 bytes to sd 12 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1.... ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1.... 5d8267b8 conn=1000 op=0 RESULT tag=97 err=49 text= 5d8267b8 daemon: activity on 1 descriptor 5d8267b8 daemon: activity on: 5d8267b8 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 daemon: activity on 1 descriptor 5d8267b8 daemon: activity on: 12r 5d8267b8 daemon: read active on 12 5d8267b8 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 connection_get(12) 5d8267b8 connection_get(12): got connid=1000 5d8267b8 connection_read(12): checking for input on id=1000 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 02 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0x7f21bc000a80 ptr=0x7f21bc000a80 end=0x7f21bc000a85 len=5 0000: 02 01 02 42 00 ...B. 5d8267b8 op tag 0x42, time 1568827320 ber_get_next ldap_read: want=8, got=0 5d8267b8 ber_get_next on fd 12 failed errno=0 (Success) 5d8267b8 connection_read(12): input error=-2 id=1000, closing. 5d8267b8 connection_closing: readying conn=1000 sd=12 for close 5d8267b8 connection_close: deferring conn=1000 sd=12 5d8267b8 conn=1000 op=1 do_unbind 5d8267b8 conn=1000 op=1 UNBIND 5d8267b8 connection_resched: attempting closing conn=1000 sd=12 5d8267b8 connection_close: conn=1000 sd=12 5d8267b8 daemon: removing 12 5d8267b8 conn=1000 fd=12 closed 5d8267b8 daemon: activity on 1 descriptor 5d8267b8 daemon: activity on: 5d8267b8 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero

2 1

Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount 17 Sep '19

17 Sep '19

--On Monday, September 16, 2019 9:34 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > Any reason you recommend delta replication? It's the only way to mitigate ITS#8125. Running standard syncrepl is just asking for data loss and endless problems. > can you share results of > delta replication over full replication? I'm not sure what you mean. I've been advising delta-syncrepl since OpenLDAP 2.3. > is there any guide/procedure > to change from full to delta replication with out downtime? If you're using cn=config, you can ldapmodify the configuration to enable delta-syncrepl. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

LDAPcon 2019 schedule
by Michael Ströder 16 Sep '19

16 Sep '19

HI! LDAPcon 2019 conference program is now publicly available: https://cfp.ldapcon.org/ldapcon2019/schedule/ Hope to see you all in Sofia in November: https://ldapcon.org/2019/ Ciao, Michael.

2 1

slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
by Norman Gray 13 Sep '19

13 Sep '19

Greetings. I'm having difficulty creating a non-trivial olcUniqueURI spec. Can anyone advise me? The problems are: * A plausible-looking spec in olcUniqueURI causes slapadd to spin its wheels indefinitely. * The manpage doesn't make it terribly clear what I should expect from a plausible-looking spec. Details follow: I want to specify something like dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub The idea is that the uidnumber attribute should be unique across the two OUs, ou=dept-A and ou=dept-B. If I do this, however, then slapadd spins its wheels: $ rm -R /usr/local/etc/openldap/slapd.d/* $ su -m ldap -c "slapadd -d255 -n 0 -F /usr/local/etc/openldap/slapd.d -l /usr/local/etc/openldap/slapd.ldif" ... ... 5d77d377 >>> dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <<< dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config>, <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <= str2entry(olcOverlay=unique,olcDatabase={1}mdb,cn=config) -> 0x800d4eca8 5d77d377 oc_check_required entry (olcOverlay=unique,olcDatabase={1}mdb,cn=config), objectClass "olcUniqueConfig" 5d77d377 oc_check_allowed type "objectClass" 5d77d377 oc_check_allowed type "olcOverlay" 5d77d377 oc_check_allowed type "olcUniqueURI" 5d77d377 oc_check_allowed type "structuralObjectClass" 5d77d377 >>> dnNormalize: <olcOverlay={1}unique> 5d77d377 <<< dnNormalize: <olcOverlay={1}unique> 5d77d377 ==> unique_db_init 5d77d377 ==> unique_new_domain <ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub> 5d77d377 >>> dnPrettyNormal: <ou=dept-A,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-A,o=example>, <ou=dept-A,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> ... ^C and so on and on and on, apparently indefinitely. slapo-unique(5) says that the syntax here is: unique_uri <[strict ][ignore ]URI[URI...]...> Configure the base, attributes, scope, and filter for uniqueness checking. Multiple URIs may be specified within a domain, allowing complex selections of objects. Multiple unique_uri statements or olcUniqueURI attributes will create independent domains, each with their own independent lists of URIs and ignore/strict settings. Keywords strict and ignore have to be enclosed in quotes (") together with the URI. The LDAP URI syntax is a subset of RFC-4516, and takes the form: ldap:///[base dn]?[attributes...]?scope[?filter] (I'm taking it that there should be a space between those `URI[URI...]`) in servers/slapd/overlays/unique.c, the comment above `unique_new_domain` says instead * domain_specs look like * * [strict ][ignore ]uri[[ uri]...] * e.g. "ldap:///ou=foo,o=bar?uid?sub ldap:///ou=baz,o=bar?uid?sub" * "strict ldap:///ou=accounts,o=bar?uid,uidNumber?one" * etc * So that's clearly permitting multiple URIs -- perhaps the quotes are required (as the manpage hints). But if I try olcUniqueURI: "ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub" ...then I get 5d77d617 ==> unique_new_domain <"ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub"> 5d77d617 olcUniqueURI: value #0: <"ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub"> invalid ldap urilist from slapadd (so that's not the problem). But the example there does look VERY much like what I tried. So: * I'm pretty sure I shouldn't be able to make slapadd spin its wheels like that. * The manpage text might be a little too telegraphic. While I'm sure it's not _wrong_, it is quite hard to go from that text to a working spec with any confidence. Googling olcUniqueURI produces very little of use. Is this not the correct way to do this? This looks somewhat similar, in symptoms and module, to ITS#8162, but it does seem distinct. Thanks for any pointers. Best wishes, Norman -- Norman Gray : https://nxg.me.uk

3 4

Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount 12 Sep '19

12 Sep '19

--On Thursday, September 12, 2019 12:23 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Thanks for quick response, i will consider your recommendations but i > wanted to understand when does consumer go to REFRESH mode? When it detects an inconsitency or error of some type. > 5d7a6178 send_ldap_result: err=66 matched="" text="subordinate objects > must be deleted first" > 5d7a6178 syncrepl_del_nonpresent: rid=001 be_delete dc=example,dc=com (66) > 5d7a6178 => bdb_entry_get: ndn: "dc=example,dc=com" And here is the error. It would appear it's getting the deletes out of sequence as it was requested to delete a parent before a child. I'd also note that back-bdb/hdb are deprecated. I will re-iterate that you need to update to a current release. Anything else is just a waste of time. Please see the change log: <https://www.openldap.org/software/release/changes.html> I'd also heavily advise using back-mdb with the current release and using delta-syncrepl. I would also note that some overlays have undefined behavior in an MMR environment (such as ppolicy as documented in the slapo-ppolicy(5) man page). YMMV with such overlays in use. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

[Q] ModRDN object via Net::LDAP::Control::SyncRequest
by Zeus Panchenko 12 Sep '19

12 Sep '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, please advise, how can I catch ModRDN object in syncrepl cosumer? I use perl Net::LDAP on ldapmodrdn I successfully catch LDAP_SYNC_MODIFY event with Net::LDAP::Entry object, DN of which contains *new* rdn ... but how to know/get the old one? accesslog DB doesn't contain reqDN for new rdn yet ... I'm using the example code from Net::LDAP::Control::SyncRequest - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCXXqZHwAKCRCveOk+D/ej KsoLAKCiqf/sGKpYLy0xUybyLCXtkTTVkQCcCfTAoMcwhC+JWHcxvHzeLrppc5w= =cVqP -----END PGP SIGNATURE-----

1 0

Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount 12 Sep '19

12 Sep '19

--On Thursday, September 12, 2019 10:57 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Any help? > > > On Tue, Sep 10, 2019 at 9:39 AM rammohan ganapavarapu > <rammohanganap(a)gmail.com> wrote: > > > Hi, > > > I have 2 nodes MMR setup with openldap 2.4.44-21 version, i see these > messages in the one of the two server logs, and looks like on consumer > side some of the entries are getting deleted. Sounds like it went into REFRESH. I'd strongly advise: a) Updating to the latest OpenLDAP release (there have been numerous MMR related fixes in the 3.5 years since 2.4.44 was released) and b) Using delta-syncrepl Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Openldap 2.4.x log details for error 49
by François Pernet 11 Sep '19

11 Sep '19

Hi all, We have a solution running on which openldap is the identity repository. OpenLDAP 2.4 is installed (on CentOS) also with policy. The system is able to send traps when authentication problem occurs, based on the slapd generated logs. Unfortunatly the log contains such error: "Jun 5 11:27:16 vms slapd[32101]: conn=1174 op=0 RESULT tag=97 err=49 text=" when the password entered generates an "invalid crendentials" message. This is fine, but the error could mean the following: * Wrong user or password * Expired account * Account locked or disabled * User must change its password Question is : is it possible to find a way to have the details for error 49 ? (this error message is far too generic) Many thanks in advance FPernet

2 1

Is there a simple document that explains the various admin passwords?
by Paul Pathiakis 11 Sep '19

11 Sep '19

Hi, I am trying to figure out all the various passwords and access controls. I seem unable to get my previously documented systems/configurations to work. I understand that slaptest is supposed to convert my slapd.conf to a new configuration and everything should be fine going forward. However, I'm having various password and access issues. Basically, I use my ldap.conf file and everything seems good. I start slapd and it works fine. I perform an ldap search and everything seems fine as it returns my domain. After that, I try to import my memberof.ldif file and it gives me an access issue. ldapadd -f /etc/openldap/memberof.ldif -v -D "cn=config" -H ldap://192.168.2.113 -W -c dn: cn=module,cn=config cn: module objectClass: olcModuleList objectclass: top olcModuleLoad: memberof.la olcModulePath: /usr/lib64/openldap dn: olcOverlay=memberof,olcDatabase={0}config,cn=config objectclass: olcconfig objectclass: olcMemberOf objectclass: olcoverlayconfig objectclass: top olcoverlay: memberof ldap_initialize( ldap://192.168.2.113:389/??base ) Enter LDAP Password: ldap_bind: Invalid credentials (49) Obviously, that's a password problem. My question is why? What step did I miss in my documentation? Thank you! P.

3 8

slapd and LetsEncrypt certificates: does a cert renewal necessitate a server restart?
by Jean-Francois Malouin 10 Sep '19

10 Sep '19

Hi, As the subject say, I'm contemplating the use of LetsEncrypt TLS certificates. Is there a way to make slapd aware of a cert renewal (they happen every 90 days) without restarting it, ie, with minimal service interruption? thanks, jf

6 6

Re: search request not blocked by ACLs
by Manuela Mandache 10 Sep '19

10 Sep '19

Le lun. 9 sept. 2019 à 18:25, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > > > --On Thursday, September 5, 2019 10:35 AM +0200 Manuela Mandache > <manuela3mandache(a)gmail.com> wrote: > > > > > > > > > > > > > > > Le mer. 4 sept. 2019 à 16:00, Quanah Gibson-Mount <quanah(a)symas.com> a > > écrit : > > > > --On Wednesday, September 4, 2019 1:56 PM +0200 Manuela Mandache > > <manuela3mandache(a)gmail.com> wrote: > > > >> olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by > >> dn.base="cn=adm > >> in,dc=example,dc=com" manage by * break > >> olcAccess: {1}to dn.base="" by * read > >> olcAccess: {2}to dn.base=cn=Subschema by * read > >> olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=userPassword by * > >> auth > >> olcAccess: {4}to dn.subtree="dc=example,dc=com" attrs=entry by * read > >> olcAccess: {5}to dn.subtree="dc=example,dc=com" attrs=cn,mail by * read > >> olcAccess: {6}to * by anonymous none by * read > > > > On what cn=config entry have you set these ACLs? > > > > > > > > > > They're on > > olcDatabase={2}mdb,cn=config > > This is the DB containing the actual data of the directory, with > > olcSuffix: dc=example,dc=com > > Given that, I would make the following notes: > > a) rootDNs are never subject to ACLs, so the access for cn=admin,cn=config > manage in {0} is suspect, as I would infer that is a rootdn. > > b) ACL {1} is invalid for this database. It should be set in the dn: > olcDatabase={-1}frontend,cn=config database > > c) ACL {2} is invalid for this database. See solution listed in (b) > > d) ACL {3} should only give auth access to anonymous, not * > > e) ACLs 3-5 should be rewritten to drop the dn.subtree="dc=example,dc=com" > bit entirely. You're already only setting ACLs for that database, no need > to list that restriction. You can also combine ACLs 4 & 5. > > olcAccess: {3} to attrs=userPassword by anonymous auth > olcAccess: {4} to attrs=entry,cn,mail by * read > olcAccess: {5} to * by anonymous none by * read > > Hello Quanah, Thank you for the detailed analysis of the ACLs - I wrote them based on very old inherited ones, but this is no excuse. Although I (believed I had) thoroughly RTFM, I feel like I only begin to really understand the way they must be defined. Well, back to the drawing board. Do poorly written ACLs have a strong impact on performance? > As for your question in general, I don't think you understand how ACLs > work > in relation to incoming search requests. The server did exactly what your > ACLs said it should do: It provided no information when someone tried to > search for data using an attribute that access is not granted to, and > correctly returned 0 entries. It sounds as though you expected the > connection to be dropped when the search was initiated because it was > filtering off of sn. No, I didn't think the connection would be dropped, but I thought no data which are never to be returned would be searched. E.g.: - there are three branches in the directory, ou=people,dc=example,dc=com, ou=dogs,dc=... and ou=carpets,...; - a user has read rights on ou=dogs and none on the two other branches; - this user makes a search with -b dc=example,dc=com and no filter. As far as I understand, the whole content is recovered, then the people and the carpets are dropped and only the dogs are returned. I expected the request to be parsed against the ACLs before performing the actual search in the directory, and so this search to be done only on ou=dogs. Maybe this example is completely different from the one in my first post: It's true that I do not know how requests-and-ACLs actually work. Is there some documentation I could read on the topic? Best regards, Manuela > That is now how things work. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

ldap_add: Insufficient Access (50)
by Paul Pathiakis 09 Sep '19

09 Sep '19

Hi all, I'm trying to restore/move a database from one machine to another and start making sure that my client uses all the correct .ldif files. Now, I've always done a slapcat to an ldif file and used sed in place to modify/remove all the extraneous entries from the dump so I can reload. Strangely, this doesn't look like it's working this time around. I get the "Insufficient access (50) additional info: no write access to parent" Seems obvious that I don't have some type of access at the beginning of the load near the base of the tree. (After I get this, I'm inundated with ldap_add: No such object (32) since it wasn't able to write things into a non-existent structure further down) I see a potential problem in that the tree was originally defined as dc=example,dc=com and, now, everything lives in: dc=hq,dc=example,dc=com . Is that the problem? If so, what's the easiest way around it? Ldap.conf has: BASE dc=example,dc=com Slapd.conf has: access to attrs=userPassword by self write by anonymous auth by dn="uid=syncuser,dc=hq,dc=example,dc=com" read by * compare access to attrs=sambaLMPassword,sambaNTPassword by dn="uid=syncuser,dc=hq,dc=example,dc=com" read by * none access to * by self write by * read access to dn.subtree="dc=hq,dc=example,dc=com" by self write by set="[cn=itlevel1,ou=Groups,dc=hq,dc=example,dc=com]/member* & user" write by set="[cn=ntadmins,ou=Groups,dc=hq,dc=example,dc=com]/member* & user" write by * break authz-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=root,dc=hq,dc=example,dc=com" database mdb suffix "dc=hq,dc=example,dc=com"rootdn "cn=root,dc=hq,dc=example,dc=com" Thank you all! P.

1 0

Re: search request not blocked by ACLs
by Manuela Mandache 09 Sep '19

09 Sep '19

Le mer. 4 sept. 2019 à 16:00, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > --On Wednesday, September 4, 2019 1:56 PM +0200 Manuela Mandache > <manuela3mandache(a)gmail.com> wrote: > > > olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by > > dn.base="cn=adm > > in,dc=example,dc=com" manage by * break > > olcAccess: {1}to dn.base="" by * read > > olcAccess: {2}to dn.base=cn=Subschema by * read > > olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=userPassword by * > > auth > > olcAccess: {4}to dn.subtree="dc=example,dc=com" attrs=entry by * read > > olcAccess: {5}to dn.subtree="dc=example,dc=com" attrs=cn,mail by * read > > olcAccess: {6}to * by anonymous none by * read > > On what cn=config entry have you set these ACLs? > They're on olcDatabase={2}mdb,cn=config This is the DB containing the actual data of the directory, with olcSuffix: dc=example,dc=com Regards, Manuela > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Why is dc=my-domain,dc=com in my namingContext?
by Paul Pathiakis 09 Sep '19

09 Sep '19

Hi, Something is amiss and I decided to rebuild from the start. # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_CACERTDIR /etc/openldap/cacerts # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on #TLS_CACERT /etc/openldap/cacert.pem #TLSCACertificateFile /etc/openldap/cacert.pem #TLSCertificateFile /etc/openldap/server.crt #TLSCertificateKeyFile /etc/openldap/private.key ssl start_tls TLS_REQCERT allow BASE dc=joescompany,dc=com URI ldap://127.0.0.1/ I start the ldap server and go to see if everything is ok. ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContexts # # dn: namingContexts: dc=joescompany,dc=com namingContexts: dc=my-domain,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Should that second line even be there? Where in the world is it getting my-domain from? Is it a default? Thank you, P.

2 2

slapo-memberof(5) confusing documentation
by Norman Gray 09 Sep '19

09 Sep '19

Greetings. The slapo-memberof(5) manpage mentions limitations on when it can be used, in the context of replication. The current text is very confusing, and possibly not self-consistent. This message might be more appropriate as an ITS PR, but I'm sending it here first, partly in case I've got the wrong end of the stick, and partly as google-bait for the benefit of anyone as puzzled as I was. The text currently says: > The memberof overlay may be used with any backend that provides full > read-write functionality, but it is mainly intended for use with local > storage backends. The maintenance operations it performs are internal > to the server on which the overlay is configured and are never > replicated. Replica servers should be configured with their own > instances of the memberOf overlay if it is desired to maintain these > memberOf attributes on the replicas. Fine -- that seems to me to say very clearly that the memberof attribute is OK to use across replicas, as long as each replica has its own memberof overlay. However, immediately after that, the text says: > Note that slapo-memberOf is not compatible with syncrepl based > replication, and should not be used in a replicated environment. An > alternative is to use slapo-dynlist to emulate slapo-memberOf > behavior. This seems to flatly contradict (my understanding of) the first part of the paragraph. So which is it? A 2009 list thread [1] seems to suggest that you can sort of get away with it, but only just. However another list thread (2015) [2] describes an apparently successful setup using simple syncrepl, with memberof in the provider and consumer, and where the memberof attribute is automatically excluded from the replication (there’s explicit advice not to exclude it using exattrs=memberof in the syncrepl setup). The latter posting refers to ITS issue 7400 [3], ‘Memberof and Syncrepl incompatibility’, which last had activity in 2012, but which still appears to be open. The latter issue notes in passing that ‘memberof must be configured on each replica’, which implies that this is a feasible setup. **However**: closed ITS 8613 (2017) [4] says baldly that > The slapo-memberOf overlay is not safe to use in a replicated > environment due to the way in which replication occurs. It also explains why, and gives a (compressed but complete) suggestion of how one might use the dynlist overlay to do something similar. A 2018 list message [5] says in passing > Unfortunately, there is no defined standard for the “memberOf” > functionality (it’s a MS hack) and so there’s nothing that details > how it should or shouldn’t behave with replication. Going with the most recent statement, therefore, it seems that this it's simply not possible to use memberOf in a replicated environment, unless (rather precariously, I'd have thought) you completely avoid 'refresh' mode in replication, as mentioned in [4]. I suggest adjusting the text in the slapo-memberof manpage. If the third sentence (‘Replica servers should...’) were simply removed, that would remove most of the contradiction. In the following sentence (‘Note that...’), the sentence first seems to suggest that it's only syncrepl replication that the overlay is incompatible with (ie, that there are other replication mechanisms which will work), but it goes on to state that it's incompatible with _all_ replication methods. Which is it? Finally, given the aside in [5], it might be worth indicating in the manpage that memberOf should only be used when other considerations force it, and should (by the sound of it) be avoided otherwise. Have I misunderstood something? Best wishes, Norman [1] https://www.openldap.org/lists/openldap-software/200910/msg00037.html [2] https://www.openldap.org/lists/openldap-technical/201505/msg00127.html [3] https://www.openldap.org/its/index.cgi/Software%20Bugs?id=7400;selectid=7400 [4] http://www.openldap.org/its/index.cgi/?findid=8613 [5] https://www.openldap.org/lists/openldap-technical/201809/msg00099.html -- Norman Gray : https://nxg.me.uk

2 2

slapd-sock as overlay
by Shiva Prasad Thagadur Prakash 09 Sep '19

09 Sep '19

Hello Guys, Could you please tell me where I could find a guide to configure slapd-sock as overlay for an existing database? I am not using slapd.conf but olc. I tried the configuring but I am getting "error 80, implementation error, could not open socket". Below is the configuration: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=ericsec,dc=com olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=ericsec,dc=com olcRootPW: {SSHA}lxpvQanVD5GoVXKiDB1HNEInKYussacd .. dn: olcOverlay={0}sock,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcOvSocketConfig olcOverlay: {0}sock olcDbSocketPath: /tmp/sockoverlay-listener1 olcDbSocketExtensions: binddn peername ssf olcOvSocketOps: bind unbind search Eagerly waiting for the reply. Thanks, Shiva

2 3

search request not blocked by ACLs
by Manuela Mandache 04 Sep '19

04 Sep '19

Hello all, My previous email address doesn't seem able to communicate with the list anymore... I sent this question yesterday and I don't find it in the September list of submitted subjects - sorry if I got it wrong and I'm double-posting. On an OpenLDAP directory, the ACLs are olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by dn.base="cn=adm in,dc=example,dc=com" manage by * break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.base=cn=Subschema by * read olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=userPassword by * auth olcAccess: {4}to dn.subtree="dc=example,dc=com" attrs=entry by * read olcAccess: {5}to dn.subtree="dc=example,dc=com" attrs=cn,mail by * read olcAccess: {6}to * by anonymous none by * read For the requests, the behavior is the expected one from user's point of view : $ ldapsearch -LLL -x -H ldap://myServer:390 -b ou=people,dc=example,dc=com 'cn=Name*' dn: uid=someuid,ou=people,dc=example,dc=com mail: FirstName.Name(a)domain.com cn: Name FirstName $ ldapsearch -LLL -x -H ldap://myServer:390 -b ou=people,dc=example,dc=com 'sn=Name' Checking the log, the first requests appears as 2019-09-03T14:22:17.537815+02:00 myServer slapd[4765]: conn=1141654 fd=13 ACCEPT from IP=xxx.xxx.xxx.xxx:55188 (IP=0.0.0.0:390) 2019-09-03T14:22:17.538004+02:00 myServer slapd[4765]: conn=1141654 op=0 BIND dn="" method=128 2019-09-03T14:22:17.538044+02:00 myServer slapd[4765]: conn=1141654 op=0 RESULT tag=97 err=0 text= 2019-09-03T14:22:17.546713+02:00 myServer slapd[4765]: conn=1141654 op=1 SRCH base="ou=people,dc=example,dc=com" scope=2 deref=0 filter="(cn=Name*)" 2019-09-03T14:22:17.550421+02:00 myServer slapd[4765]: conn=1141654 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= 2019-09-03T14:22:17.562783+02:00 myServer slapd[4765]: conn=1141654 op=2 UNBIND 2019-09-03T14:22:17.562835+02:00 myServer slapd[4765]: conn=1141654 fd=13 closed which is once again the expected behavior. But the second request generates in the log 2019-09-03T14:22:04.293120+02:00 myServer slapd[4765]: conn=1141645 fd=13 ACCEPT from IP=xxx.xxx.xxx.xxx:55186 (IP=0.0.0.0:390) 2019-09-03T14:22:04.293262+02:00 myServer slapd[4765]: conn=1141645 op=0 BIND dn="" method=128 2019-09-03T14:22:04.293328+02:00 myServer slapd[4765]: conn=1141645 op=0 RESULT tag=97 err=0 text= 2019-09-03T14:22:04.302404+02:00 myServer slapd[4765]: conn=1141645 op=1 SRCH base="ou=people,dc=example,dc=com" scope=2 deref=0 filter="(sn=Name)" 2019-09-03T14:22:04.304850+02:00 myServer slapd[4765]: <= mdb_equality_candidates: (sn) not indexed 2019-09-03T14:22:04.334020+02:00 myServer slapd[4765]: conn=1141645 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= 2019-09-03T14:22:04.342618+02:00 myServer slapd[4765]: conn=1141645 op=2 UNBIND It actually looks as if the search was performed first, and the ACLs were checked only afterwards to prevent any return. As sn is not supposed to be used in the filter, it is not indexed (but we have no control over the requests sent to the directory to prevent the use of unauthorized filters). Am I misreading the log? And if I'm not, is there some parameter to be set to block the actual search on unauthorized filters? Thank you, and please let me know if I need to supply more configuration information. Regards, Manuela

2 1

Dynamic ACL in OpenLDAP with set:expand not working
by Martin W. 27 Aug '19

27 Aug '19

Dear OpenLDAP technical list, I‘ve been running into a little problem with my permission structures – and was wondering if you could help me with it. I want the members of a group to administer a tree structure, the group is member of it. I've tried some acl settings – I'll post my trials below the basic structure. Basic structure The structure is somehow like that tree – behind an # symbol, there is a brief description what the entries are meant for. > dc=example,dc=com > │ > ├── cn=admin # OpenLDAP default admin user > │ > ├── ou=entities # organisational entities > │ │ > │ ├── o=e1 # first of these entities > │ │ │ > │ │ ├── cn=admin # groupOfNames – see bullet points below > │ │ │ ┆ > │ │ │ └ ┄▸ member: cn=admin,dc=example,dc=com > │ │ │ └ ┄▸ member: uid=j.doe,ou=people,dc=example,dc=com > │ │ │ > │ │ ├── cn=role1 # groupOfNames to be reused below > │ │ │ ┆ as recursive group members within > │ │ │ ┆ permission groups > │ │ │ ┆ > │ │ │ └ ┄▸ member: cn=admin,o=e1,ou=entities,dc=example,dc=com > │ │ │ > │ │ └── cn=role2 > │ │ ┆ > │ │ └ ┄▸ member: cn=admin,o=e1,ou=entities,dc=example,dc=com > │ │ > │ └── o=e2 > │ ├── cn=admin > │ ├── cn=role1 > │ └── cn=role2 > │ > ├── ou=groups # permission groups for applications > │ │ that authenticate against OpenLDAP > │ │ > │ ├── cn=globaladmins # groupOfNames – superusers in all applications > │ │ ┆ > │ │ └ ┄▸ member: cn=admin,dc=example,dc=com > │ │ > │ ├── cn=ldapadmins # groupOfNames – same rights as admin user > │ │ ┆ > │ │ └ ┄▸ member: cn=globaladmins,ou=groups,dc=example,dc=com > │ │ └ ┄▸ member: uid=l.dap,ou=people,dc=example,dc=com > │ │ > │ ├── cn=permissiongroup1 # groupOfNames – authentication group > │ │ ┆ for specific application > │ │ ┆ > │ │ └ ┄▸ member: cn=globaladmins,ou=groups,dc=example,dc=com > │ │ └ ┄▸ member: cn=role1,o=e1,ou=entities,dc=example,dc=com > │ │ └ ┄▸ member: cn=role1,o=e2,ou=entities,dc=example,dc=com > │ │ > │ └── cn=permissiongroup2 > │ ┆ > │ └ ┄▸ member: cn=globaladmins,ou=groups,dc=example,dc=com > │ └ ┄▸ member: cn=role2,o=e1,ou=entities,dc=example,dc=com > │ └ ┄▸ member: cn=role2,o=e2,ou=entities,dc=example,dc=com > │ > └── ou=people # finally the "real people" accounts > │ > ├── uid=j.doe > ├── uid=l.dap > └── uid=m.muster cn=admin,dc=example,dc=com is basic member of the admin groups (since every group needs at least one member). uid=l.dap,ou=people,dc=example,dc=com is member of the cn=ldapadmins,ou=groups,dc=example,dc=com group. Therefor every member should have same rights within LDAP structure as cn=admin,dc=example,dc=com ou=people is the only structure, (personal) accounts are maintained ou=groups is the only structure, authentication groups for (web)applications are maintained (with nested members) The cn=admin,o=e1,ou=entities,dc=example,dc=com DN members should be able to admin everything below o=e1,ou=entities,dc=example,dc=com. e1 should be dynamic. The entity admins should not be able to administer other entities than the ones, they are admins from. Permission LDIF I've tried some different things ... and none Regex was successful :( Since I'll post some fragments, I put every LDIF fragment within such a bash fragment: > touch /permissions.ldif > > cat >/permissions.ldif <<EOF > # first of all delete all permissions > dn: olcDatabase={1}mdb,cn=config > changetype: modify > delete: olcAccess > - > > ######## > ## LDIF blocks from below > ######## > > - > # add general permissions > add: olcAccess > olcAccess: to * > by self write > by dn="cn=admin,dc=example,dc=com" write > by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & user" write > by users read > by * none > EOF > > ldapmodify -Q -Y EXTERNAL -H ldapi:/// <ldapi:///> -f /permissions.ldif trial 1 > # add administrative access to LVe admin subgroups > add: olcAccess > olcAccess: to dn.regex="([^,]+,)?o=([^,]+),ou=entities,dc=example,dc=com" > by self write > by dn="cn=admin,dc=example,dc=com" write > by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & user" write > by set.expand="[cn=admin,o=$2,ou=entities,dc=example,dc=com]/member* & user" write > by set="this/member* & user" read > by * none The result is, that admin and any member of ldapadminscan edit, the members of specific entity admin subgroups cannot edit. The specific admin subgroups cannot even see the entities subtree. trial 2 > # add administrative access to LVe admin subgroups > add: olcAccess > olcAccess: to dn.regex="o=([^,]+),ou=entities,dc=example,dc=com" > by self write > by dn="cn=admin,dc=example,dc=com" write > by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & user" write > by set.expand="[cn=admin,o=$1,ou=entities,dc=example,dc=com]/member* & user" write > by set="this/member* & user" read > by * none The same result as with trial 1 ... trial 3 Additional groups – as a tree: > dc=example,dc=com > ┆ > └── ou=entity_admins > │ > ├── cn=e1 > │ ┆ > │ └ ┄▸ member: cn=admin,o=e1,ou=entities,dc=example,dc=com > │ > └── cn=e2 And the LDIF: > # add administrative access to LVe admin subgroups > add: olcAccess > olcAccess: to dn.regex="o=([^,]+),ou=entities,dc=example,dc=com" > by self write > by dn="cn=admin,dc=example,dc=com" write > by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & user" write > by set.expand="[cn=$1,ou=entity_admins,dc=example,dc=com]/member* & user" write > by set="this/member* & user" read > by * none The result is again: admin and any member of ldapadminscan edit, entity_admins subgroups user cannot edit – even not their "owned" entities. trial 4 If I put an by set="[cn=admin,o=e1,ou=entities,dc=example,dc=com]/member* & user" write for EVERY single olcAccess: to dn.regex="([^,]+,)?o=jpbay,ou=entities,dc=example,dc=com" (with all the other stuff from trial 1), everything works fine. BUT: that's not maintainable or dynamic. So that's no solution, I can accept. I do not know why set.expand doesn't work as expected (as explained within different online examples on openldap.com <http://openldap.com/>) – and was not able to find a proper documentation that could explain why. Or if there has to be some enablement of an OpenLDAP module? If you could support me with that problem – probably with a solution – it would be great =) Thanks a lot, Martin

3 4

Procedure going from search query to an acl
by Marc Roos 27 Aug '19

27 Aug '19

I have client that coredumps with these acl's. When I remove them, the client is getting data from the ldap server and I can see the queries it is doing on the server. I thougt the lines below would give access to ou=Services and below by test, but I guess not. dn: olcDatabase={-1}frontend,cn=config olcAccess: {0} to dn.exact="" by * read olcAccess: {1} to dn.exact="cn=Subschema" by * read olcAccess: {2} to attrs=userPassword,shadowLastChange by ssf=256 self read by ssf=256 anonymous auth by * none olcAccess: {3} to dn.exact="ou=Services,dc=example,dc=local" attrs="children" by dn.exact="cn=test,ou=Hosts,dc=example,dc=local" ssf=64 read by * break olcAccess: {4} to dn.children="ou=Services,dc=example,dc=local" by dn.exact="cn=test,ou=Hosts,dc=example,dc=local" ssf=64 read olcAccess: {5} to * by * none acl_mask: access to entry "name=asdf,ou=Services,dc=example,dc=local", attr "bla" requested acl_mask: access to entry "ou=Services,dc=example,dc=local", attr "entry" requested I guess I should grep the log for the acl_mask entries not? What would be an adviced procedure to do this? I also do not want to get a huge list of acls for just one client type. Everything below "ou=Services,dc=example,dc=local" is test to read. (No password attributes stored there)

2 1

Q: Multiple accesslog overlays?
by Ulrich Windl 27 Aug '19

27 Aug '19

Hi! I have a question preparing a transition of syncrepl to delta-syncrepl: Our database already has an accesslog overlay (olcAccessLogOps: writes) and a corresponding database configured for monitoring purposes. Now that delta syncreply also requires an accesslog overlay/database with somewhat different setting compared to the existing database, I wonder whether it's possible (and practically being used/proven to work) to have multiple accesslog overlays. Thinking about it, I also wonder whether both needs for accesslog could be satisfied with one accesslog database, just using different LDAP filters. I guess the delta syncreply is using the acesslog database in a read-only manner (our monitoring also does), so it might actually work. Anybody went that way before? Finally a question on the requirement to backup the acesslog database in addition to the corresponding database (18.2.1: "Note: since the database state is stored in both the changelog DB and the main DB on the provider, it is important to backup/restore both the changelog DB and the main DB using slapcat/slapadd when restoring a DB or copying it to another machine."): Is it actually a hard requirement needed for consistency, or will it just improve the performance (avoiding a full refresh)? Also: Isn't it tricky to backup both databases consistently while the database is writable? Regards, Ulrich

3 10

Adding syncprov to running slapd
by Marc Roos 27 Aug '19

27 Aug '19

I am adding the syncprovider to a running server with these: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpCheckpoint: 100 10 olcSpSessionlog: 100 However when I do slapd -VVV the overlay is not listed. Do I need to 1. restart? 2. use syncprov.la instead of syncprov?

3 2

Socat tcp to local socket
by Marc Roos 27 Aug '19

27 Aug '19

Anyone having some experience using socat (or something similar?) to connect to a remote slapd server tcp/tls with a local socket? I have a client that requires the local ldapi socket. But I do not want to install there an instance of slapd.

1 2

RE: Socat tcp to local socket
by Marc Roos 26 Aug '19

26 Aug '19

Hi Harry, I just did a build from srpm, and currently I trying to get the scenario of a pipe between sockets working. Just to make sure this pipe is working correctly before I am moving to the tcp/tls connection. Of course my problem persists with socat using something like this. socat -s -d -d -d -t 3 UNIX-CONNECT:/var/run/ldapi,raw,ignoreeof UNIX-LISTEN:/var/run/bla,raw,ignoreeof,fork You have a suggestion how to to do this with dpipe, I have tried this dpipe vde_plug /var/run/ldapi = vde_plug /var/run/bla But it does not launch nor reports the error. -----Original Message----- Subject: Re: Socat tcp to local socket > > With this I am able to issue just one ldap search on the socket. > Subsequent queries fail with 'ldap_sasl_bind(SIMPLE): Can't contact > LDAP server (-1)' Sure, use either very long timeouts or use an other tool, i.e. dpipe. The problem with socat is, socat terminates after each ldapsearch. dpipe only stops, if manual terminated. Their are some other useful tools in vde2 package. > > socat -d -d > OPENSSL:192.168.10.18:8443,cafile=/etc/openldap/cacerts/ca.crt,verify= > 0, > keepalive,reuseaddr,ignoreeof > UNIX-LISTEN:/var/run/ldapi,reuseaddr,type=1,ignoreeof > > I am just wondering if this is even possible, maybe the tcp > connections keeps an authorized session? Or ldapi communication is just different? > If this ldapi communication is different from ldaps. I guess I am only > left with the options like > - connecting with some forwarded ssh session to the local ldapi server > socket > - maybe export ldapi with stunnel on the server, and capture it again > with stunnel/socat > - look into slapd proxy/meta > > > > > > > > > -- Harry Jede

1 0

Complex setup to do back-ldap AND SASL auth in one go
by Markus.Storm＠t-systems.com 26 Aug '19

26 Aug '19

Dear all, I am desperately trying to setup an OpenLDAP instance "P" with a proxy or other backend or even chain of proxies to do the following and I just don't manage to wrap my head around it. I'd be thankful if someone could give me a helping hand and provide me with the missing link. Apologies upfront for the lengthy mail and complicated setup, but for organizational reasons, I have a couple of constraints that I cannot change. Scenario: Ultimately I want some UNIX machines using pam-ldap to authenticate against an Active Directory ("AD"). Logins to those machines require a number of attributes but I don't have authority/ability to store them in the AD. They are stored in an external (non-OpenLDAP !) server "S" instead. As the AD passwords cannot be read/replicated, I also cannot simply direct clients to S, so I want to direct them to an OpenLDAP instance "P" to "split" the request, i.e. do authentication against AD using external auth/SASL (that part already works) while retrieving the attributes from S. I have this working to some extent but needed to create a copy of the user data on S in my openLDAP server/proxy P. But I'm trying to avoid the need to have those copies in P, I want it to be dataless to avoid all need for synchronization (as S is non-OpenLDAP I cannot simply replicate). I'm open to suggestions but I think it would need to work like this: 1. Client "C" connects to P with say binddn cn=user,dc=domain and password pw 2. P proxies all requests for dc=domain to S using a generic binddn (instead of the user credentials) to have access to the subtree the users are in As of today I wouldn't know how to configure that binddn on P. 1. S has an entry for every user with userpassword={SASL}user@domain and a couple of attributes which all are returned to P S is the only place where we can store those attributes (and the instruction to use SASL - or is there another place for that ?) But authentication of C against S fails when I use the user's credentials (because of the "{SASL}..." contents on S). Obviously S is unable to interpret/execute SASL auth format (if it was able that would be an obvious solution to my problem). I also believe I cannot have ANOTHER userPassword attribute on S to have the user's password pw (S wouldn't know which of those 2 userPassword attributes to authenticate against). 1. P does SASL auth as user@domain and initially provided password against an Active Directory ("AD") The SASL part already works but only if I setup another DB in P to contain a copy of the user data tree on S and userPassword="{SASL}user@domain" for all users. Thanks in advance to anyone willing to wrap his head around my problem. Best regards Markus

2 2

Re: Socat tcp to local socket
by Giuseppe De Marco 25 Aug '19

25 Aug '19

Hi Marc, Slapd-proxy or slapd-meta could be the solution Il dom 25 ago 2019, 14:42 Marc Roos <M.Roos(a)f1-outsourcing.eu> ha scritto: > > Anyone having some experience using socat (or something similar?) to > connect to a remote slapd server tcp/tls with a local socket? I have a > client that requires the local ldapi socket. But I do not want to > install there an instance of slapd. > > > > > > >

1 0

openldap replication
by sami's strat 22 Aug '19

22 Aug '19

I'm trying to configure replication between two hosts using the following as a guideline: https://www.server-world.info/en/note?os=CentOS_7&p=openldap&f=5 Here are some notes I have based on the setup I've done: ##### REPLICATION ON Master ##### [root@ldap01 ~]# more mod_syncprov.ldif dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /usr/lib64/openldap olcModuleLoad: syncprov.la [root@ldap01 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f mod_syncprov.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config" [root@ldap01 ~]# more syncprov.ldif dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpSessionLog: 100 [root@ldap01 ~]# [root@ldap01 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f syncprov.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcOverlay=syncprov,olcDatabase={2}hdb,cn=config" [root@ldap01 ~]# ##### REPLICATION ON Slave ##### [root@ldap02 ~]# more syncrepl.ldif dn: olcDatabase={2}hdb,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://172.19.33.42:389/ bindmethod=simple binddn="cn=admin,dc=ZZZ,dc=ZZZ" credentials=password searchbase="dc=ZZZ,dc=ZZZ" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:05:00 [root@ldap02 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f syncrepl.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={2}hdb,cn=config" [root@ldap02 ~]# # Testing LDAP ldapsearch -x -b 'uid=testaccount,ou=People,dc=ZZZ,dc=ZZZ' Both LDAP hosts work in the sense that I can authenticate to them. But replication is not working. Please help. TIA

2 1

any working documentation?
by Dmitri Seletski 21 Aug '19

21 Aug '19

Hello. I am new to the list, so if you gonna beat me with your feet - please don't hit me in the face. I did not find help/user list. So post here. Where can I find working documentation for OpenLDAP? Most current i found: https://www.openldap.org/doc/admin24/quickstart.html It says nothing of TLS encryption. I fail to start service See output below: TLSMC: MozNSS compatibility interception begins. tlsmc_intercept_initialization: INFO: entry options follow: tlsmc_intercept_initialization: INFO: cacertdir = `/etc/openldap/certs' tlsmc_intercept_initialization: INFO: certfile = `OpenLDAP Server' tlsmc_intercept_initialization: INFO: keyfile = `/etc/openldap/certs/password' tlsmc_convert: INFO: trying to open NSS DB with CACertDir = `/etc/openldap/certs'. tlsmc_open_nssdb: INFO: trying to initialize moznss using security dir `/etc/openldap` prefix `certs`. tlsmc_open_nssdb: WARN: could not initialize MozNSS context - error -8015. tlsmc_convert: INFO: cannot open the NSS DB, expecting PEM configuration is present. tlsmc_intercept_initialization: INFO: altered options follow: tlsmc_intercept_initialization: INFO: cacertdir = `/etc/openldap' tlsmc_intercept_initialization: INFO: certfile = `OpenLDAP Server' tlsmc_intercept_initialization: INFO: keyfile = `/etc/openldap/certs/password' tlsmc_intercept_initialization: INFO: successfully intercepted TLS initialization. Continuing with OpenSSL only. TLSMC: MozNSS compatibility interception ends. TLS: could not use certificate `OpenLDAP Server'. TLS: error:02001002:system library:fopen:No such file or directory bss_file.c:402 TLS: error:20074002:BIO routines:FILE_CTRL:system lib bss_file.c:404 TLS: error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system lib ssl_rsa.c:468 5d5af51b main: TLS init def ctx failed: -1 5d5af51b slapd destroy: freeing system resources. 5d5af51b slapd stopped. 5d5af51b connections_destroy: nothing to destroy. Where can I submit errata to documentation maintainer?(as quick start clearly doesn't work in my default install of OpenLDAP on CentOS 7) And how can I start SLAPD without encryption? I can generate self signed private/public key and make ln -s of my CA cert folder to 'cacertdir = `/etc/openldap'', but this seems SOOO unnecessary. At least on 'try out' step. Thanks in advance Dmitri

5 6

BDB to LMDB migration and Linux kernel parameters
by openldap-technical＠kolttonen.fi 21 Aug '19

21 Aug '19

Hello! OpenLDAP Admin Guide says: [LMDB] supports indexing like the BDB backends, but it uses no caching and requires no tuning to deliver maximum search performance. We are planning migration from deprecated BerkeleyDB to recommended LMDB. Our OpenLDAP runs on RHEL7. Since the LMDB uses mmap() system calls, is it necessary to tweak any Linux kernel parameters to allow better caching etc.? Thanks for any information. Best regards, Jokke Hämäläinen

1 0

Re: OpenLDAP 2.3 to 2.4 Migration Question
by Razi Ahmad 21 Aug '19

21 Aug '19

Thanks, I'll do that. -- Razi Ahmad Director, IT Infrastructure Services NYU Stern School of Business 14 East 4th Street, Room 327, New York, NY 10012 Phone: 212-998-0172 | Email: razi(a)stern.nyu.edu Follow us on Twitter: @nyustern An Education in *Possible* On Tue, Aug 20, 2019 at 6:36 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Tuesday, August 20, 2019 7:32 PM -0400 Razi Ahmad <razi(a)stern.nyu.edu> > > wrote: > > > > > Thanks, Quanah. I did that and see that memberof was populated. However, > > I also noticed that the number of groups returned when I query for the > > memberOf attribute on one account doesn't match the number of groups > > returned when I search for all groups that this particular user is a > > member of. Do you have any ideas what could be the cause of this mismatch > > or where I should look when troubleshooting? I checked a few other > > accounts and the numbers match. > > Hi Razi, > > Not without more information. What version of OpenLDAP 2.4 did you > upgrade > to? Are all the groups of the same objectClass type? I assume the other > users are also in those same groups? You could try deleting and re-adding > the user as a member to see if that resolves it. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Re: OpenLDAP 2.3 to 2.4 Migration Question
by Razi Ahmad 21 Aug '19

21 Aug '19

Thanks, Quanah. I did that and see that memberof was populated. However, I also noticed that the number of groups returned when I query for the memberOf attribute on one account doesn't match the number of groups returned when I search for all groups that this particular user is a member of. Do you have any ideas what could be the cause of this mismatch or where I should look when troubleshooting? I checked a few other accounts and the numbers match. Thanks, Razi -- Razi Ahmad Director, IT Infrastructure Services NYU Stern School of Business 14 East 4th Street, Room 327, New York, NY 10012 Phone: 212-998-0172 | Email: razi(a)stern.nyu.edu Follow us on Twitter: @nyustern An Education in *Possible* On Tue, Aug 20, 2019 at 4:31 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Tuesday, August 20, 2019 5:17 PM -0400 Razi Ahmad <razi(a)stern.nyu.edu> > > wrote: > > > > > Hi, > > > > > > I'm working on migrating from OpenLDAP 2.3 to 2.4. I've got my 2.4 > > provider set up and customized and have a copy of production data to > > load. I'd like to know if there's any way to have the memberof attribute > > populated during the process of loading the data. I used slapadd but when > > I searched for a user, I didn't see the memberOf attribute. Prior to > > running the slapadd command, I replaced the groupOfUniqueNames > > objectClass with groupOfNames and the uniqueMember attribute with member > > inside my LDIF file. > > You'll have to use ldapadd if you want memberOf populated. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

OpenLDAP 2.3 to 2.4 Migration Question
by Razi Ahmad 20 Aug '19

20 Aug '19

Hi, I'm working on migrating from OpenLDAP 2.3 to 2.4. I've got my 2.4 provider set up and customized and have a copy of production data to load. I'd like to know if there's any way to have the memberof attribute populated during the process of loading the data. I used slapadd but when I searched for a user, I didn't see the memberOf attribute. Prior to running the slapadd command, I replaced the groupOfUniqueNames objectClass with groupOfNames and the uniqueMember attribute with member inside my LDIF file. Thanks. -- Razi Ahmad Director, IT Infrastructure Services NYU Stern School of Business 14 East 4th Street, Room 327, New York, NY 10012 Phone: 212-998-0172 | Email: razi(a)stern.nyu.edu Follow us on Twitter: @nyustern An Education in *Possible*

2 1

mdb index reporting available?
by Marc Roos 20 Aug '19

20 Aug '19

I used to have some help with what and how I should add indexes, but it looks like the new mdb backend is not telling me anymore. Is this correct? Anyway to get a warning when some index needs to be set? bdb_equality_candidates: (xxxx) not indexed bdb_inequality_candidates: (createTimestamp) not indexed etc https://mishikal.wordpress.com/2013/05/16/openldap-a-comparison-of-back-mdb…

4 16

PPolicy: Multiple pwdGraceUseTime attributes
by Ulrich Windl 19 Aug '19

19 Aug '19

Hi! I noticed that one user has multiple pwdGraceUseTime attributes like this: pwdGraceUseTime: 20190409095627Z pwdGraceUseTime: 20190605063107Z pwdGraceUseTime: 20190614121258Z pwdGraceUseTime: 20190723062401Z I don't understand: Doesn't the pwdGraceUseTime record how long/often the user may login despite of an expired password? For the example given, I assume the user has changed the password a few time since the inital grace login. So aren't the older pwdGraceUseTime attributes removed after the password was changed? Or can this happen if some admin chnages the password using some plain replace operation? Regards, Ulrich

2 1

Re: Multi-master replication : read_config: no serverID / URL match found. Check slapd -h arguments.
by HG 19 Aug '19

19 Aug '19

Hi, It is not as easy as you state it. I have a 2nd set up olcServerID: 1 ldap://abc1prdp01.abcgroup.com:1600 olcServerID: 2 ldap://abc2prdp01.abcgroup.com:1600 and SLAPD_URLS="ldapi:/// ldap://:1600/" This works too. Op wo 14 aug. 2019 om 17:03 schreef Quanah Gibson-Mount <quanah(a)symas.com>: > > > --On Wednesday, August 14, 2019 11:23 AM +0200 HG > <hanspeter.sloot(a)gmail.com> wrote: > > > > > olcServerID: 1 ldap://linux1014.ts.aa-srv.com > > olcServerID: 2 ldap://linux1015.ts.aa-srv.com > > Neither of those has a trailing slash. You noted: > > SLAPD_URLS="ldapi:/// ldap://linux1014.ts.aa-srv.com/" > > doesn't start, but > > SLAPD_URLS="ldapi:/// ldap://linux1014.ts.aa-srv.com" > > starts. > > I would expect this. As I said before, it's a MATCH between what's > provided in the olcServerID field and the -h option to slapd (SLAPD_URLS > in > your case). I.e., the software is functioning as documented. If you want > it to match on the trailing slash, adjust your olcServerID values to > include a trailing slash. > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

3 4

use-case for arg const char *dn of ldap_sasl_bind_s()
by Michael Ströder 18 Aug '19

18 Aug '19

HI! It seems I've never passed a DN to SASL bind functions. Could someone please elaborate on a valid use-case for argument dn of libldap function ldap_sasl_bind_s()? Thanks in advance. Ciao, Michael.

2 5

LDAPCon 2019 CFP closimg today
by Howard Chu 18 Aug '19

18 Aug '19

Just a reminder that the Call for Papers is closing today. If you've been thinking about submitting a talk, this is your last chance! https://ldapcon.org/2019 -- -- 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 1

Fresh install changing the hdb to mdb
by Marc Roos 18 Aug '19

18 Aug '19

This is the default file that rhel/centos have in their slapd.d dir for the database. I thought I would just remove this one and place the one for mdb, seems to work, don't know about this entryUUID? Or can I do this with ldapmodify? [@53386e4b0025 cn=config]# cat /tmp/olcDatabase\=\{2\}hdb.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 4f2ac1fc dn: olcDatabase={2}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=my-domain,dc=com olcRootDN: cn=Manager,dc=my-domain,dc=com olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub structuralObjectClass: olcHdbConfig entryUUID: 537b0adc-5476-1039-9bf9-1dc025e1859d creatorsName: cn=config createTimestamp: 20190816133433Z entryCSN: 20190816133433.095410Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20190816133433Z [@53386e4b0025 cn=config]# cat olcDatabase\=\{2\}mdb.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 b6a274bd dn: olcDatabase={2}mdb objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=my-domain,dc=com olcRootDN: cn=Manager,dc=my-domain,dc=com olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub structuralObjectClass: olcMdbConfig entryUUID: 537b0adc-5476-1039-9bf9-1dc025e1859d creatorsName: cn=config createTimestamp: 20190816133433Z entryCSN: 20190816133433.095410Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20190816133433Z

4 4

Initial syncreplication details
by Marc Roos 17 Aug '19

17 Aug '19

Am I correct to understand from this page[0] that the consumer gets its 'new' contextCSN from the slapcat import. (I saw it in the file). And will get all data since that date at startup? The replication id is of no influence. So if I would stop slapd import again the same old slapcat file. It would again receive all new data since that contextCSN? Regardless of the same rid being used with the provider. The idea behind this is that if you create a container with a default imported slapcat/slapadd file. Every time the task is stopped and started. It will go back to it initial container state. (unless you make it statefull of course) I am not adding that much data so I could make a new default image every week or so, this would be used every time a container is launched. (which only happens in a failover situation) [0] https://www.openldap.org/doc/admin24/replication.html

2 2

Environment variable in slapd config
by Marc Roos 16 Aug '19

16 Aug '19

Is it possible to reference an environment variable in olcSyncrepl: {0}rid= ? --On Saturday, August 10, 2019 6:54 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > Are you talking about the serverID? > > serverID is not needed on a read-only consumer. Just leave it out. He's talking about replication ID (rid), and it's clearly out of bounds in his post. The slapd.conf/slapd-config man pages clearly document the allowed range that can be used for a RID. rid identifies the current syncrepl directive within the replication consumer site. It is a non-negative integer not greater than 999 (limited to three decimal digits --Quanah --

6 16

RE: Environment variable in slapd config
by Marc Roos 16 Aug '19

16 Aug '19

I guess I am missing some info??? Is there any animosity between openldap and redhat? My general perspective is RedHat has made a core business of supporting a linux enterprise os. So I do hope that, if the shit hits the fan, you can rely on the paid services based on the knowledge of their 10k+ employees or so? These guys that work on ceph are doing a great job, looks like very competent people. And now they are owned by IBM I like them even more. :) Always have had IBM in high regards with their r&d. -----Original Message----- Subject: RE: Environment variable in slapd config --On Friday, August 16, 2019 5:17 PM +0200 Marc Roos <M.Roos(a)f1-outsourcing.eu> wrote: > I am more fan of Centos because then I can fall back on RedHat > support, especially for production environments. That's the most laughable statement (in relation to OpenLDAP at least) that I've heard in years. Thanks for the morning chuckle. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: Make slapadd faster?
by Marc Roos 16 Aug '19

16 Aug '19

Ok ok I will look at this mdb again. -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@symas.com] Subject: Re: Make slapadd faster? --On Friday, August 16, 2019 10:14 AM +0200 Marc Roos <M.Roos(a)f1-outsourcing.eu> wrote: > > I know you can disable some checks to make slapadd faster. But I think > in my test vm with limited disk iops, it looks like this disk io is > the problem. > I am not sure how slapadd adds entries, I guess one at a time? You > could get a significant improvement by reading more entries and > writing more entries at once? And if such a batch transaction fails > you can always go back to submitting the transactions of the batch one > by one, to identify which one is failing. Stop using back-hdb, it's signficantly slower than back-mdb. If you're going to insist on using back-hdb, then you *must* have a well tuned DB_CONFIG before you import. For any backend, ensure you have tool-threads set appropriately (For back-mdb, values > 2 are ignored). Use the -q flag if you know the LDIF is good. slapadd has been heavily profiled and tested. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Make slapadd faster?
by Marc Roos 16 Aug '19

16 Aug '19

I know you can disable some checks to make slapadd faster. But I think in my test vm with limited disk iops, it looks like this disk io is the problem. I am not sure how slapadd adds entries, I guess one at a time? You could get a significant improvement by reading more entries and writing more entries at once? And if such a batch transaction fails you can always go back to submitting the transactions of the batch one by one, to identify which one is failing.

2 1

recommended ppolicy pwdCheckModule
by Dave Macias 16 Aug '19

16 Aug '19

Hello, Currently we use ppm https://github.com/ltb-project/ppm which works quite well as a quality checker. Wanted to see what others use. Was looking around and found some interesting ones: pam_pwquality ( i believe these are only for users in passwd file ) ppchecker http://www.meddeb.net/pqchecker/?Idx=0 Any input is appreciated. Thanks! Dave

2 1

Openldap in container advice, how have you done it?
by Marc Roos 16 Aug '19

16 Aug '19

I was thinking of putting read-only slapd('s) in a container environment so other tasks can query their data. Up until now I have had replication only between vm's. To be more flexible I thought of using stateless containers. Things that could be caveats - replication id's say I spawn another instance, I need to have a new replication id to get updates from the master. But what if the tasks is killed, should I keep this replication id? Or better just always use a random unique replication id whenever a slapd container is launched? Maybe use launch date/time (date +'%g%H%M%S%2N') as repid? Is this giving issues with the master? What if I test with launching instances and the master will think there are a hundred slaves that are not connecting anymore? - updating of a newly spawned slapd instance When the new task is launched, it is not up to date with its database, can I prevent connections to the slapd until it is fully synced? Say I have user id's in slapd, it could be that when launching a new instance, this user is not available yet. When clients are requesting this data, they do not get it, and this user could be 'offline' until that specific instance of slapd is fully updated. - to prevent lots of records syncing Can I just copy the data of /var/lib/ldap of any running instance to the container default image? Or does it have some unique id's that will prevent this data to be run multiple times? Is there some advice on how to do this? - doing some /var/lib/ldap cleanup I am cleaning with db_checkpoint -1 -h /var/lib/ldap, and db_archive -d. Is there an option slapd can initiate this? - keep uniform configuration environment, or better a few different slapd instances? In my current environment vm slave slapd's only sync data from the master that the masters acls allow access to. That results in that on some vm's the ldap database is quite small and on other it is larger. I think for the container slapd instances to have all data, and just limit client access via the acls. But this means a lot more indexes on the slapd What else am I missing?

4 5

RE: Antw: RE: Openldap in container advice, how have you done it?
by Marc Roos 16 Aug '19

16 Aug '19

The ip address is known when I start the container that would mean I need to sed some ready ldif and import it into the slapd at runtime. That would also require the the availability of some secret to be able to import it. Although I have prepared the container for ldif fetching. Nicer would be if I could specify something like an environment variable in olcSyncrepl -----Original Message----- From: Ulrich Windl [mailto:Ulrich.Windl@rz.uni-regensburg.de] Sent: maandag 12 augustus 2019 8:56 To: Marc Roos Subject: Antw: RE: Openldap in container advice, how have you done it? >>> "Marc Roos" <M.Roos(a)f1-outsourcing.eu> schrieb am 10.08.2019 um 14:07 in Nachricht <"H00000710014b895.1565438831.sx.f1-outsourcing.eu*"@MHS>: > Ok so long rep id is not going to work modifying entry > "olcDatabase={2}hdb,cn=config" > ldap_modify: Other (e.g., implementation specific) error (80) > additional info: Error: parse_syncrepl_line: syncrepl id > 1911533132 is out of range [0..999] Why not derive the ID from some container ID or from the container's IP address? > > > > > ‑‑‑‑‑Original Message‑‑‑‑‑ > From: Marc Roos > Sent: zaterdag 10 augustus 2019 1:24 > To: openldap‑technical(a)openldap.org > Subject: Openldap in container advice, how have you done it? > > > > I was thinking of putting read‑only slapd('s) in a container > environment so other tasks can query their data. Up until now I have > had replication only between vm's. > > To be more flexible I thought of using stateless containers. Things > that could be caveats > > ‑ replication id's > say I spawn another instance, I need to have a new replication id to > get updates from the master. But what if the tasks is killed, should I > keep this replication id? Or better just always use a random unique > replication id whenever a slapd container is launched? Maybe use > launch date/time (date +'%g%H%M%S%2N') as repid? Is this giving issues > with the master? What if I test with launching instances and the > master will think there are a hundred slaves that are not connecting anymore? > > ‑ updating of a newly spawned slapd instance When the new task is > launched, it is not up to date with its database, can I prevent > connections to the slapd until it is fully synced? > Say I have user id's in slapd, it could be that when launching a new > instance, this user is not available yet. When clients are requesting > this data, they do not get it, and this user could be 'offline' until > that specific instance of slapd is fully updated. > > ‑ to prevent lots of records syncing > Can I just copy the data of /var/lib/ldap of any running instance to > the container default image? Or does it have some unique id's that > will prevent this data to be run multiple times? Is there some advice > on how to do this? > > ‑ doing some /var/lib/ldap cleanup > I am cleaning with db_checkpoint ‑1 ‑h /var/lib/ldap, and db_archive ‑d. > Is there an option slapd can initiate this? > > ‑ keep uniform configuration environment, or better a few different > slapd instances? > In my current environment vm slave slapd's only sync data from the > master that the masters acls allow access to. That results in that on > some vm's the ldap database is quite small and on other it is larger. > I think for the container slapd instances to have all data, and just > limit client access via the acls. But this means a lot more indexes on > the slapd > > What else am I missing?

1 0

PID file /var/run/openldap/slapd.pid not readable (yet?) after start
by Paul Pathiakis 14 Aug '19

14 Aug '19

Hi.... After the previous issue... I went to startup slapd and got the error above. I don't even know how to address that. Slapd won't even start. I'm on CentOS 7. :( systemctl status slapd.service ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled) Active: failed (Result: timeout) since Wed 2019-08-14 11:34:15 EDT; 2min 7s ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Process: 15117 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=0/SUCCESS) Process: 15102 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS) Main PID: 14277 (code=exited, status=0/SUCCESS) Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com systemd[1]: Starting OpenLDAP Server Daemon... Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com runuser[15105]: pam_unix(runuser:session): session opened for user ldap by (uid=0) Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com runuser[15105]: pam_unix(runuser:session): session closed for user ldap Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com slapd[15117]: @(#) $OpenLDAP: slapd 2.4.44 (Jan 29 2019 17:42:45) $ mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/openlda...s/slapd Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com systemd[1]: PID file /var/run/openldap/slapd.pid not readable (yet?) after start. Aug 14 11:34:15 NewLDAP.hq.boston-engineering.com systemd[1]: slapd.service start operation timed out. Terminating. Aug 14 11:34:15 NewLDAP.hq.boston-engineering.com systemd[1]: Failed to start OpenLDAP Server Daemon. Aug 14 11:34:15 NewLDAP.hq.boston-engineering.com systemd[1]: Unit slapd.service entered failed state. Aug 14 11:34:15 NewLDAP.hq.boston-engineering.com systemd[1]: slapd.service failed. Hint: Some lines were ellipsized, use -l to show in full. [root@NewLDAP openldap]# systemctl start slapd.service Job for slapd.service failed because a timeout was exceeded. See "systemctl status slapd.service" and "journalctl -xe" for details. Thank you, P.

3 2

mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792)
by Paul Pathiakis 14 Aug '19

14 Aug '19

Hi, I'm reloading a DB into OpenLDAP after an upgrade. It starts off fine with: ldapadd -f ./20190812-200001.ldif -v -D "cn=root,dc=hq,dc=example,dc=com" -h newldap.hq.example.com -W -c However, during the load, it gets through a few hundred entries and then: adding new entry "cn=ZRO001-INTERNAL,ou=ZRO001,ou=Projects,dc=hq,dc=example,dc=com"ldap_add: Other (e.g., implementation specific) error (80) additional info: index generation failed During the load, it seems that the indexes are failing as well. Could I have what the issue is?How do I correct it?What are the commands I run properly load this (and generate the indexes)?How do I make sure enough space for the DB and the indexes is allocated? @(#) $OpenLDAP: slapd 2.4.44 (Jan 29 2019 17:42:45) $ mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd Thank you! P.

2 1

Re: Multi-master replication : read_config: no serverID / URL match found. Check slapd -h arguments.
by Quanah Gibson-Mount 14 Aug '19

14 Aug '19

--On Wednesday, August 14, 2019 11:23 AM +0200 HG <hanspeter.sloot(a)gmail.com> wrote: > > olcServerID: 1 ldap://linux1014.ts.aa-srv.com > olcServerID: 2 ldap://linux1015.ts.aa-srv.com Neither of those has a trailing slash. You noted: SLAPD_URLS="ldapi:/// ldap://linux1014.ts.aa-srv.com/" doesn't start, but SLAPD_URLS="ldapi:/// ldap://linux1014.ts.aa-srv.com" starts. I would expect this. As I said before, it's a MATCH between what's provided in the olcServerID field and the -h option to slapd (SLAPD_URLS in your case). I.e., the software is functioning as documented. If you want it to match on the trailing slash, adjust your olcServerID values to include a trailing slash. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Username case
by JC 14 Aug '19

14 Aug '19

I have an OpenLDAP 2.4.42 server in which I have loaded an LDIF file that contains (among other entries) the following: # james, staff, yoyodyne.com dn: uid=james,ou=staff,dc=yoyodyne,dc=com uid: james cn: james objectClass: account objectClass: posixAccount loginShell: /bin/bash uidNumber: 1010 gidNumber: 100 homeDirectory: /home/james Separately, I have a Centos 7 box that retrieves user information from the OpenLDAP server above, by means of the Name Service Switch framework in the Centos 7 system. Users to be authenticated in this box may not be defined locally, but in the OpenLDAP server alone; PAM has been configured in the Centos system so that, for such users, and when attempting to log in over SSH, a directory is created in the Centos box on the fly as necessary, using the path retrieved from the OpenLDAP server in the homeDirectory attribute for the user. The authentication itself is carried out by a remote RADIUS server; PAM is correctly configured for this too. This works fine as described, in that when one attempts to log in over SSH into the Centos system as james, provided that the right password is supplied, the '/home/james' directory is created in the Centos system and an interactive SSH session is established. What I would be interested in next is an OpenLDAP setup so that the entry for a given user can be retrieved from the OpenLDAP server in a case-insensitive manner. The goal is to be able to authenticate username, password pairs over the SSH interface in the Centos7 system, with the username being cases-insensitive. As far as I can tell, in the process of establishing an SSH session, the OpenSSH daemon in the Centos 7 system will attempt to verify that the username is valid by invoking the gepwnam() Linux system call. This function will attempt to retrieve information for its argument - a username string - in a case-sensitive way. It first looks into the relevant local files and, if nothing is found and the NSS framework is appropriately configured, it will next attempt to obtain the data from an LDAP server. PAM helps me here by providing a PAM module (pam_regex) which enables me to normalize incoming usernames - in essence, this module makes is easy to recast all incoming usernames to strings where all uppercase letters are transformed into their lowercase versions. The problem that I have is that OpenSSH invokes getpwnam() both before and after the pam_regex module has been invoked. Thus, if the username received from the client is, say, James, OpenSSH will invoke getpwnam("James") first, and getpwnam("james") later, after pam_regex has normalized "James". The upshot here seems to be that what I would need is an OpenLDAP setup such that when getpwnam("james") and getpwnam("James") - or any other case combination of "James" - are invoked, the OpenLDAP server would return the same user data. Now it seems to be the case that, with a user entry in OpenLDAP as described above, getpwnam("james") will look for an entry such that the its uid attribute takes the value "james". I.e. if the value of uid is, say, "James" then it will be ignored. Which, following the discussion above, doesn't fit my goal. I guess that the question would be the following: Is it possible to configure OpenLDAP so that getpwnam() can retrieve a given entry from the OpenLDAP server in a case-insensitive way? How would one create an entry for a user identified as James so that getpwnam("James"), getpwnam("james"), getpwnam("JAMES"), etc. would all cause the OpenLDAP server to return exactly the same Linux user data (uidNumber, gidNumber, homeDirectory)? Other than the obvious and impractical approach consisting of creating identical entries for all the case combinations of the target name, that is.

4 5

OpenLDAP 2.5 plans and community engagement
by Ondřej Kuzník 13 Aug '19

13 Aug '19

Hi all, as 2.4 has finally stabilised and the ITS list is getting shorter not longer (thanks to Quanah's tireless efforts), the project can finally tackle some of the long-standing pain points. So this post aims to outline where we are/want to move to as well as to start a discussion and hopefully get you, the community, more involved on the road to 2.5 and beyond. We would love to welcome more people to participate in the project and make it more active and resilient. People of various skills and experience can make a difference, I am personally happy to assist anyone who wants to contribute with getting up to speed and start helping out, and for sure I'm not the only one. Also OpenLDAP is about more than just C programming and I'll try to outline the main areas where we want to focus our work in the short term here: One of the pain points in the 2.4 release cycle was the level of testing done on the code before we have released. There are issues with the existing test suite that make testing hard and I will come to how this could be tackled in a later email. In the short term however, we could benefit from having the tests we have run more often and on more diverse environments. If you have a chance to run it regularly, in a loop and report issues picked up, that would be a definite help. If you could help extend the test suite to cover scenarios that are of interest to you and are not appropriately covered yet, even better. Another issue frustrating both users and contributors to the project has been the existing jitterbugs bug tracker (a.k.a. ITS), which has by now outlived its usefulness. Plans to move to a project-hosted Gitlab instance + Bugzilla (via Gitlab's built in Bugzilla integration) are being made and this should make the issue tracker searchable again, help with triage as well as greatly improve the visibility into our release process. Especially after the migration, this would be another opportunity for anyone with just a bit of spare time to help by triaging open issues so we can make timely releases of better quality. I'm sure everyone agrees our website could do with a redesign. We've started looking into this but it has been a slow process so far and if you can contribute here, that might speed things up. It doesn't need much, keeping it a collection of static html pages, just a slight reorganisation of the content that is more friendly to anyone visiting it for the first time plus a simplistic design along the lines of many other open source projects (openssl.org for example) would go a long way. This leads to documentation, much of which is already hosted on the website. While I believe there is good work to be done on the admin guide, it is one of the better parts of our documentation. This is where user feedback on its usefulness is more important, please read it, have people on your team read it and show it people just getting started and report which parts are confusing, how they could be improved. We also intend to document our contributor guidelines in a more readable way. The FAQ site however is on the opposite side of the spectrum and will be removed at some later point. There have been two suggestions how to replace it. We could use Gitlab internal wiki or a static webpage site based on Gitlab pages and we want to transfer over articles that are still relevant. In general, moving to Gitlab should let us integrate CI much better, especially if there are people willing to integrate and manage external runners. As mentioned above, we could definitely do with more regular testing on non-Linux platforms, e.g. *BSD or Windows+MSYS2. Pull requests might then also be automatically tested. Let us know what the pain points have been with OpenLDAP when you were just starting, right now and if you have a suggestion how to make it easier to start using it. Or if you wanted to contribute, has anything discouraged you? There are things we might not be able to influence easily (LDAP itself can be complex), but a fresh look might help direct efforts in the right direction. Thanks ever so much for reading this far. This email is long enough already so I will follow up with another one about my long term plans to overhaul the test infrastructure and other tools that might be worth introducing to help with setting up and managing OpenLDAP deployments. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

11 39

Re: Multi-master replication : read_config: no serverID / URL match found. Check slapd -h arguments.
by HG 13 Aug '19

13 Aug '19

Hi, For example: When /etc/sysconfig/slapd contains: SLAPD_URLS="ldapi:/// ldap://linux1014.ts.aa-srv.com/" # Any custom options SLAPD_OPTIONS="-4" # Keytab location for GSSAPI Kerberos authentication #KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab" systemctl start slapd fails But with: SLAPD_URLS="ldapi:/// ldap://linux1014.ts.aa-srv.com" # Any custom options SLAPD_OPTIONS="-4" # Keytab location for GSSAPI Kerberos authentication #KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab" It starts without any trouble. I took me hours to find this :-( Regards Hans Op ma 12 aug. 2019 om 18:03 schreef Quanah Gibson-Mount <quanah(a)symas.com>: > --On Monday, August 12, 2019 12:38 PM +0200 HG <hanspeter.sloot(a)gmail.com> > > wrote: > > > When I stop and start the slapd service the latter fails with : > > Aug 12 11:33:17 ldap1.domain.com slapd[30972]: @(#) $OpenLDAP: slapd > > 2.4.44 (Jan 29 2019 10:05:51) $ > > It means that there is no match between what you defined as the URI's > associated with olcServerID and the -h argument to slapd, so it cannot > link > a serverID to this instance of slapd. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Filter memberOf attributes
by Markus Ludwig Grandpré 13 Aug '19

13 Aug '19

Dear list members, i've recently read that dn syntax in memberOf attributes does not allow substring matching in an ldap search filter like: (memberOf=cn=41*) Is there another way implement a substring search in memberOf attributes? Given the following structure: dn: cn=user0,ou=people,o=univeritaet konstanz,c=de memberOf: cn=410000,ou=groups,o=univeritaet konstanz,c=de dn: cn=user1,ou=people,o=univeritaet konstanz,c=de memberOf: cn=410001,ou=groups,o=univeritaet konstanz,c=de dn: cn=user2,ou=people,o=univeritaet konstanz,c=de memberOf: cn=410002,ou=groups,o=univeritaet konstanz,c=de ... dn: cn=user100,ou=people,o=univeritaet konstanz,c=de memberOf: cn=410100,ou=groups,o=univeritaet konstanz,c=de dn: cn=user101,ou=people,o=univeritaet konstanz,c=de memberOf: cn=420000,ou=groups,o=univeritaet konstanz,c=de ... is there an appropriate ldap search filter expression that can be used to filter all memberOf attributes that begin with 41? Whereby compound ldap search expressions like: (| (memberOf=cn=410000,ou=groups,o=univeritaet konstanz,c=de) (memberOf=cn=410001,ou=groups,o=univeritaet konstanz,c=de) (memberOf=cn=410002,ou=groups,o=univeritaet konstanz,c=de) ... (memberOf=cn=410100,ou=groups,o=univeritaet konstanz,c=de) ) are not intended to become implemented, because in real world they would get much too long and therefore too hard to maintain. Best regrads, Markus -- Markus Ludwig Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) DV-Anwendungsprogrammierer / Abteilung Basisdienste 78457 Konstanz, Deutschland ++49 7531 88 4342

1 0

Transaction commit speed
by Sam Dave 13 Aug '19

13 Aug '19

Hi, Are transaction commits always fast (almost instantaneous) operations compared to the read or write operations within it? Is it possible for say an mdb_cursor_get or mdb_put to be faster than a subsequent mdb_txn_commit, and if so under what circumstances can that happen? This is relevant info for UI applications showing a progress indicator. If an mdb_txn_commit is always fast, we can rely on the _get/_put count to calculate the percentage. Thanks, Sam

3 2

Re: Multi-master replication : read_config: no serverID / URL match found. Check slapd -h arguments.
by HG 12 Aug '19

12 Aug '19

Thanks I understood that already. But I found out that SLAPD_URLS in /etc/sysconfig/slaps has an issue. It contains ldapi:/// and ldap:/// When I modify the latter in ldap://xxx.yyy.com/ slaps will not work. After removing the last / it works fine. Looks like a bug Op ma 12 aug. 2019 18:03 schreef Quanah Gibson-Mount <quanah(a)symas.com>: > --On Monday, August 12, 2019 12:38 PM +0200 HG <hanspeter.sloot(a)gmail.com> > > wrote: > > > When I stop and start the slapd service the latter fails with : > > Aug 12 11:33:17 ldap1.domain.com slapd[30972]: @(#) $OpenLDAP: slapd > > 2.4.44 (Jan 29 2019 10:05:51) $ > > It means that there is no match between what you defined as the URI's > associated with olcServerID and the -h argument to slapd, so it cannot > link > a serverID to this instance of slapd. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Multi-master replication : read_config: no serverID / URL match found. Check slapd -h arguments.
by HG 12 Aug '19

12 Aug '19

Hello all, I am trying to setup multi-master replication while following the instructions on: https://www.itzgeek.com/how-tos/linux/centos-how-tos/configure-openldap-mul… When I stop and start the slapd service the latter fails with : Aug 12 11:33:17 ldap1.domain.com slapd[30972]: @(#) $OpenLDAP: slapd 2.4.44 (Jan 29 2019 10:05:51) $ mockbuild(a)x86-ol7-builder-02.us.oracle.com: /builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd Aug 12 11:33:17 ldap1.domain.com slapd slapd[30972]: read_config: no serverID / URL match found. Check slapd -h arguments. Aug 12 11:33:17 ldap1.domain.com slapd slapd[30972]: slapd stopped. Aug 12 11:33:17 ldap1.domain.com slapd slapd[30972]: connections_destroy: nothing to destroy. The openldap version is:2.4.44-21.el7_6.x86_64 I have filled /etc/sysconfig/slapd with the right url's. Also used strace to see whether I could determine the cause. This looks like a bug to me. Can anyone help? Regards Hans

2 1

Default autoconf values / building OpenLDAP 2.4.48
by Dominique Fuchs 12 Aug '19

12 Aug '19

Hi everyone, I just started building OpenLDAP 2.4.48 (stable tarball from openldap.org) and realized that there are some autoconf options regarding SLAPD configuration that do not comply with the --help documentation. Specifically: First I got errors regarding missing sql.h, then mysql_config. This led to the conclusion that autoconf tried to enable sql and ndb. However, in the documentation it says it'll default to 'no', which is why I didn't explicitly --disable-ndb and --disable-sql. When I do that, it acts as expected and configure is successful. Unfortunately I'm completely unaware how the handling of these default values is accomplished for autoconf, so I dign't have a chance to look it up myself. Thanks for any hints, Dominique

4 5

How can I run slapd in foreground
by Marc Roos 10 Aug '19

10 Aug '19

Afaik from the mesos executor, it wants to keep the process in foreground, so when the task terminates, it will be detected and restarted. How can I run slapd in foreground?

2 1

Building the OpenLDAP client libraries on Windows
by Olivier Hartmann 09 Aug '19

09 Aug '19

Hello, We are having difficulties building the OpenLDAP client libraries on Windows. Would anyone on this list be willing to share a procedure through which they succeeded in doing that with a recent version of OpenLDAP (2.4.47 or the next one)? The only thing we are after is building the OpenLDAP client libraries (not the server). Any help would be appreciated. Thanks, -Olivier

2 1

Help with LDAP Notifications
by Manojkiran Eda 08 Aug '19

08 Aug '19

1 0

How to change BaseDN? (OpenLDAP/slapd)
by Dominique Fuchs 08 Aug '19

08 Aug '19

Hi everyone, I'm actually stuck trying to set up an OpenLDAP implementation on my server running debian/slapd. Based on the hostname of the server (server.foo.bar) slapd automatically sets up the base config with dc=foo,dc=bar as BaseDN. This runs fine and I can connect successfully. However, I actually want the BaseDN for the LDAP structure to rely on the subdomain ldap.foo.bar (dc=ldap,dc=foo,dc=bar). How can I accomplish this? I already tried to fiddle around with ldapmodify/ldif-files, but the only thing I found online where descriptions of how to add a node, not how to change the root node. This post on SO: https://stackoverflow.com/questions/19537319/change-basedn-in-openldap only explains how to rename an existing setup (and even there I can't imagine there isn't a more native way of changing the BaseDN). Thanks in advance!

5 6

Fwd: Clarification regarding global ldapoptions structure in ldap
by sachidananda sahu 07 Aug '19

07 Aug '19

Hi All, I recently upgraded to openldap 2.4.47, it's working with single threaded connection but with multi threaded getting problem due to global structure of ldapoptions in init.c ------------------------- init.c ------------------------- *struct* ldapoptions <http://opengrok-prd.eng.netapp.com/source/s?defs=ldapoptions&project=dev> ldap_int_global_options <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_int_global_options&pr…> = { LDAP_UNINITIALIZED <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_UNINITIALIZED&project…>, LDAP_DEBUG_NONE <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_DEBUG_NONE&project=dev> LDAP_LDO_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_NULLARG&project=d…> LDAP_LDO_CONNECTIONLESS_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_CONNECTIONLESS_NU…> LDAP_LDO_TLS_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_TLS_NULLARG&proje…> LDAP_LDO_SASL_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_SASL_NULLARG&proj…> LDAP_LDO_GSSAPI_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_GSSAPI_NULLARG&pr…> LDAP_LDO_MUTEX_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_MUTEX_NULLARG&pro…> }; This global structure is accessed at multiple places (such as ldap_pvt_tls_init_def_ctx <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_pvt_tls_init_def_ctx&…>, alloc_handle <http://opengrok-prd.eng.netapp.com/source/s?refs=alloc_handle&project=dev>, ldap_int_tls_connect <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_int_tls_connect&proje…>, *ldap_pvt_tls_destroy <http://opengrok-prd.eng.netapp.com/source/xref/R9.6x/third_party/open_sourc…>, ldap_ld_free*) in tls2.c using the macro lo <http://opengrok-prd.eng.netapp.com/source/s?defs=lo&project=dev> = LDAP_INT_GLOBAL_OPT <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_INT_GLOBAL_OPT&projec…> (); So in case of multi threaded application multiple ldap connection will be using this global structure, for example ldo_tls_ctx of lapoptions will be used. In one thread it can be creating a tls connection and in one it can be destroying the connection. As it's global so it is getting corrupted. Is openldap library thread safe completely ? Because this variable seems to be not for this tls context variable, is there any other way of using this context . As i can see a local variable ldo_tls_ctx exist in dap ld->ldc->ldap_options->ldo_tls_ctx structure, but it's just got assigned with the same address of global structure in ldap_int_tls_connect <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_int_tls_connect&proje…> . So can someone share some thoughts on it ? -- Regards, Sachidananda Sahu

2 8

Re: Trouble with “Connection Refused” errors and timeouts on server with high Thread Backload
by erich_2323 06 Aug '19

06 Aug '19

Hi OpenLdap folks, I ran into an issue with OpenLdap 2.4.44 that I am having trouble finding the root cause of. I run Openldap in syncrepl mode. I have one machine which serves as a write endpoint (let’s call it the master node), and many machines which sync from it, and serve as read-replicas. To ensure that they are in-sync with the Master, each read-replica runs ldapsearch against the Master node every minute. It looks at the entryCSN values for a bunch of objects on the Master, and compares against its own entryCSNs for its copy of these objects. It searches a bunch of different objects, and in total takes about 3 seconds for a read replica to do this search (I have duration logging on LDAP operations enabled by merging in this patch (http://www.openldap.org/its/index.cgi/Software%20Enhancements?id=8054;page=9). About 20 MB are transferred to each read-replica when they run this script. NOTE: I prefer not to use the contextCSN for this sync because I only care about certain objects of the database being in-sync, and I need to know specifically which objects are in-sync vs out-of-sync. I doubled the amount of times this script runs per read-replica. Therefore instead of each read-replica running this script once per minute, it was running it twice per minute. Shortly thereafter, I started getting reports from someone who writes to the LDAP Master regularly that they are seeing a high amount of write operations failing with timeouts and “Connection Refused” errors. I reduced the frequency of the script back to once per minute, and the writer reported that they were no longer seeing these errors. I assumed that this Connection Refused error was due to the fact that Openldap 2.4 uses a single thread for incoming connections (sources: https://lwn.net/Articles/755207/, https://www.openldap.org/pub/slim/OpenLDAP_Conn_Mgmt.pdf (section 3)), and the pending connection backlog on the socket was too high. Therefore the syscall is returning Connection Refused. This may be similar to the frontend contention issue described in this post: (http://www.openldap.org/lists/openldap-devel/201308/msg00003.html). I noticed that the values for cn=Backload,cn=Threads,cn=Monitor as well as cn=Pending,cn=Threads,cn=Monitor got very high when the read-replicas were running the script twice as much. For example, Pending is usually sitting around 5-6, but during the time of high read traffic, I saw Pending count increase by over 1000 times (my graph looks very spiky, with pending threads shooting up to 1000x, then down to 10x or 100x the next minute, then back up, etc.). I understand that cn=Backload is simply Active + Pending Threads, and interestingly Active threads stayed at normal levels. I am wondering what Pending threads means exactly, and how is Pending Threads different from Read/Write Waiters? (Interestingly, Read/Write Waiters stayed at normal levels.) I attempted to reproduce this issue by running the script concurrently from a few different clients, hoIver, I was unable to get the Pending/Backload Threads up to similar levels (this value hovered around 16, which seems healthy. I did not see it spike up to similarly high levels). I observed that the latency of the Master from the read-replica’s perspective increased quite a bit during this test, but was unable to observe Connection Refused issues. Is my assumption about the cause of this issue (single thread for incoming connections) down the right track? Is this behavior (high Pending/Backload Threads, Connection Refused errors) a known occurrence? Are there any other metrics that I can observe which would indicate what is the cause of the Connection Refused errors? Is there a reliable way to repro this issue (without doubling the frequency of the read-replica script)? NOTE: I have the following settings configured, which I suspect may be relevant: olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 60 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcListenerThreads: 1 olcLocalSSF: 71 olcLogLevel: Stats olcLogLevel: Sync olcSizeLimit: unlimited olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcToolThreads: 1 olcWriteTimeout: 0 Thanks, Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 3

Re: Openldap Acl
by Quanah Gibson-Mount 29 Jul '19

29 Jul '19

--On Sunday, July 28, 2019 11:47 PM +0100 Meryem Fahim <meryem.f97(a)gmail.com> wrote: Hello, Please keep replies on the list. > Hello > Thank you for taking the time to respond.You have asked me to provide you > with my set of ACLs so here it is: > dn: olcDAtabase={0}config,cn=config You're changing the ACLs on the wrong database. That DN is clearly for the cn=config datbase, and so would not apply to the DB that contains your users, etc. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Openldap Access Control
by Meryem Fahim 26 Jul '19

26 Jul '19

HELLO; i'm working on an Openldap project where im supposed to create groups and users and be able to work with phpldapadmin,I've done all of that. Now I want to modify access whereas ensaUser and estUser when logging in will be able to see only the branch they are in(and give that privilege to admin only) I tried so many ACLs (using ldapmodify) but nothing seems to work,when I log in with one of the users I still can see the whole dataBase,I would appreciate some help.thank you

2 1

slapd-sock v2.4.47 not returning LDIF
by Giuseppe De Marco 26 Jul '19

26 Jul '19

Hello everyone, I made a configuration to get slapd-sock to work with a python3 server (gevent). The slapd configuration can be reproduced less then a minute using this ansible playbook: https://github.com/peppelinux/ansible-slapd-eduperson2016 the python3 server is available at the following resource, slapd-sock backend configuration can be found in the README file: https://github.com/peppelinux/pyMultiLDAP It is the following: ldapadd -Y EXTERNAL -H ldapi:/// <<EOF dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModuleLoad: back_sock.la EOF ldapadd -Y EXTERNAL -H ldapi:/// <<EOF dn: olcDatabase={4}sock,cn=config objectClass: olcDbSocketConfig olcDatabase: {4}sock olcDbSocketPath: /var/run/multildap.sock olcSuffix: dc=proxy,dc=unical,dc=it olcDbSocketExtensions: binddn peername ssf EOF I tested that this configuration doesn't have any problems in a Debian 9 installation (slapd 2.4.44) but in a Debian10 (2.4.47) does. Even if I use "servers/slapd/back-sock/searchexample.pl" [1] I get the same faulty result, described as follow: ```` # extended LDIF # # LDAPv3 # base <dc=proxy,dc=unical,dc=it> with scope subtree # filter: uid=mario # requesting: ALL # # search result search: 2 result: 0 Success text: OK ```` As we can see RESULT was found but with any preceeding ldif. Looking into /var/log/slapd.log I found the same behaviour of Debian9 installation: ```` [25-07-2019 10:33:57] slapd debug conn=1036 fd=20 ACCEPT from IP= 127.0.0.1:54674 (IP=0.0.0.0:389) [25-07-2019 10:33:57] slapd debug conn=1036 op=0 BIND dn="cn=admin,dc=testunical,dc=it" method=128 [25-07-2019 10:33:57] slapd debug conn=1036 op=0 BIND dn="cn=admin,dc=testunical,dc=it" mech=SIMPLE ssf=0 [25-07-2019 10:33:57] slapd debug conn=1036 op=0 RESULT tag=97 err=0 text= [25-07-2019 10:33:57] slapd debug conn=1036 op=1 SRCH base="dc=proxy,dc=unical,dc=it" scope=2 deref=0 filter="(objectClass=*)" [25-07-2019 10:33:57] slapd debug conn=1034 op=5 SRCH base="ou=people,dc=testunical,dc=it" scope=2 deref=3 filter="(objectClass=*)" [25-07-2019 10:33:57] slapd debug conn=1034 op=5 SRCH attr=eduPersonPrincipalName schacHomeOrganization mail uid givenName sn eduPersonScopedAffiliation schacPersonalUniqueId schacPersonalUniqueCode userPassword [25-07-2019 10:33:57] slapd debug conn=1034 op=5 SEARCH RESULT tag=101 err=0 nentries=4 text= [25-07-2019 10:33:57] slapd debug sock: fgets failed: Success (0) [25-07-2019 10:33:57] slapd debug conn=1036 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= OK [25-07-2019 10:33:57] slapd debug conn=1036 op=2 UNBIND [25-07-2019 10:33:57] slapd debug conn=1036 fd=20 closed ```` I also tried to use admin credentials, as shown in the slapd log. I also tried to do a fresh slapd installation by hands, on Debian9 slapd-sock works (searchexample.pl <https://github.com/openldap/openldap/blob/master/servers/slapd/back-sock/se…> and pyMultiLdap) but not Debian10. I read that there are two additional features regarding slapd-sock in openldap 2.4.47. These are: - Added slapd-sock DN qualifier for subtrees to be processed (ITS#8051) - Added slapd-sock ability to send extended operations to external listeners (ITS#8714) My doubts: Is there any need to change configuration, following ITS#8714 and ITS#8051, to get it to work in Debian10 ? or Am I facing a bug present in openldap 2.4.47 ? Thank you in advance for everything you would tell me, Cheers [1] https://github.com/openldap/openldap/blob/master/servers/slapd/back-sock/se… -- ____________________ Dott. Giuseppe De Marco CENTRO ICT DI ATENEO University of Calabria 87036 Rende (CS) - Italy Phone: +39 0984 496961 e-mail: giuseppe.demarco(a)unical.it

3 5

Mapping gid numbers
by JC 24 Jul '19

24 Jul '19

My question is not strictly an LDAP one, but perhaps somebody here with experience in the LDAP and Linux worlds can throw some light on it. I understand how to map attributes, as defined in an LDAP server, to other attributes in a Linux when the NSS framework is used in the latter. Is it possible to map values of attributes? Let's say I have an OpenLDAP server that defines a certain group with a gid number 10000. Would it be possible to map that 10000 to (say) 5000 in the Linux system? That is, every time an operation is executed in the Linux system that uses the group information, the gid would be retrieved from the OpenLDAP server as 10000, and automatically be converted to 5000. Can this be done?

4 4

Re: where is debuglevel documented ?
by danielle lampert 23 Jul '19

23 Jul '19

Hello, yes I was asking for the log levels of the command-line tools like ldapsearch. Thanks for your answers. This doc helps ( https://www.openldap.org/doc/admin24/runningslapd.html ) but is not completely right, as levels 4 and 8 don't do anything special. I will rely on the this doc for my tests, thanks again. D.L. Le lun. 22 juil. 2019 à 16:14, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > --On Monday, July 22, 2019 10:56 AM -0400 Brian Reichert > <reichert(a)numachi.com> wrote: > > > I think that the OpenLDAP server and client share debug flags. I may be > > wrong on this. > > > > https://www.openldap.org/doc/admin24/runningslapd.html > > This is correct. It's trivial to grep the source and confirm this as well. > > --Quanah > > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > >

2 1

Re: Intensive disk write after long-running LDAP activity terminated
by Tamás Rébeli-Szabó 23 Jul '19

23 Jul '19

Quanah, thank you for your warning. We are aware that it is a very old release and a version upgrade is already being planned. But for the moment, that is the currently installed version and that is what produced the strange phenomenon. Regards, tamas Quanah Gibson-Mount <quanah(a)symas.com> ezt írta (időpont: 2019. júl. 22., H, 15:25): > --On Monday, July 22, 2019 2:20 PM +0200 Tamás Rébeli-Szabó > <tamas.rebeli.szabo(a)webvalto.hu> wrote: > > > > > > > > > Hello, > > > > we had a long-running (several days) process doing add and modify > > operations in OpenLDAP 2.4.41 + LMDB backend + SLES 11.3. > > I would note you're talking about OpenLDAP and LMDB releases that are over > 4 years old, past which point numerous issues have been fixed for both. > > LMDB 0.9.15 Release (2015/06/19) > OpenLDAP 2.4.41 Release (2015/06/21) > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Openldap issues user issues after updating user groups
by 王峰 23 Jul '19

23 Jul '19

Hello, wish you happiness! Sorry, take up your precious time. I encountered a problem. In the openldap HA environment, the update user group found that it was not synchronized to the client in time (8 hosts, 5 stations, 3 syncs, not synchronized, waiting for half an hour to complete synchronization). Has anyone encountered such a problem? And would like to know how to troubleshoot such problems, I use openldap soon. thank you very much! 发送自 Windows 10 版邮件应用

2 3

where is debuglevel documented ?
by danielle lampert 22 Jul '19

22 Jul '19

hello the ldapsearch man page ( https://www.openldap.org/software//man.cgi?query=ldapsearch&apropos=0&sekti… ) says : *-d* *debuglevel* Set the LDAP debugging level to *debuglevel*. Where can I find the debuglevel values and their meaning ? best regards D.L.

7 8

Intensive disk write after long-running LDAP activity terminated
by Tamás Rébeli-Szabó 22 Jul '19

22 Jul '19

Hello, we had a long-running (several days) process doing add and modify operations in OpenLDAP 2.4.41 + LMDB backend + SLES 11.3. When the process was stopped, we experienced minutes of intensive disk write by LMDB. The LMDB option dbnosync is not set. Checking git we see that there should be a transaction commit in LMDB after every LDAP add/modify operation, and the updating of on-disk contents should happen after each LDAP add/modify operation. Furthermore, at the OS level, dirty pages should be generally flushed every 5 seconds. So we wonder what could possibly cause such a significant I/O burst? Regards, tamas

2 1

Re: Error when try modify olcTLS*
by Igor Sousa 22 Jul '19

22 Jul '19

Hi Quanah, Sorry about my delay to answer you, I've been in vacation and away from PC. I understand that I should use the same name when I'll update this file to make it easy, but it is a new installation and this reason that I need modify this entries. I've tested your suggestion and delete operation has worked fine, but I've still had the same problem described previously when I've tried add new olcTLSCertificateFile or new olcTLSCertificateKeyFile or new olcTLSCACertificateFile. I don't understand the reason for that. [root@localhost ldifs]# ldapmodify -Y EXTERNAL -H ldapi:/// -f 5tls.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) -- Igor Sousa Em sex, 28 de jun de 2019 às 21:53, Quanah Gibson-Mount <quanah(a)symas.com> escreveu: > --On Friday, June 28, 2019 7:33 PM -0300 Igor Sousa <igorvolt(a)gmail.com> > wrote: > > > dn: cn=config > > changetype: modify > > replace: olcTLSCertificateFile > > olcTLSCertificateFile: /etc/openldap/certs/ldap.local.crt > > - > > replace: olcTLSCertificateKeyFile > > olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.local.key > > - > > add: olcTLSCACertificateFile > > olcTLSCACertificateFile: /etc/openldap/certs/ca.cert.pem > > I would suggest simply using the same filenames as you had before, > negating > the need to modify the attributes at all. You're likely hitting ITS#8286 > with the replace operations. Another idea may be to change replace to a > delete+add in the same operation sequence. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

4 10

slapd crashing
by Alex Hebra 19 Jul '19

19 Jul '19

Hi there, I've MMR running on two FreeBSD servers with OpenLDAP 2.4.47. After few days one node always crash with signal 11. The last log I got from slapd is: Jul 17 18:04:19 slapd[676]: syncprov_matchops: skipping original sid 001 When I try to restart the slapd process it eats all the ram memory, until the server become irresponsible. I have to delete the database and re-sync everything to make it works again. Is there a way to find out how can I fix this issue? Thanks.

2 4

Re: Error when try modify olcTLS*
by Igor Sousa 19 Jul '19

19 Jul '19

Hi everybody, I would like to apologize me about this email discussion, in specially to Quanah and Howard. After a ton of emails sent, specially the last Quanah email, I've finally understood my error. Due it be a beginner error, I'm very embarrassed to importune you about it. Then, I would like to apologize me with Quanah, Howard and everyone on openldap-technical(a)openldap.org list about time spent in this problem. Finally, I would like thank all involved that has helped me to solve my problem. OBS: I've removed -aes256 when I've generated server key aiming no encrypting the key. Then I've got to add all olcTLS* entries with ldapmodify and ldif file described in previous emails. -- Igor Sousa Em qui, 18 de jul de 2019 às 17:35, Quanah Gibson-Mount <quanah(a)symas.com> escreveu: > --On Thursday, July 18, 2019 1:08 PM -0700 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: > > >> build@c7rpm:/home/build/git/rheldap/RHEL7_x86_64/BUILD...lapd > >> Jul 18 11:55:29 localhost.localdomain slapd[2133]: main: TLS init def > ctx > >> failed: -1 > >> Jul 18 11:55:29 localhost.localdomain slapd[2133]: Enter PEM pass > phrase: > > > > This clearly indicates your key file is password protected, which is not > > supported. > > To be clear, it's not supported to use a password protected key file and > then try and start slapd via an automated init system such as systemd. To > use a password protected key file requires that you start slapd manually > so > you can provide the password as part of the startup process so slapd can > access it. > > Regards, > Quanah > > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Database problems with OpenIndiana
by dieter＠dkluenter.de 17 Jul '19

17 Jul '19

Hi, I am testing OpenLDAP-2.4.44 on OpenIndiana-Hipster. I have configured two back-mdb databases.For some strange reason a data.mdb and a bdb logfile is created. openldap openldap 45441024 Juli 17 16:45 data.mdb openldap openldap 8192 Juli 17 16:57 lock.mdb root root 10485760 Juli 17 16:57 log.0000000001 After a restart slapd cannot read the data.mdb anymore. -Dieter -- Dieter Klünter | Directory Service http://sys4.de 53°37'09,95"N 10°08'02,42"E

2 3

RE24 testing call (2.4.48) LMDB RE0.9 testing call (0.9.24)
by Quanah Gibson-Mount 16 Jul '19

16 Jul '19

This is expected to be the only testing call for 2.4.48, with an anticipated release, depending on feedback, during the week of 2019/07/22. Specific to this release, it would be helpful if anyone using back-ldap or back-meta with TLS can confirm their existing configurations continue to work (Due to the changes related to ITS#8427). Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.4.48 Engineering Added libldap OpenSSL Elliptic Curve support (ITS#7595) Added libldap Expose OpenLDAP specific interfaces via openldap.h (ITS#8671) Added slapd-monitor support for slapd-mdb (ITS#7770) Fixed liblber leaks (ITS#8727) Fixed liblber with partial flush (ITS#8864) Fixed libldap ASYNC TLS so it works (ITS#8957,ITS#8980) Fixed libldap ASYNC connections with Solaris 10 (ITS#8968) Fixed libldap with SASL_NOCANON=on and ldapi connections (ITS#7585) Fixed libldap to use AI_ADDRCONFIG when available (ITS#7326) Fixed libldap to be able to unset syncrepl TLS options (ITS#7042) Fixed libldap race condition in ldap_int_initialize (ITS#7996, ITS#8450) Fixed libldap return code in ldap_create_assertion_control_value (ITS#8674) Fixed libldap to correctly disable IPv6 when configured to do so (ITS#8754) Fixed libldap to correctly close TLS connection (ITS#8755) Fixed libldap_r handling of deprecated OpenSSL function (ITS#8353) Fixed liblunicode case correspondance (ITS#8508) Fixed slapd with an idletimeout of less than four seconds (ITS#8952) Fixed slapd config parser variable for Windows64 (ITS#9012) Fixed slapd syncrepl fallback handling with delta-syncrepl (ITS#9015) Fixed slapd telephoneNumberNormalize, cert DN validation (ITS#8999) Fixed slapd syncrepl for relax with delta-syncrepl (ITS#8037) Fixed slapd TLS settings on reconnection (ITS#8427) Fixed slapd to restrict rootDN proxyauthz to its own databases (ITS#9038) Fixed slapd to initialize SASL SSF per connection (ITS#9052) Fixed slapo-accesslog with SLAP_MOD_SOFT modifications (ITS#8990) Fixed slapd-ldap starttls connections timeout behavior (ITS#8963) Fixed slapd-ldap TLS settings on reconnection (ITS#8427) Fixed slapd-ldap segfault when entry result doesn't match filter (ITS#8997) Fixed slapd-meta conversion from slapd.conf to cn=config (ITS#8743) Fixed slapd-meta TLS settings on reconnection (ITS#8427) Fixed slapd-meta assertion when network interface goes down (ITS#8841) Fixed slapd-mdb fix bitshift integer overflow (ITS#8989) Fixed slapd-mdb index cleanup with cn=config (ITS#8472) Fixed slapd-mdb to improve performance with alias deref (ITS#7657) Fixed slapo-accesslog possible assert with exops (ITS#8971) Fixed slapo-chain to correctly reject multiple chaining URIs (ITS#8637) Fixed slapo-chain conversion from slapd.conf to cn=config (ITS#8799) Fixed slapo-memberof conversion from slapd.conf to cn=config (ITS#8663) Fixed slapo-memberof for group name change to itself (ITS#9000) Fixed slapo-ppolicy behavior when pwdInHistory is changed (ITS#8349) Fixed slapo-rwm to not free original filter (ITS#8964) Fixed slapo-syncprov contextCSN generation (ITS#9015) Build Environment Fixed slapd to only link to BDB libraries with static build (ITS#8948) Fixed libldap implicit declaration with LDAP_CONNECTIONLESS (ITS#8794) Fixed libldap double inclusion of limits.h in cyrus.c (ITS#9041) Documentation General - Fixed minor typos (ITS#8764, ITS#8761) admin24 - Miscellaneous updates promoting mdb and fixing examples (ITS#9031) slapd.access(5) - Note MDB is the primary backend (ITS#8881) slapd.backends(5) - Note MDB is the recommended backend (ITS#8771) slapd-ldap(5) - Document starttls parameter (ITS#8693) Contrib Added slapo-lastbind capability to forward authTimestamp updates (ITS#7721) LMDB 0.9.24 Engineering ITS#8969 Tweak mdb_page_split ITS#8975 WIN32 fix writemap set_mapsize crash ITS#9007 Fix loose pages in WRITEMAP Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 13

Re: RE24 testing call (2.4.48) LMDB RE0.9 testing call (0.9.24)
by Abdelkader Chelouah 16 Jul '19

16 Jul '19

Hello, make mdb and make mdb-its, all succeded under CentOS 7. As far as concerned back-ldap, commit e224920ea5641b71bbd38604cb58bd1922537e7d (ITS#8427 Take late TLS configuration into account) has fixed the regression introduced by commit 6f623dfa1ca65698c19ccc6c058cd170e633384e (ITS#8427 Set up TLS settings on each reconnection) with my test configuration. Regard, Kader On Mon, Jul 15, 2019 at 6:18 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > This is expected to be the only testing call for 2.4.48, with an > anticipated release, depending on feedback, during the week of 2019/07/22. > > Specific to this release, it would be helpful if anyone using back-ldap or > back-meta with TLS can confirm their existing configurations continue to > work (Due to the changes related to ITS#8427). > > Generally, get the code for RE24: > > < > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h… > > > > Configure & build. > > Execute the test suite (via make test) after it is built. Optionally, cd > tests && make its to run through the regression suite. > > Thanks! > > OpenLDAP 2.4.48 Engineering > Added libldap OpenSSL Elliptic Curve support (ITS#7595) > Added libldap Expose OpenLDAP specific interfaces via openldap.h > (ITS#8671) > Added slapd-monitor support for slapd-mdb (ITS#7770) > Fixed liblber leaks (ITS#8727) > Fixed liblber with partial flush (ITS#8864) > Fixed libldap ASYNC TLS so it works (ITS#8957,ITS#8980) > Fixed libldap ASYNC connections with Solaris 10 (ITS#8968) > Fixed libldap with SASL_NOCANON=on and ldapi connections (ITS#7585) > Fixed libldap to use AI_ADDRCONFIG when available (ITS#7326) > Fixed libldap to be able to unset syncrepl TLS options (ITS#7042) > Fixed libldap race condition in ldap_int_initialize (ITS#7996, > ITS#8450) > Fixed libldap return code in ldap_create_assertion_control_value > (ITS#8674) > Fixed libldap to correctly disable IPv6 when configured to do so > (ITS#8754) > Fixed libldap to correctly close TLS connection (ITS#8755) > Fixed libldap_r handling of deprecated OpenSSL function (ITS#8353) > Fixed liblunicode case correspondance (ITS#8508) > Fixed slapd with an idletimeout of less than four seconds (ITS#8952) > Fixed slapd config parser variable for Windows64 (ITS#9012) > Fixed slapd syncrepl fallback handling with delta-syncrepl (ITS#9015) > Fixed slapd telephoneNumberNormalize, cert DN validation (ITS#8999) > Fixed slapd syncrepl for relax with delta-syncrepl (ITS#8037) > Fixed slapd TLS settings on reconnection (ITS#8427) > Fixed slapd to restrict rootDN proxyauthz to its own databases > (ITS#9038) > Fixed slapd to initialize SASL SSF per connection (ITS#9052) > Fixed slapo-accesslog with SLAP_MOD_SOFT modifications (ITS#8990) > Fixed slapd-ldap starttls connections timeout behavior (ITS#8963) > Fixed slapd-ldap TLS settings on reconnection (ITS#8427) > Fixed slapd-ldap segfault when entry result doesn't match filter > (ITS#8997) > Fixed slapd-meta conversion from slapd.conf to cn=config (ITS#8743) > Fixed slapd-meta TLS settings on reconnection (ITS#8427) > Fixed slapd-meta assertion when network interface goes down (ITS#8841) > Fixed slapd-mdb fix bitshift integer overflow (ITS#8989) > Fixed slapd-mdb index cleanup with cn=config (ITS#8472) > Fixed slapd-mdb to improve performance with alias deref (ITS#7657) > Fixed slapo-accesslog possible assert with exops (ITS#8971) > Fixed slapo-chain to correctly reject multiple chaining URIs (ITS#8637) > Fixed slapo-chain conversion from slapd.conf to cn=config (ITS#8799) > Fixed slapo-memberof conversion from slapd.conf to cn=config (ITS#8663) > Fixed slapo-memberof for group name change to itself (ITS#9000) > Fixed slapo-ppolicy behavior when pwdInHistory is changed (ITS#8349) > Fixed slapo-rwm to not free original filter (ITS#8964) > Fixed slapo-syncprov contextCSN generation (ITS#9015) > Build Environment > Fixed slapd to only link to BDB libraries with static build > (ITS#8948) > Fixed libldap implicit declaration with LDAP_CONNECTIONLESS > (ITS#8794) > Fixed libldap double inclusion of limits.h in cyrus.c (ITS#9041) > Documentation > General - Fixed minor typos (ITS#8764, ITS#8761) > admin24 - Miscellaneous updates promoting mdb and fixing examples > (ITS#9031) > slapd.access(5) - Note MDB is the primary backend (ITS#8881) > slapd.backends(5) - Note MDB is the recommended backend (ITS#8771) > slapd-ldap(5) - Document starttls parameter (ITS#8693) > Contrib > Added slapo-lastbind capability to forward authTimestamp updates > (ITS#7721) > > LMDB 0.9.24 Engineering > ITS#8969 Tweak mdb_page_split > ITS#8975 WIN32 fix writemap set_mapsize crash > ITS#9007 Fix loose pages in WRITEMAP > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > >

1 0

ldap_destroy() vs. ldap_unbind()
by Edgar Fuß 16 Jul '19

16 Jul '19

Hello. I'm sorry if this is a silly question, but the only thing close to an answer I could find is from a post of Hallvard B Furuseth to this list (pre-dating the actual ldap_destroy() introduction) stating that ldap_unbind() was mis-named and should have been called ldap_destroy(). The question is whether to use ldap_destroy() or ldap_unbind(). More precisely, the question is which one is preferable in a single-threaded application that never calls ldap_dup(). >From reading the man page of ldap_dup()/ldap_destroy() and above mentioned post, I would get the impression that technichally, it doesn't matter, so I would gess ldap_unbind() to be slightly preferable because it works with pre-2.4.24 OpenLDAP. However, proposing such an adjustment (https://redmine.lighttpd.net/issues/2849 in case anyone cares[*]) was vigorously turned down stating I didn't know what I was talking about so I might be missing something. Could someone shed light on this? I'm in no way an LDAP or OpenLDAP expert, just trying to read man pages. [*] There's an error in my comment there: I wrote "2.4" where it should read "2.4.24".

2 1

Re: Switch OpenLDAP backend database from HDB to MDB
by SHarbich＠t-online.de 11 Jul '19

11 Jul '19

> You can not convert a hdb backend into a mdb backend without changing > the underlying database. slapcat(8) the hdb database into a file and > slapadd(8) the file into a mdb backend. Hello, but it works. I have made the following changes to the config.ldif file. Then I replayed the LDIF file into an empty ldap directory with slapadd: ... olcModuleLoad: {0}back_mdb dn: olcBackend={0}mdb,cn=config olcBackend: {0}mdb dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig ... Thank you in advance for your support

1 0

Re: Switch OpenLDAP backend database from HDB to MDB
by SHarbich＠t-online.de 10 Jul '19

10 Jul '19

Hello, I can not change my config.ldif file from the HDB backend to the MDB backend. I have changed the following: ... dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap -olcModuleLoad: {0}back_hdb +olcModuleLoad: {0}back_mdb olcModuleLoad: {1}dynlist.so olcModuleLoad: {2}ppolicy.la structuralObjectClass: olcModuleList entryUUID: 9495e2a6-da11-1033-97d9-c1ceaf236428 creatorsName: cn=admin,cn=config createTimestamp: 20140926214112Z entryCSN: 20170201184048.317884Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170201184048Z -dn: olcBackend={0}hdb,cn=config +dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig -olcBackend: {0}hdb +olcBackend: {0}mdb structuralObjectClass: olcBackendConfig entryUUID: 94960592-da11-1033-97da-c1ceaf236428 creatorsName: cn=admin,cn=config createTimestamp: 20140926214112Z entryCSN: 20140926214112.940239Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20140926214112Z -dn: olcDatabase={1}hdb,cn=config +dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig -objectClass: olcHdbConfig +objectClass: olcMdbConfig -olcDatabase: {1}hdb +olcDatabase: {1}mdb +olcDbMaxSize: 1073741824 olcDbDirectory: /var/lib/ldap olcSuffix: dc=harnet,dc=de olcLastMod: TRUE olcRootDN: cn=admin,dc=harnet,dc=de olcRootPW:: -olcDbCheckpoint: 512 30 -olcDbConfig: {0}set_cachesize 0 2097152 0 -olcDbConfig: {1}set_lk_max_objects 1500 -olcDbConfig: {2}set_lk_max_locks 1500 -olcDbConfig: {3}set_lk_max_lockers 1500 -structuralObjectClass: olcHdbConfig entryUUID: 94960be6-da11-1033-97db-c1ceaf236428 creatorsName: cn=admin,cn=config createTimestamp: 20140926214112Z olcAccess: {0}to dn.subtree="dc=harnet,dc=de" by dn="uid=lamdaemon,ou=users, dc=harnet,dc=de" write by * none break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to attrs=userPassword by anonymous auth by * none olcAccess: {3}to dn.base="dc=harnet,dc=de" by * read olcAccess: {4}to dn.subtree="ou=users,dc=harnet,dc=de" by dn="cn=Harbich CA Server,ou=services,dc=harnet,dc=de" write by users read by * none olcAccess: {5}to dn.subtree="ou=services,dc=harnet,dc=de" by dn="cn=Harbich CA Server,ou=services,dc=harnet,dc=de" write by users read by * none olcAccess: {6}to * by dn="cn=admin,dc=harnet,dc=de" write by * read olcDbIndex: cn pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: uid pres,eq olcDbIndex: mail pres,eq,sub olcDbIndex: dcMailAlias pres,eq olcDbIndex: givenName pres,eq,sub olcDbIndex: dcSubMailAddress pres,eq olcDbIndex: dcMailAlternateAddress pres,eq olcDbIndex: dcAccountStatus pres,eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: dhcpHWAddress eq olcDbIndex: uniqueMember eq olcDbIndex: memberUid eq olcDbIndex: objectClass eq olcDbIndex: loginShell eq olcDbIndex: sambaSID eq olcDbIndex: sambaPrimaryGroupSID eq olcDbIndex: sambaGroupType eq olcDbIndex: sambaSIDList eq olcDbIndex: sambaDomainName eq olcDbIndex: default sub olcDbIndex: ou pres,eq,sub entryCSN: 20190304162152.376029Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20190304162152Z -dn: olcOverlay={0}dynlist,olcDatabase={1}hdb,cn=config +dn: olcOverlay={0}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {0}dynlist olcDlAttrSet: {0}dcPosixSubAccount dcPosixOwnerURL structuralObjectClass: olcDynamicList entryUUID: 6f6012cc-da16-1033-84a3-8399e4f67731 creatorsName: cn=admin,cn=config createTimestamp: 20140926221557Z entryCSN: 20140926221557.994629Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20140926221557Z ... When I play back the config and data ldif file after deleting the ldap directories, I get the following error message: "root@dsme01:/tmp# slapadd -F /etc/ldap/slapd.d -n 1 -l harnet.de.ldif Database number selected via -n is out of range Must be in the range 0 to 0 (the number of configured databases)" Did I change something wrong in my config file above? Thank you in advance for your support

3 2

Replication persistence
by Nebula WAN 08 Jul '19

08 Jul '19

Hello I have a replication problem between two OpenLDAP 2.44 servers configured as multimasters on CentOS 7.3 : The minimal configuration of both are correct (connection OK with admin credentials), I replicate the config and hdb databases as you can see in the configuration above, I use LDAPAdmin to connect to each of them and check if the replication works by creating a test OU: they replicate well. After a week or more, automatic replication no longer works: I have to restart the slapd service to see the data exchange between the two servers ... I have contextCSN for both but they are fixed at the installation date. Do you have an idea ? Thank you Here are the configuration (the olcServerID change in server2's configuration) : dn: olcDatabase={0}config,cn=config changeType: modify add: olcAccess olcAccess: to * by dn.exact="cn=ldapadm,dc=test,dc=factory" manage by * break dn: olcDatabase={2}hdb,cn=config changeType: modify add: olcAccess olcAccess: to * by dn.exact="cn=ldapadm,dc=test,dc=factory" manage by * break dn: cn=config changetype: modify add: olcServerID olcServerID: 1 dn: olcDatabase={1}monitor,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external, cn=auth" read by dn.base="cn=ldapadm,dc=test,dc=factory" read by * none ### Updating ID ### dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://server1.test.factory olcServerID: 2 ldap://server2.test.factory ### Enabling CONFIG Replication ### dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov ### Configuring CONFIG replication ### dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://server1.test.factory binddn="cn=config" bindmethod=simple credentials=password searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldap://server2.test.factory binddn="cn=config" bindmethod=simple credentials=password searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE ### Enabling HDB Replication ### dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov ### Configuring HDB replication ### dn: olcDatabase={2}hdb,cn=config add: olcSyncRepl olcSyncRepl: rid=004 provider=ldap://server1.test.factory binddn="cn=ldapadm,dc=test,dc=factory" bindmethod=simple credentials=password searchbase="dc=test,dc=factory" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 olcSyncRepl: rid=005 provider=ldap://server2.test.factory binddn="cn=ldapadm,dc=test,dc=factory" bindmethod=simple credentials=password searchbase="dc=test,dc=factory" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 - add: olcDbIndex olcDbIndex: entryUUID eq - add: olcDbIndex olcDbIndex: entryCSN eq - add: olcMirrorMode olcMirrorMode: TRUE

2 1

How to configure OpenLDAP on Debian Stretch to support SSLv3.0
by Jeremy Davis 02 Jul '19

02 Jul '19

Hi all, I'm writing on behalf of a user ragrading how to go about configuring LDAPS support for SSLv3.0 certificate under OpenLDAP v2.4.44 - running on Debian 9/Stretch (default Debian 'slapd' package install). I know that SSLv3.0 is insecure and generally a bad option, but a user needs to connect to LDAPS with an old application that only supports SSLv3.0. I understand that a complicating factor may be that the Debian OpenLDAP (slapd) package is compiled against GnuTLS, rather than OpenSSL. Any insight that might head me in the right direction would be greatly appreciated. Also please note that I'm a bit of an OpenLDAP newb and my knowledge of SSL/TLS is more related to web servers/browsers and more about "best practices" rather than tweaking to be more permissive. Regards, Jeremy Davis TurnKey Linux

3 2

Error when try modify olcTLS*
by Igor Sousa 29 Jun '19

29 Jun '19

Hi everyone, I've tried a common proceeded: insert CA and server certificates on cn=config. I've created CA and server certificate in PEM format and I've signed server certificate with CA certificate. Then I've created a 5tls.ldif with following content: dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/openldap/certs/ldap.local.crt - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.local.key - add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/openldap/certs/ca.cert.pem But server has returned following error when I've ran ldapmodify -Y EXTERNAL -H ldapi:/// -f 5tls.ldif: [root@localhost ldifs]# ldapmodify -Y EXTERNAL -H ldapi:/// -f 5tls.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) ldap.local.crt, ldap.local.key and ca.cert.pem are /etc/openldap/certs and they own read permission to ldap group. I don't understand this behavior and I have no idea what is wrong. OBS: I've mounted environment on CentOS 7, added symas' repository and install from yum. Here some relevant info below. OpenLDAP version - 2.4.47 [root@localhost ldifs]# slapd -V @(#) $OpenLDAP: slapd 2.4.47 (Mar 11 2019 17:22:04) $ build@c7rpm :/home/build/git/rheldap/RHEL7_x86_64/BUILD/symas-openldap-2.4.47/openldap-2.4.47/servers/slapd STATUS after run ldapmodify [root@localhost ldifs]# systemctl status slapd -l ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2019-06-28 01:51:50 -03; 1h 36min ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Process: 4654 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=0/SUCCESS) Process: 4641 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS) Main PID: 4656 (slapd) CGroup: /system.slice/slapd.service └─4656 /usr/sbin/slapd -u ldap -h ldapi:/// ldap:/// Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 fd=11 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 BIND dn="" method=163 Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 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" Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 RESULT tag=97 err=0 text= Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=1 MOD dn="cn=config" Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=1 MOD attr=olcTLSCACertificateFile Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=1 RESULT tag=103 err=80 text= Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=2 UNBIND Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 fd=11 closed Best regards, -- Igor Sousa

2 1

Cluster takes around 48 hours to synchronize after deletion
by x0101 26 Jun '19

26 Jun '19

Dear all, We have an OpenLDAP 2.4 cluster of three nodes configured in multi-master and accessed through a VIP in round-robin. The three machines run RHEL7. We noticed that deletion of an entry (done from a Windows machine onto the first node via Oracle's tool ldapmodify.exe) takes a long time (about 48 hours) to be replicated in the cluster. Here's the relevant extract of cn=config for the first node: olcSyncrepl: {0}rid=001 provider=ldap://mynode2:389/ bindmethod=simple binddn="cn=Replicator,dc=mydomain,dc=org" credentials=1234567890 searchbase="dc=mydomain,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 +" keepalive="60:5:10" olcSyncrepl: {1}rid=002 provider=ldap://mynode3:389/ bindmethod=simple binddn="cn=Replicator,dc=mydomain,dc=org" credentials=1234567890 searchbase="dc=mydomain,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 +" keepalive="60:5:10" olcMirrorMode: TRUE We looked up for the offending entry (thisentry) in all nodes' logs and we found this line on mynode3: Jun 18 14:18:20 mynode3 slapd[8871]: conn=1987936 op=14 DEL dn="dc=thisentry,ou=myou,ou=foobars,dc=mydomain,dc=org" There are no other references to thisentry (apart from SRCH operations) on node1 and node2, even if the entry was originally deleted from node1, as said above. What could be the cause and what could we do to further troubleshoot the issue? Thanks in advance.

2 1

debug incoming modify operations
by Mark Coetser 25 Jun '19

25 Jun '19

Hi changing my loglevel to trace or stats, shows me search queries but I need a way to debug a remote client doing a php ldap modify that is failing? -- Thank you, Mark Adrian Coetser mark(a)pkfnet.co.za

4 7

Invalid DN reported during authentication
by Chris K 25 Jun '19

25 Jun '19

Hello experts, I setup an openLDAP server some time ago and am to create a newer server for TLS 1.3 support. I am using a fully patched CentOS 7 server with OpenLDAP 2.4.44 and am seeing 'invalid DN' when authenticating to the server from my Linux client. I will attempt to supply all the config and tests I have done thus far: ######################################## ldap.conf: # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net URI ldap://openldapsec.brm.acslab.wokyourdog.net #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLSCipherSuite HIGH:MEDIUM:+TLSv1:!SSLv2:+SSLv3 TLS_CACERTDIR /etc/openldap/certs TLS_CACERT /etc/openldap/certs/RootCA.pem TLSCACertificateFile /etc/openldap/certs/RootCA.pem TLSCertificateFile /etc/openldap/certs/Identity.pem TLSCertificateKeyFile /etc/openldap/certs/Identity.key TLSVerifyClient never # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on ######################################## slapd.conf # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema # Added for policy include /etc/openldap/schema/ppolicy.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args moduleload ppolicy.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. TLSCACertificateFile /etc/openldap/certs/RootCA.pem TLSCertificateFile /etc/openldap/certs/Identity.pem TLSCertificateKeyFile /etc/openldap/certs/Identity.key database bdb suffix "dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" rootdn "cn=root,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" rootpw {SSHA}C6RcppHr0rweEVCQW6pio6tnPCIHCGnt # PPolicy Configuration overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" ppolicy_use_lockout ppolicy_hash_cleartext # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub ######################################## ldapsearch output: [root@OpenLDAP_Server openldap]# ldapsearch -H ldap:// openldapsec.brm.acslab.wokyourdog.net -D "cn=root,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" -w Siladmin123 -ZZ # extended LDIF # # LDAPv3 # base <dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # openldapsec.brm.acslab.wokyourdog.net dn: dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net dc: openldapsec objectClass: top objectClass: domain # people, openldapsec.brm.acslab.wokyourdog.net dn: ou=people,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net objectClass: top objectClass: organizationalUnit ou: people # swadmin3, openldapsec.brm.acslab.wokyourdog.net dn: cn=swadmin3,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net objectClass: person objectClass: uidObject cn: swadmin3 sn: admin user uid: swadmin3 userPassword:: e1NTSEF9WDdRQ2xzallYUDUvWU9sZnJyc3ZWVXhnS0xkbXB2U1o= # search result search: 3 result: 0 Success # numResponses: 4 # numEntries: 3 ######################################## ldapwhoami [root@OpenLDAP_Server openldap]# ldapwhoami -vvv -h openldapsec.brm.acslab.wokyourdog.net -p 389 -D "cn=swadmin3,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" -x -w Siladmin123 ldap_initialize( ldap://openldapsec.brm.acslab.wokyourdog.net:389 ) dn:cn=swadmin3,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net Result: Success (0) ######################################## client authentication failure logs ber_dump: buf=0x7fe684117870 ptr=0x7fe684117870 end=0x7fe68411788d len=29 0000: 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 ...w...1.3.6.1.4 0010: 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .1.1466.20037 ber_dump: buf=0x7fe684117870 ptr=0x7fe684117873 end=0x7fe68411788d len=26 0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1. 0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ber_dump: buf=0x7fe684115be0 ptr=0x7fe684115be0 end=0x7fe684115c23 len=67 0000: 02 01 02 60 3e 02 01 03 04 2c 73 77 61 64 6d 69 ...`>....,swadmi 0010: 6e 33 40 6f 70 65 6e 6c 64 61 70 73 65 63 2e 62 n3(a)openldapsec.b 0020: 72 6d 2e 62 73 6e 6c 61 62 2e 62 72 6f 61 64 63 rm.acslab.wokyou 0030: 6f 6d 2e 6e 65 74 80 0b 53 69 6c 61 64 6d 69 6e rdog.net..Siladmin 0040: 31 32 33 123 ber_dump: buf=0x7fe684115be0 ptr=0x7fe684115be3 end=0x7fe684115c23 len=64 0000: 60 3e 02 01 03 04 2c 73 77 61 64 6d 69 6e 33 40 `>....,swadmin3@ 0010: 6f 70 65 6e 6c 64 61 70 73 65 63 2e 62 72 6d 2e openldapsec.brm. 0020: 62 73 6e 6c 61 62 2e 62 72 6f 61 64 63 6f 6d 2e acslab.wokyourdog. 0030: 6e 65 74 80 0b 53 69 6c 61 64 6d 69 6e 31 32 33 net..Siladmin123 ber_dump: buf=0x7fe684115be0 ptr=0x7fe684115c16 end=0x7fe684115c23 len=13 0000: 00 0b 53 69 6c 61 64 6d 69 6e 31 32 33 ..Siladmin123 5d10d347 conn=1048 op=1 do_bind: invalid dn ( swadmin3(a)openldapsec.brm.acslab.wokyourdog.net) 0000: 30 16 02 01 02 61 11 0a 01 22 04 00 04 0a 69 6e 0....a..."....in 0010: 76 61 6c 69 64 20 44 4e valid DN ber_dump: buf=0x7fe6841171a0 ptr=0x7fe6841171a0 end=0x7fe6841171a5 len=5 0000: 02 01 03 42 00 ...B. ber_dump: buf=0x7fe684107eb0 ptr=0x7fe684107eb0 end=0x7fe684107ecd len=29 0000: 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 ...w...1.3.6.1.4 0010: 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .1.1466.20037 ber_dump: buf=0x7fe684107eb0 ptr=0x7fe684107eb3 end=0x7fe684107ecd len=26 0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1. 0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ber_dump: buf=0x7fe684002250 ptr=0x7fe684002250 end=0x7fe6840022ae len=94 0000: 02 01 02 60 59 02 01 03 04 47 63 6e 3d 73 77 61 ...`Y....Gcn=swa 0010: 64 6d 69 6e 33 2c 63 6e 3d 75 73 65 72 73 2c 64 dmin3,cn=users,d 0020: 63 3d 6f 70 65 6e 6c 64 61 70 73 65 63 2c 64 63 c=openldapsec,dc 0030: 3d 62 72 6d 2c 64 63 3d 62 73 6e 6c 61 62 2c 64 =brm,dc=acslab,d 0040: 63 3d 62 72 6f 61 64 63 6f 6d 2c 64 63 3d 6e 65 c=wokyourdog,dc=ne 0050: 74 80 0b 53 69 6c 61 64 6d 69 6e 31 32 33 t..Siladmin123 ber_dump: buf=0x7fe684002250 ptr=0x7fe684002253 end=0x7fe6840022ae len=91 0000: 60 59 02 01 03 04 47 63 6e 3d 73 77 61 64 6d 69 `Y....Gcn=swadmi 0010: 6e 33 2c 63 6e 3d 75 73 65 72 73 2c 64 63 3d 6f n3,cn=users,dc=o 0020: 70 65 6e 6c 64 61 70 73 65 63 2c 64 63 3d 62 72 penldapsec,dc=br 0030: 6d 2c 64 63 3d 62 73 6e 6c 61 62 2c 64 63 3d 62 m,dc=acslab,dc=w 0040: 72 6f 61 64 63 6f 6d 2c 64 63 3d 6e 65 74 80 0b kyourdog,dc=net.. 0050: 53 69 6c 61 64 6d 69 6e 31 32 33 Siladmin123 ber_dump: buf=0x7fe684002250 ptr=0x7fe6840022a1 end=0x7fe6840022ae len=13 0000: 00 0b 53 69 6c 61 64 6d 69 6e 31 32 33 ..Siladmin123 0000: 30 0c 02 01 02 61 07 0a 01 31 04 00 04 00 0....a...1.... ber_dump: buf=0x7fe684118dd0 ptr=0x7fe684118dd0 end=0x7fe684118dd5 len=5 0000: 02 01 03 42 00 ...B. Please let me know if you can see my mis-configuration or if you have any questions about my setup. Thanks, Chris

2 1

Hide pwdHistory field from anonymous
by Kyle Sloan 21 Jun '19

21 Jun '19

I am able to hide the userPassword and any other single/unique fields on a query, but I cannot figure out the pwdHistory and how to disable it from anonymous queries. I keep getting syntax errors and am unsure what the syntax is. This works for userPassword, but fails when I replace or add pwdHistory access to attrs=userPassword by self write by anonymous auth by * none Here is what my my query looks like /usr/bin/ldapsearch -h 1.2.3.4 -x -b 'ou=People,dc=company,dc=com' '(uid=myuser)' '*' '+' # extended LDIF # # LDAPv3 # base <ou=People,dc=copmany,dc=com> with scope subtree # filter: (uid=myuser) # requesting: * + # # myuser, People, company dn: uid=myuser,ou=People,dc=company,dc=com uidNumber: 31518 gidNumber: 100 shadowExpire: 99999 shadowMax: 90 objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount uid: myuser pwdHistory: 20180718212202Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}bTWu9btdOzp pwdHistory: 20181015214815Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}Ys8LvXcdnsr pwdHistory: 20181016164512Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}nQLIieWGwt7 pwdHistory: 20190114155333Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}j3d+hxGalnC pwdHistory: 20190412183313Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}7r2E2DdryKa pwdHistory: 20190412185409Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}ZbqMWB0x4v+

3 4

How to filter all entries by multi-value attributes?
by Tankman 六四 21 Jun '19

21 Jun '19

Hi everyone Is there a way to find all people whose telephoneNumber is multi-valued through the use of LDAP filter? Searched around there are only ways to search into multiple values but not based on the number of values. Thanks:) Regards

2 1

LDAP with TLS Enable/Disable not working
by Sunkad, Abhilash 21 Jun '19

21 Jun '19

Hi All, I am facing a strange problem. I am using FreeRadius 3.16 version for my Proxy authentication. I have an AD server and I make an authentication request enabling TLS. So the TLS connection passes and authentication is successful. Now I have one more LDAP server where its non TLS. Now if I make a call, even though TLS is disabled on this server, Client tries to make a TLS connection and fails. I have tried freeing connections but with no luck. Please help. Thanks Abhilash

2 1

Re: Extensible filters and ordering searches: filtering shadowExpire by range?
by Côme Chilliet 19 Jun '19

19 Jun '19

Le mardi 18 juin 2019, 12:36:56 CEST Quanah Gibson-Mount a écrit : > > So, there is no way to filter on shadowExpire values which are less than > > today's timestamp? > > shadowExpire is defined as an integer type, not as a timestamp, so no. > > > It sounds crazy that such basic needs are not covered by LDAP protocol, > > have I missed something? > > It's not clear to me what this has to do with the LDAP protocol. The > definition of the "expire" field from /etc/shadow is: > > Expire : days since Jan 1, 1970 that account is disabled i.e. an absolute > date specifying when the login may no longer be used. > > So it's an integer (just as the RFC defines it). I would imagine you could > write something that converts a current timestamp into the number of days, > etc, and then perform a search. Yeah this is what I was calling timestamp sorry, getting the integer for today is easy, but it seems there is no way for writing a search filter with greater-than or lesser-than for this attribute. It has to do with the LDAP protocol that LDAP lets schema define attributes in ways that forbid substring and range filters. We should be able to use extensible filters for these, and specify which ordering or substring rule we want to see used. And if attributes using integer syntax were to default to integerOrdering when not specified, that would seem more sane. Côme

2 1

Extensible filters and substring searches
by Côme Chilliet 18 Jun '19

18 Jun '19

Hello, I’m trying to understand if it is possible or not to do a substring search on an attribute which does not specify a substring matching rule. I was expecting to be able to use an extensible filter and specify the sub matching rule to use, but it does not seem to work ldapsearch says "ldap_search_ext: Bad search filter (-7)" as soon as the filter contains an asterisk. And indeed reading https://tools.ietf.org/html/rfc4515 it does look like extensible filter does not allow asterisk, but it is surprising to me. Is there really no way to do an extensible search on a substring? I found some examples on the web of such filters, like here: http://www.zytrax.com/books/ldap/apa/search.html They give these examples: > # override SUBSTR match with case sensitive match > sn:caseExactSubstringMatch:=*S* # only finds Smith > # functionally same as above using OID > sn:2.5.13.7:=*S* But these do not work if I try them in ldapsearch I get bad search filter. Côme

3 7

Uniqueness across multiple attributes
by Stefan Schmidt 17 Jun '19

17 Jun '19

Hello, is it possible define a unique constraint across attributes? We have a mail field and a mailAlias field and would like to assure that if a mail address exists either in mail or mailAlias it cannot be added again to either field, meaning mail addresses are unique in the complete tree. We are using OpenLDAP 2.4 and currently we use the following LDIF to load the unique module and assure that the mail attribute is unique: dn: cn=module,cn=config cn: module objectclass: olcModuleList objectclass: top olcmoduleload: unique olcmodulepath: /usr/lib/ldap dn: olcOverlay=unique,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: {0}unique olcUniqueAttribute: mail Which LDIF would I use to assure uniqueness across mail and mailAlias? Cheers, Stefan Schmidt

4 5

Re: No olcBackend module loaded.
by Igor Sousa 14 Jun '19

14 Jun '19

Hi Quanah, Thank you for your answer. My boss has asked me for a tutorial due our new installation that we'll do. Then we'll update our production environment to latest version of distribution and openldap. I've used, in my test, hdb backend because I've used default installation from yum package management. Then I'll change it to mdb in my tutorial and new installation. (I've seen, after you explanation, that OpenLDAP documentation says hdb is deprecated.) About "olcBackend", I've understand, after your explanation, that is normal it there isn't in CentOS. Best regards and thank you so much, -- Igor Sousa

2 2

How to correctly import schemas?
by Jens Bürger 13 Jun '19

13 Jun '19

Dear people of OpenLDAP, I have a Univention Corporate Server (UCS) running at a local site, with a well-populated LDAP. I have a VM on the Internet, providing some web services. I’d like to just clone the LDAP data from the local UCS machine to the VM regularly. While copying the database is a no-brainer (scp & ssh-key), I currently fail at importing the UCS-specific LDAP schemas into the LDAP of the VM. The schema conversion created a {0}core.ldif as starting point. Importing this into openldap failed because I have not the right to modification to core (of course). Any hints? Kind regards, Jens

4 9

authentication failure
by Adam Weremczuk 12 Jun '19

12 Jun '19

Hi all, I'm trying to make pfSense talk to Samba AD LDAP through "bind credentials to resolve distinguished names" option. I have 2 accounts which, as far as I can tell, look identical from AD perspective. One of them successfully connects (Samba logs): [2019/06/12 14:34:41.517364, 3] ../lib/ldb-samba/ldb_wrap.c:325(ldb_wrap_connect) ldb_wrap open of secrets.ldb [2019/06/12 14:34:41.520731, 3] ../source4/auth/ntlm/auth.c:271(auth_check_password_send) auth_check_password_send: Checking password for unmapped user [MATRIX_SCIENCE]\[account1]@[(null)] auth_check_password_send: mapped user is: [MATRIX_SCIENCE]\[account1]@[(null)] [2019/06/12 14:34:41.521510, 4] ../source4/auth/sam.c:183(authsam_account_ok) authsam_account_ok: Checking SMB password for user account1 The other one fails: [2019/06/12 15:09:56.215000, 3] ../lib/ldb-samba/ldb_wrap.c:325(ldb_wrap_connect) ldb_wrap open of secrets.ldb [2019/06/12 15:09:56.217871, 3] ../source4/smbd/service_stream.c:66(stream_terminate_connection) Terminating connection - 'ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' [2019/06/12 15:09:56.217941, 3] ../source4/smbd/process_single.c:114(single_terminate) single_terminate: reason[ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED] Any idea what the second account is missing? The difference must be restricted to what's replicated between domain controllers as the behavior is identical against the primary and secondary one. Thanks, Adam

1 0

No olcBackend module loaded.
by Igor Sousa 11 Jun '19

11 Jun '19

Hi everyone, I've been creating a tutorial for my company for documented "How to install and configure OpenLDAP" for our needs. Currently, we've had a OpenLDAP server on Debian 8 and OpenLDAP 2.4.40 on the production server. My boss has asked me for a tutorial of OpenLDAP on CentOS7. I've agreed with him (distribution is only a shell to Kernel Linux). Them I've created a tutorial for this request, BUT I've noticed a strange thing before enable memberOf module: my new installations doesn't have any module loaded, including backend module. Then, my questions are: 1 - Is this a normal? 2 - How to enable back_hdb module? OBS1: I've installed from package management YUM: *yum install openldap*. OBS2: Database of new installations is hdb. -- Igor Sousa

2 1

Replication issues with delta-syncrepl, MMR and memberOf overlay on 2.4.47
by Mark Cairney 06 Jun '19

06 Jun '19

Hi, We currently run a multi-master setup where all 4 of our servers replicate from each other via delta-syncrepl but all our writes are directed at a selected "master" server. I've noticed recently that we are suffering sync issues and this coincides with us upgrading from 2.4.46 with a patch for ITS8843 to 2.4.47. On a "consumer" I'm seeing log entries like this: Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_graduate_commit _csn: removing 0xa1da880 20190605063503.192377Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_ op: rid=034 be_modify cn=STUUG,ou=affiliations,ou=grouper2,dc=authorise,dc=ed,dc =ac,dc=uk (0) Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_queue_csn: queu eing 0x1e963c40 20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_ op: rid=035 tid b7ae2700 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=034 cookie=rid=034,sid=003,csn=20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_null_callba ck : error code 0x14 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_graduate_commit_csn: removing 0x1e963c40 20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_op: rid=035 be_modify cn=PRPHDOPMIH3F_3,ou=PRPHDOPMIH3F,ou=pos,ou=grouper2,dc=authorise,dc=ed,dc=ac,dc=uk (20) Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=035 delta-sync lost sync on (reqStart=20190605063503.000020Z,cn=accesslog), switching to REFRESH Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_queue_csn: queueing 0x1d0f8100 20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_op: rid=034 tid bacef700 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_null_callback : error code 0x14 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_graduate_commit_csn: removing 0x1d0f8100 20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_op: rid=034 be_modify cn=PRPHDOPMIH3F_3,ou=PRPHDOPMIH3F,ou=pos,ou=grouper2,dc=authorise,dc=ed,dc=ac,dc=uk (20) Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=034 delta-sync lost sync on (reqStart=20190605063503.000414Z,cn=accesslog), switching to REFRESH Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_queue_csn: queueing 0x1b5c87c0 20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_op: rid=036 tid b62df700 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_null_callback : error code 0x14 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_graduate_commit_csn: removing 0x1b5c87c0 20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_op: rid=036 be_modify cn=PRPHDOPMIH3F_3,ou=PRPHDOPMIH3F,ou=pos,ou=grouper2,dc=authorise,dc=ed,dc=ac,dc=uk (20) Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=036 delta-sync lost sync on (reqStart=20190605063503.000361Z,cn=accesslog), switching to REFRESH Then a number of SYNC_ID_SET messages: Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=035 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=034 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=036 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=035 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=034 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=036 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=035 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Before finally a whole bunch of: Jun 5 07:35:20 cauth04.authorise.is.ed.ac.uk slapd[18267]: nonpresent_callback: rid=035 present UUID 8573adfa-71c7-4a9c-ab64-54d6c7f51e25, dn dc=authorise,dc=ed,dc=ac,dc=uk Jun 5 07:35:20 cauth04.authorise.is.ed.ac.uk slapd[18267]: nonpresent_callback: rid=035 present UUID 555bdc68-06ee-443c-9b33-6c8355c0a00d, dn ou=is,dc=authorise,dc=ed,dc=ac,dc=uk Jun 5 07:35:20 cauth04.authorise.is.ed.ac.uk slapd[18267]: nonpresent_callback: rid=035 present UUID 8749c8a0-0b06-4dc0-b1bd-ca85f3077603, dn ou=hss,dc=authorise,dc=ed,dc=ac,dc=uk Jun 5 07:35:20 cauth04.authorise.is.ed.ac.uk slapd[18267]: nonpresent_callback: rid=035 present UUID 5d59b0fd-68f1-44b7-a2af-f4aec00c7857, dn ou=mvm,dc=authorise,dc=ed,dc=ac,dc=uk Jun 5 07:35:20 cauth04.authorise.is.ed.ac.uk slapd[18267]: nonpresent_callback: rid=035 present UUID d75a41f2-a279-4cf2-a8e6-033c6821b6b2, dn ou=sce,dc=authorise,dc=ed,dc=ac,dc=uk (At which point CPU usage on journald and rsyslog understandably go through the roof). There is a (possibly self-inflicted) point of pain where we have an exattrs=memberOf in our syncrepl config to work around another replication issue so this means that any user objects which are REFRESH'ed end up losing all their group memberships. I'm mitigating this at present by periodically dumping the data from the "master" and re-generating the databases on the "consumers" but this is more of a sticking plaster approach. Are there any known bugs/ regressions with delta-syncrepl in 2.4.47? One idea I've had is to go to a true single-master config by setting the current consumers to be read-only and having a single olcSyncrepl clause for the master on these 3 servers. My config from one of the consumers is listed below although the master config is identical bar the olcSyncrepl lines and olcSaslHost value. I've redacted the schema and olcAccess entries and the root password: If there's any obvious deficiencies in my config too that would be good to know. Kind regards, Mark dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: slapd.conf olcConfigDir: slapd.d olcArgsFile: /opt/openldap/var/run/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcAuthzRegexp: {0}"^uid=([^,/@]+)/ldapauth(@(((TEST\.)?EASE)|INF).ED.AC.UK)?,cn=(((TEST\.)?EASE)|INF).ED.AC.UK,cn=GSSAPI,cn=auth$" "uid=$1,ou=people,ou=central,dc=authorise,dc=ed,dc=ac,dc=uk" olcAuthzRegexp: {1}"^uid=(host|ldap)/([^/]+).authorise.is.ed.ac.uk,cn=EASE.ED.AC.UK,cn=GSSAPI,cn=auth$" "uid=replicator.authorise.is.ed.ac.uk,ou=people,ou=central,dc=authorise,dc=ed,dc=ac,dc=uk" olcAuthzRegexp: {2}"^uid=([^,/@]+)(@(((TEST\.)?EASE)|INF).ED.AC.UK)?,cn=(((TEST\.)?EASE)|INF).ED.AC.UK,cn=GSSAPI,cn=auth$" "uid=$1,ou=people,ou=central,dc=authorise,dc=ed,dc=ac,dc=uk" olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 71 olcLogFile: /opt/openldap/var/log/openldap-debug.log olcLogLevel: stats olcLogLevel: sync olcPidFile: /opt/openldap/var/run/slapd.pid olcReadOnly: FALSE olcSaslHost: cauth04.authorise.is.ed.ac.uk olcSaslRealm: EASE.ED.AC.UK olcSaslSecProps: noplain,noanonymous olcSecurity: ssf=1 olcSecurity: update_ssf=112 olcSecurity: simple_bind=64 olcServerID: 3 ldaps://cauth01.authorise.is.ed.ac.uk/ olcServerID: 4 ldaps://cauth02.authorise.is.ed.ac.uk/ olcServerID: 5 ldaps://cauth03.authorise.is.ed.ac.uk/ olcServerID: 6 ldaps://cauth04.authorise.is.ed.ac.uk/ olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 12 olcTLSCACertificateFile: /opt/openldap/certs/quovadis.bundle olcTLSCertificateFile: /opt/openldap/certs/authorise.is.ed.ac.uk-QUOVADIS.crt olcTLSCertificateKeyFile: /opt/openldap/certs/authorise.is.ed.ac.uk-QUOVADIS.key olcTLSCipherSuite: HIGH:MEDIUM:+SSLv3:+SSLv2:+TLSv1:+AES256-SHA:!EXPORT olcTLSCRLCheck: none olcTLSVerifyClient: never olcTLSProtocolMin: 3.1 olcToolThreads: 2 olcWriteTimeout: 900 dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 2 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSecurity: ssf=1 olcSecurity: update_ssf=112 olcSecurity: simple_bind=64 olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcSortVals: member olcSortVals: eduniServiceCode dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.regex="^uid=replicator\.authorise\.is\.ed\.ac\.uk,ou=people,ou=central,dc=authorise,dc=ed,dc=ac,dc=uk$" read by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,cn=config olcRootPW:: ************************* olcSyncUseSubentry: FALSE olcMonitoring: FALSE dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /opt/openldap/var/openldap-data/authorise olcSuffix: dc=authorise,dc=ed,dc=ac,dc=uk olcAccess: ************* olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 1 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=authorise,dc=ed,dc=ac,dc=uk olcRootPW:: ********************* olcSecurity: ssf=1 olcSecurity: update_ssf=112 olcSecurity: simple_bind=64 olcSizeLimit: unlimited olcSyncUseSubentry: FALSE olcTimeLimit: unlimited olcMirrorMode: TRUE olcMonitoring: TRUE olcDbCheckpoint: 1024 10 olcDbEnvFlags: writemap olcDbEnvFlags: nometasync olcDbNoSync: FALSE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: eduniType eq olcDbIndex: gecos pres,eq,sub olcDbIndex: eduniCategory eq olcDbIndex: mail pres,eq,sub olcDbIndex: eduniSchoolCode eq olcDbIndex: eduniIDStatus eq olcDbIndex: eduniCollegeCode eq olcDbIndex: eduniUnitCode eq olcDbIndex: eduniOrgCode eq olcDbIndex: eduniLibraryBarcode pres,eq olcDbIndex: eduniServiceCode pres,eq olcDbIndex: krbName pres,eq olcDbIndex: eduPersonAffiliation pres,eq olcDbIndex: eduPersonPrimaryAffiliation eq olcDbIndex: eduPersonPrincipalName eq olcDbIndex: eduPersonEntitlement pres,eq olcDbIndex: eduPersonTargetedID eq olcDbIndex: eduPersonScopedAffiliation pres,eq olcDbIndex: userPassword eq olcDbIndex: eduniIdmsId pres,eq olcDbIndex: sn pres,eq,sub olcDbIndex: memberUid eq olcDbIndex: uniqueMember pres,eq olcDbIndex: autoMountKey eq olcDbIndex: eduniOrganisation pres,eq,sub olcDbIndex: description pres,eq,sub olcDbIndex: eduniTitle pres,eq olcDbIndex: title pres,eq,sub olcDbIndex: eduniCardNumber pres,eq olcDbIndex: eduniRefNo pres,eq olcDbIndex: givenName pres,eq,sub olcDbIndex: member eq olcDbIndex: eduniYearOfStudy pres,eq olcDbIndex: yubiKeyId pres,eq olcDbIndex: nisMapName eq olcDbIndex: memberOf eq olcDbIndex: proxyAddresses pres,eq,sub olcDbMaxReaders: 96 olcDbMaxSize: 32212254720 olcDbMode: 0600 olcDbSearchStack: 16 olcSyncrepl: {0}rid=34 provider=ldaps://cauth01.authorise.is.ed.ac.uk/ realm=EASE.ED.AC.UK bindmethod=sasl saslmech=gssapi authcid="replicator.authorise.is.ed.ac.uk(a)EASE.ED.AC.UK" searchbase="dc=authorise,dc=ed,dc=ac,dc=uk" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" tls_reqcert=never timeout=1 keepalive=300:12:5 syncdata=accesslog exattrs="memberOf" olcSyncrepl: {1}rid=35 provider=ldaps://cauth02.authorise.is.ed.ac.uk/ realm=EASE.ED.AC.UK bindmethod=sasl saslmech=gssapi authcid="replicator.authorise.is.ed.ac.uk(a)EASE.ED.AC.UK" searchbase="dc=authorise,dc=ed,dc=ac,dc=uk" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" tls_reqcert=never timeout=1 keepalive=300:12:5 syncdata=accesslog exattrs="memberOf" olcSyncrepl: {2}rid=36 provider=ldaps://cauth03.authorise.is.ed.ac.uk/ realm=EASE.ED.AC.UK bindmethod=sasl saslmech=gssapi authcid="replicator.authorise.is.ed.ac.uk(a)EASE.ED.AC.UK" searchbase="dc=authorise,dc=ed,dc=ac,dc=uk" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" tls_reqcert=never timeout=1 keepalive=300:12:5 syncdata=accesslog exattrs="memberOf" entryCSN: 20190528133331.277387Z#000000#006#000000 dn: olcOverlay={0}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {0}dynlist olcDlAttrSet: {0}groupOfURLs memberURL dn: olcOverlay={1}memberof,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {1}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf dn: olcOverlay={2}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {2}syncprov dn: olcOverlay={3}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {3}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 02+00:00 00+04:00 olcAccessLogSuccess: TRUE dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /opt/openldap/var/openldap-data/accesslog olcSuffix: cn=accesslog olcAccess: {0}to * by dn.exact="uid=replicator.authorise.is.ed.ac.uk,ou=people,ou=central,dc=authorise,dc=ed,dc=ac,dc=uk" write by dn="cn=Manager,dc=authorise,dc=ed,dc=ac,dc=uk" write olcLimits: {0}dn.exact="uid=replicator.authorise.is.ed.ac.uk,ou=people,ou=central,dc=authorise,dc=ed,dc=ac,dc=uk" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited olcLimits: {1}dn.exact="cn=Manager,dc=authorise,dc=ed,dc=ac,dc=uk" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited olcRootDN: cn=Manager,cn=accesslog olcRootPW:: ******************************** olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart,reqDN olcDbMaxReaders: 96 olcDbMaxSize: 32212254720 olcDbMode: 0600 olcDbSearchStack: 16 dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcDatabase={3}monitor,cn=config objectClass: olcMonitorConfig objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcDatabase: {3}monitor olcAccess: {0}to dn.subtree="cn=monitor" by dn.exact="cn=Manager,cn=config" write by * none -- /**************************** Mark Cairney ITI Enterprise Services Information Services University of Edinburgh Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk PGP: 0x435A9621 *******************************/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

4 6

Re: Adding an Entry Outside the DIT
by A. Yuesuen 06 Jun '19

06 Jun '19

I believe it is outside from the main DIT because the differents suffix. and i saw this documentation: https://wiki.zimbra.com/wiki/Zimbra_Directory_Service_(LDAP) at the second Picture there are two DIT. I solved my problem by building a second Database with the wanted Suffix by adding this ldif: dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/<NEWDIR> olcSuffix: <new root DN> olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=Manager,<new root DN>" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=Manager,dc=<new root DN>" write by * read olcLastMod: TRUE olcRootDN: cn=Manager,<new root DN> olcRootPW: <manager password> Am Mi., 5. Juni 2019 um 19:32 Uhr schrieb Quanah Gibson-Mount < quanah(a)symas.com>: > --On Wednesday, June 05, 2019 10:18 AM +0200 "A. Yuesuen" > <ayuesuen93(a)gmail.com> wrote: > > > I have to work with a Shadow Server of my Company Ldap Server. And they > > are using for the authentication the Entry with the DN > > uid=zimbra,cn=admins,cn=zimbra but have the Suffic dn: dc=company,dc=com. > > How i can add a User with the dn uid=zimbra,cn=admins,cn=zimbra when > > the suffix ends with dn: dc=company,dc=com. > > > > Is there a way to add a Entry outside the DIT? > > What makes you believe it is outside of the DIT? Zimbra deployments use > "" > as the suffix for the database. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

2 1

LDIF import fails
by Adam Weremczuk 05 Jun '19

05 Jun '19

Hi all, I exported from LDAP version 2.4.31 (samba AD 4.0.9) as below: C:\Windows\system32>ldifde -f export.ldf -s samba.matrixscience.co.uk Connecting to "samba.matrixscience.co.uk" Logging in as current user using SSPI Exporting directory to file export.ldf Searching for entries... Writing out entries............................................................. ................................................................................ ................................................................................ ................................................................................ ................................................................................ ........................................................................ 453 entries exported The command has completed successfully When I import to 2.4.44 through php LDAP admin logging in as cn=admin,dc=matrixscience,dc=co,dc=uk the import fails on every line. It's full of 0x11 and 0x15 errors. 2 examples below: Could not add the object to the LDAP server. LDAP said: Undefined attribute type Error number: 0x11 (LDAP_UNDEFINED_TYPE) Description: The attribute type specified is invalid. LDIF text import Could not add object cn=testuser,CN=Users,DC=matrixscience,DC=co,DC=uk LDAP said: Undefined attribute type Error number: 0x11 (LDAP_UNDEFINED_TYPE) Description: The attribute type specified is invalid. Could not add the object to the LDAP server. LDAP said: Invalid syntax Error number: 0x15 (LDAP_INVALID_SYNTAX) Description: An invalid attribute value was specified. LDIF text import Could not add object cn=Domain Controllers,CN=Users,DC=matrixscience,DC=co,DC=uk LDAP said: Invalid syntax Error number: 0x15 (LDAP_INVALID_SYNTAX) Description: An invalid attribute value was specified. Am I doing something fundamentally wrong? Regards, Adam Weremczuk

2 1

Adding an Entry Outside the DIT
by A. Yuesuen 05 Jun '19

05 Jun '19

Hello, I have to work with a Shadow Server of my Company Ldap Server. And they are using for the authentication the Entry with the DN uid=zimbra,cn=admins,cn=zimbra but have the Suffic dn: dc=company,dc=com. How i can add a User with the dn uid=zimbra,cn=admins,cn=zimbra when the suffix ends with dn: dc=company,dc=com. Is there a way to add a Entry outside the DIT? best wishes Ajdar

2 1

SHA-2 and other hashes
by Norman Gray 04 Jun '19

04 Jun '19

Greetings. I've been doing some reading on password hashes, in OpenLDAP and elsewhere. It's slightly harder to find explicit details about this, than I expected, and some of what I learned was unexpected to me, though probably familiar to many on this list. In the expectation I'm not the only naive one, I'd like to log these on-list, with a broad query about whether I'm understanding things correctly. There are very good discussions at [1] and [2]. SHA-256/SHA-512 on OpenLDAP doesn't mean the same as what is nominally the same hash function in glibc. In OpenLDAP, the MD5 and SHA-whatever hash of a password is the result of hashing the password plus salt -- ie, pretty much what I expected -- but in glibc's crypt(3), the $5$ and $6$ hashes are the result of an unspecified number of rounds of such hashing (the $1$/MD5 glibc hash does appear to be compatible with OpenLDAP {SMD5}, though). (Quite possibly everyone else in the world already knew this, but I didn't!) While the glibc $5$ and $6$ hashes are therefore, in principle, somewhat resistant to brute-forcing, the OpenLDAP ones are not, and so should be managed as confidential data. MD5 _isn't_ significantly worse than plain SHA-whatever for password hashing, since its discovered defects with respect to collisions are not a problem for this application (it's still resistant to 'preimages'). However both are unsafe for secure password storage, simply because they're too fast (by design), and MD5 is unusable simply because 'everyone knows MD5 is broken', so it would require tedious explanation. Thus it would seem that the SHA-2 support optionally available in the OpenLDAP distribution (in contrib/slapd-modules/passwd/sha2) doesn't actually benefit me much, over and above the MD5 and SHA-1 support available by default. However PBKDF2 (available in contrib/slapd-modules/passwd/pbkdf2) would be usable immediately, though this appears to be not the best such function available. So the two options for password storage seem to be * use {SSHA} and -- as [3] stresses -- protect password attributes as if they were clear text; or * one way or another use a hash-stretching algorithm such as bcrypt (though [4] -- *sigh*) or scrypt [5] (maybe the best option?) or PBKDF2 * (and don't worry about having to protect password attributes?). Is that about right? Is there a consensus OpenLDAP best practice here? Best wishes, Norman [1] https://crackstation.net/hashing-security.htm [2] https://security.stackexchange.com/questions/211/how-to-securely-hash-passw… [3] https://openldap.org/doc/admin24/security.html [4] https://github.com/wclarie/openldap-bcrypt/issues/1 [5] https://github.com/Tarsnap/scrypt -- Norman Gray : https://nxg.me.uk

5 7

Help need with replication
by John C. Pfeifer 04 Jun '19

04 Jun '19

I am setting up a new OpenLDAP (2.4.47) cluster to migrate to from another LDAP product. I am having problems with delta-syncrepl multi-master mirror mode replication. It seems to be fine for a while and then something happens where some of the consumers start having the dreaded “CSN too old” errors. My understanding from the docs is that this ought to get resolved automatically by syncing the whole object…but that never happens. In my testing environment, there are two producers and two read-only consumers. In a recent example, two changes to the same object in within one minute (both change were mad against the same producer. From cn=accesslog (slightly redacted): dn: reqStart=20190520190341.000001Z,cn=accesslog objectclass: auditModify reqdn: uid=xyz,dc=umd,dc=edu reqend: 20190520190341.000002Z reqmod: entryCSN:= 20190520190341.087987Z#000000#001#000000 reqmod: modifyTimestamp:= 20190520190341Z reqresult: 0 reqsession: 7112 reqstart: 20190520190341.000001Z reqtype: modify dn: reqStart=20190520190418.000012Z,cn=accesslog objectclass: auditModify reqdn: uid=xyz,dc=umd,dc=edu reqend: 20190520190418.000013Z reqmod: entryCSN:= 20190520190418.183747Z#000000#001#000000 reqmod: modifyTimestamp:= 20190520190418Z reqresult: 0 reqsession: 7112 reqstart: 20190520190418.000012Z reqtype: modify If I do a search for the entryCSN, both producers have the correct value (having processed both changes)... dn: uid=xyz,dc=umd,dc=edu entrycsn: 20190520190418.183747Z#000000#001#000000 …but the consumers only processed the first change… dn: uid=xyx,dc=umd,dc=edu entrycsn: 20190520190341.087987Z#000000#001#000000 …are failing the second change (from slapd.log): do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20190520190418.183747Z#000000#001#000000 do_syncrep2: rid=001 CSN too old, ignoring 20190520190418.183747Z#000000#001#000000 (uid=xyz,,dc=umd,dc=edu) I am beginning to despair as to why this keeps happening and how to fix it when it does (short of reloading from a dump). And, yes, the clocks are being kept in sync. I will be the first to admit that I have got myself all turned around trying to get the configs right…and probably have something horribly wrong. Below are the relevant bits. Any advice is greatly appreciated. — CONFIGS — # # these lines are only on the producers # olcServerID: 1 ldap://producer1.umd.edu olcServerID: 2 ldap://producer2.umd.edu dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcSuffix: dc=umd,dc=edu # # not on producer1 # olcSyncrepl: rid=1 provider=ldaps://producer1.umd.edu type=refreshAndPersist scope=sub searchbase="dc=umd,dc=edu" bindmethod=simple binddn=“SYNC_DN" credentials=“PW" schemachecking=off retry="5 5 300 +" interval=00:00:00:30 timeout=10 keepalive="240:10:30" tls_cert=/etc/openldap/certs/slapd-cert.pem tls_key=/etc/openldap/certs/slapd-key.pem tls_cacert=/etc/openldap/certs/slapd-cacert.pem tls_reqcert=never logbase="cn=accesslog" syncdata=accesslog logfilter="(&(objectClass=auditWriteObject)(reqResult=0))” # # not on producer2 # olcSyncrepl: rid=2 provider=ldaps://producer2.umd.edu type=refreshAndPersist scope=sub searchbase="dc=umd,dc=edu" bindmethod=simple binddn=“SYNC_DN" credentials=“PW" schemachecking=off retry="5 5 300 +" interval=00:00:00:30 timeout=10 keepalive="240:10:30" tls_cert=/etc/openldap/certs/slapd-cert.pem tls_key=/etc/openldap/certs/slapd-key.pem tls_cacert=/etc/openldap/certs/slapd-cacert.pem tls_reqcert=never logbase="cn=accesslog" syncdata=accesslog logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" olcUpdateRef: ldaps://master.main.eng.directory.it-eng-aaa.aws.umd.edu # # on producers, this is set to TRUE # olcMirrorMode: FALSE dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckPoint: 100 10 olcSpSessionlog: 250000 olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcOverlay={1}accesslog,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogPurge: 5+00:00 1+00:00 dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcSuffix: cn=accesslog olcDbDirectory: /var/lib/ldap/accesslog olcDbMaxReaders: 126 olcDbSearchStack: 16 olcDbMaxSize: 10000000000 dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcSpCheckPoint: 100 1 olcSpNoPresent: TRUE olcSpReloadHint: TRUE olcSpSessionlog: 250000 // John Pfeifer Division of Information Technology University of Maryland, College Park

3 11

Updating slapd configuration programmatically
by Michel Gokan 03 Jun '19

03 Jun '19

I'm using slapd-mdb <http://manpages.courier-mta.org/htmlman5/slapd-mdb.5.html> and I'm looking for a way to programmatically update "maxsize" parameter using ldapmodify or similar. My main problem is that I have a huge dataset and I need more space. Any suggestions on how to update OpenLDAP configuration programmatically would be appreciated. My environment is Kubernetes and I deployed OpenLDAP as a container. I’ve also asked this question here: https://stackoverflow.com/questions/56373598/openldap-updating-slapd-config…

2 1

Re: accesslog database: overflow or data rotation?
by Manuela Mandache 30 May '19

30 May '19

Le mer. 15 mai 2019 19:52, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > --On Wednesday, May 15, 2019 8:23 PM +0200 Manuela Mandache > <manuela.mandache.mm(a)gmail.com> wrote: > > > Actually, the replication is in refreshAndPersist mode. > > Replication mode is immaterial. > Quanah, Thanks a lot for your detailed and comprehensive answers. Best regards, Manuela > >

4 8

Re: Extensible filters and substring searches
by Côme Chilliet 27 May '19

27 May '19

Le lundi 27 mai 2019, 07:45:34 CEST Quanah Gibson-Mount a écrit : > That's an IA5 string, so use either: > > caseExactIA5SubstringsMatch > or > caseIgnoreIA5SubstringsMatch > > I.e., the matching rules should match the syntax. So what would the syntax be? Because I get the error posted earlier anyway: >ldapsearch [options] "(ipHostNumber:1.3.6.1.4.1.1466.109.114.3:=10.*)" dn ># extended LDIF ># ># LDAPv3 ># base <dc=ecolo,dc=lan> with scope subtree ># filter: (ipHostNumber:1.3.6.1.4.1.1466.109.114.3:=10.*) ># requesting: dn ># > >ldap_search_ext: Bad search filter (-7) Côme

2 1

schema errors with slapcat with custom schema?
by Christopher Wood 22 May '19

22 May '19

I ran into ITS#8100 (replication item) with 2.4.45 and went to upgrade; one of the pre-upgrade slapcats complained about schema errors. The odd part is that the schema does indeed exist under cn=schema,cn=config and the attributes in question do exist in the resulting ldif. I was unable to find any reference to similar behaviour via ITS or Google search. Does this ring a bell with anybody? Does this have any implications for a subsequent slapadd after upgrading my custom-compiled openldap rpm? Will this affect future OpenLDAP upgrades? Have I missed a manpage?? Background and more details as follows. This is how I found out about ITS#8100: https://www.openldap.org/lists/openldap-technical/201706/msg00078.html https://www.openldap.org/its/index.cgi/Software%20Bugs?id=8100 The schema I had added: https://github.com/credativ/postfix-ldap-schema Adding the custom schema went fine apart from the replication issue: ---------- dn: cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.200 NAME 'mailacceptinggeneralid' DESC 'Postfix mail local address alias attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.201 NAME 'maildrop' DESC 'Postfix mail final destination attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) - add: olcObjectClasses olcObjectClasses: ( 1.3.6.1.4.1.4203.666.1.100 NAME 'postfixUser' DESC 'Postfix mail user class' SUP top AUXILIARY MAY ( mailacceptinggeneralid $ maildrop )) modifying entry "cn=schema,cn=config" ---------- The custom bits are indeed in the directory: [root@mailhost man]# /opt/openldap/bin/ldapsearch -D cn=config -W -s sub -b cn=schema,cn=config -o ldif-wrap=no | egrep 'postfixUser|maildrop|mailacceptinggeneralid' Enter LDAP Password: olcAttributeTypes: {245}( 1.3.6.1.4.1.4203.666.1.200 NAME 'mailacceptinggeneralid' DESC 'Postfix mail local address alias attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) olcAttributeTypes: {246}( 1.3.6.1.4.1.4203.666.1.201 NAME 'maildrop' DESC 'Postfix mail final destination attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) olcObjectClasses: {49}( 1.3.6.1.4.1.4203.666.1.100 NAME 'postfixUser' DESC 'Postfix mail user class' SUP top AUXILIARY MAY ( mailacceptinggeneralid $ maildrop )) slapschema thinks something is odd, although I can ldapsearch and retrieve entries with these attributes just fine: [root@mailhost man]# /opt/openldap/sbin/slapschema -bdc=me -F/opt/openldap/etc/openldap/slapd.d 5ce5693b UNKNOWN attributeDescription "MAILACCEPTINGGENERALID" inserted. 5ce5693b UNKNOWN attributeDescription "MAILDROP" inserted. # (65) Object class violation: unrecognized objectClass 'postfixUser' dn: uid=mail1,dc=fake1.example,dc=me # (65) Object class violation: unrecognized objectClass 'postfixUser' dn: cn=mail1(a)somedomain.com,dc=fake1.example,dc=me slapcat only reports the attribute item, but not the objectClass item: [root@mailhost man]# /opt/openldap/sbin/slapcat -bdc=me -F/opt/openldap/etc/openldap/slapd.d -l'/var/tmp/dc=me.ldif' 5ce55367 UNKNOWN attributeDescription "MAILACCEPTINGGENERALID" inserted. 5ce55367 UNKNOWN attributeDescription "MAILDROP" inserted. For completeness, here's showing that the custom schema exists in the exports. Pardon the redactions, not listing people's names save for myself in a list post. [root@mailhost man]# egrep -i 'postfixUser|maildrop|mailacceptinggeneralid' /var/tmp/dc\=me.ldif | cut -d: -f1 objectClass MAILACCEPTINGGENERALID MAILACCEPTINGGENERALID MAILDROP MAILDROP objectClass MAILACCEPTINGGENERALID MAILACCEPTINGGENERALID MAILDROP MAILDROP [root@mailhost man]# egrep -i 'postfixUser|maildrop|mailacceptinggeneralid' /var/tmp/cn\=config.ldif olcAttributeTypes: {1}( 1.3.6.1.4.1.4203.666.1.201 NAME 'maildrop' DESC 'Pos olcObjectClasses: {0}( 1.3.6.1.4.1.4203.666.1.100 NAME 'postfixUser' DESC 'P ostfix mail user class' SUP top AUXILIARY MAY ( mailacceptinggeneralid $ ma

3 3

OPEN LDAP ACL
by Florent Vallée 22 May '19

22 May '19

Hello, I manage all my users with LDAP. I would like to build the following reading rules: 1. only admin can change passwords, authenticated users read and anonymous do nothing 2. Authenticated users access the database but can only read their account but not the rest 3. the group ou = system-read can read the whole database 4. the group ou = system-write can write in ou = ent 5. Anonymous access is forbidden My LDIF file : dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword by self write by dn="cn=admin,dc=example,dc=fr" write by * auth olcAccess: {1}to dn.base="" by self write by dn="ou=system-read,dc=example,dc=fr" read by * auth olcAccess: {2}to dn.subtree="ou=ent,dc=example,dc=fr" by self write by dn="ou=system-write,dc=example,dc=fr" write by * none olcAccess: {3}to * by self write by dn="cn=admin,dc=example,dc=fr" write by * none I have a lot of trouble with ACLs, I can not do what I want with. Thank you for your help. Florent

3 3

ObjectClass auxiliary - Beginner's question
by Olivier - 21 May '19

21 May '19

Hi all, I have to re-write a shcema but i'm beginner with this. I would like to add some attributes to describe service. We use a AUXILIARY class to add some attributes : objectclass ( 1.2.250.1.152.14.2.1.2 NAME 'intService' SUP top AUXILIARY MAY (...)) We have an object using this objectclass and other : dn: idService=196018, dmdName=Services, dc=fr objectClass: intService objectClass: organizationalUnit Now i would like to transform this object in static group so I use GroupOfnames and I got this error : Object class violation (65) additional info: invalid structural object class chain (organizationalUnit/groupOfNames) Why can't I use groupOfNames with organizationalUnit ? Or is it another problem ? Thanks a lot.

2 1

Re: accesslog database: overflow or data rotation?
by Manuela Mandache 15 May '19

15 May '19

Le mer. 15 mai 2019 22:42, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > --On Wednesday, May 15, 2019 10:37 PM +0200 Manuela Mandache > <manuela.mandache.mm(a)gmail.com> wrote: > > > > > > > > > > > > > > > Le mer. 15 mai 2019 19:52, Quanah Gibson-Mount <quanah(a)symas.com> a > > écrit : > > > > --On Wednesday, May 15, 2019 8:23 PM +0200 Manuela Mandache > > <manuela.mandache.mm(a)gmail.com> wrote: > > > >>> Actually, the replication is in refreshAndPersist mode. > >> > >> Replication mode is immaterial. > > > Thanks a lot for your detailed and comprehensive answers. > > Heh, I can't tell in this case if your serious or sarcastic, but I'll note > this: it's entirely possible (and legal, and there are valid reasons for > it) to have an accesslog for a database where the environment is not > replicated at all. So replication mode, etc, is utterly immaterial to > whether or not an accesslog may exist, what its purge interval is, etc. > If > that helps. :) > Oh dear, I was totally serious, meaning to thank you for your three answers in one go. I might have been too formal, to the point of making you doubt - sorry, English is not my mother tongue and I live in France... Now that you mention it, I did read somewhere in the web-wide documentation that the delta-syncrepl is only one of the possible uses for the accesslog DB. And thanks again (seriously ;)) Manuela > >

1 0

Re: accesslog database: overflow or data rotation?
by Manuela Mandache 15 May '19

15 May '19

Le mar. 14 mai 2019 19:31, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > --On Tuesday, May 14, 2019 8:03 PM +0200 Dieter Kluenter > <dieter(a)dkluenter.de> wrote: > > >> olcDbMaxSize defined for this database? Thanks! > > > > Depending on the number of operations you may set logpurge to a > > appropriate value. > > Yeah, I think the question is, what happens if you have so many operations > in an <interval> that it maxes out the DB, where the interval is smaller > than the logpurge interval. Hi all, Thank you Quanah for your answers (and Dieter too, it seems :)). This was indeed the question. But it's a good point, one could (if using > cn=config) do an on-the-fly modification of the logpurge interval so that > the DB gets purged more frequently to accomodate the rate of change. > > --Quanah > Would a small logpurge interval strongly influence the system's performance? If it would, a both ways on-the-fly change based on automatic watch of the actual size of the accesslog database might be interesting if the high rate writes are a seldom event. If it wouldn't, setting a small enough interval from the beggining would do the trick. Regards, Manuela > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

3 6

overlay unique
by A. Schulze 14 May '19

14 May '19

Hello, I've a openldap master and numerous sync replica servers running. I'm suspect my master contain mail attributes that aren't unique. My idea was to build an other sync replica with unique overlay enabled. The 'empty' sync replica will fetch data from master and complain about values that aren't unique. I would discard that replica, correct the master database and start replication again until replication succeed. But then there was reality :-/ I placed an deliberately none-unique value in my database but replication did not fail. The replica did contain two DNs with "mail=none-unique(a)example.test". syncrepl.conf: moduleload mdb.la moduleload unique.la database mdb suffix ou=test ... overlay unique uniqiue_uri ldap:///ou=test?mail?sub? index ... limits ... syncrepl rid=1 privider=ldap://master.example ... access ... Q: is this setup wrong? Q: is replication the right way to enforce uniqueness? Looks like the answer is "no" Q: what is "the" better way? Andreas

2 1

accesslog database: overflow or data rotation?
by Manuela Mandache 14 May '19

14 May '19

Hi all, A directory is configured as delta-syncrepl provider, the backends for the main database and the accesslog database are both mdb. Everything works fine, my question is: What happens if there are so many write ops that the size of the accesslog database reaches the value of olcDbMaxSize defined for this database? Thanks! Cheers, Manuela

3 3

Re: Problem with N-Way multimaster replication after an node fail and restore
by David Tello 13 May '19

13 May '19

Hi Quanah, Thank for your answer. I improved my configuration with your indications. Unfortunately the behavior remained the same. Following your suggestions, i will send an message to ITS. I willl try to script the exact steps i did for get the current behavior. i will reuse the logs that i putted here. Regards, David El jue., 9 may. 2019 a las 20:16, Quanah Gibson-Mount (<quanah(a)symas.com>) escribió: > --On Thursday, May 09, 2019 11:21 AM +0200 David Tello > <david.tello.wbsgo(a)gmail.com> wrote: > > > > > > > I have a problem with the N-Way replication multimaster. My enviroiment > > is debian Stretch and slapd (2.4.47+dfsg-3~bpo9+1) from Stretch > > backports. > > Hi David, > > I notice your slapo-syncprov overlays are missing a sessionlog setting. > It > is critical that this value be large (approximately the same as the number > of entries in your database). I'd also note that the order in which > overlays (particularly syncprov) are instantiated on a database can > matter. > It's generally advised that syncprov be the first instantiated overlay (In > your configuration, it's the 7th overlay on the mdb database with index > {6}). I.e., it should be the overlay at index {0}. > > These changes may or may not address your issue, but I note them as they > are items that should be addressed in your configuration. > > If you are able to reproduce the issue after fixing the above config > items, > I would ask that you file an ITS at <http://www.openldap.org/its>. Even > better is if you're able to script the reproduction case (it seems rather > straight forward) so we can reproduce it locally to work on a fix. > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Problem with N-Way multimaster replication after an node fail and restore
by David Tello 13 May '19

13 May '19

I have a problem with the N-Way replication multimaster. My enviroiment is debian Stretch and slapd (2.4.47+dfsg-3~bpo9+1) from Stretch backports. I have configured a cluster with 3 nodes. I have configured to replicate the config database and a normal data mdb database. I followed the documentation and the cluster sync work correctly when all nodes are started. If i made a change in any node, this change is replicated to the others. My problem appears when i make a change whe one node is down. In this case, the other two nodes repli correctly, and when the downed node start this get all pending changes correctly. And in this point occurs the problem. After the start of downed node, the changes mades in this node are not send to the other two nodes. For other way, the changes mades in the other two nodes (no shutdowned) are sended to all nodes correctly. I tried this config with a two nodes cluster and the behavior was the same, after reboot slapd do not send more updates. I have checked the olcServerId because i know that a mistake here can produce similar problems. I really think that it is correct. The cmdlines of the proccess are: /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode1/ ldap://127.0.0.1/ ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode2/ ldap://127.0.0.1/ ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode3/ ldap://127.0.0.1/ ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d The config database configuración is below: *DN: cn=config* ..... olcServerID: 1 ldap://wbsvisionNode1/ olcServerID: 2 ldap://wbsvisionNode2/ olcServerID: 3 ldap://wbsvisionNode3/ *dn: olcDatabase={0}config,cn=config* ....... olcMirrorMode: TRUE olcSyncUseSubentry: FALSE olcSyncrepl: {0}rid=001 provider=ldap://wbsvisionNode1 bindmethod=simple binddn="cn=admin,cn=config" credentials="TuoDqAG7UbCJx8H8gfMO" starttls=no tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem tls_key=/etc/pki/private/wbsagnitio.local.es.key tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem tls_reqcert=never searchbase="cn=config" scope=sub type=refreshAndPersist retry="5 5 300 +" {1}rid=002 provider=ldap://wbsvisionNode2 bindmethod=simple binddn="cn=admin,cn=config" credentials="TuoDqAG7UbCJx8H8gfMO" starttls=no tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem tls_key=/etc/pki/private/wbsagnitio.local.es.key tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem tls_reqcert=never searchbase="cn=config" scope=sub type=refreshAndPersist retry="5 5 300 +" {2}rid=003 provider=ldap://wbsvisionNode3 bindmethod=simple binddn="cn=admin,cn=config" credentials="TuoDqAG7UbCJx8H8gfMO" starttls=no tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem tls_key=/etc/pki/private/wbsagnitio.local.es.key tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem tls_reqcert=never searchbase="cn=config" scope=sub type=refreshAndPersist retry="5 5 300 +" FALSE ------ *dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config* objectClass: olcSyncProvConfig objectClass: olcOverlayConfig olcOverlay: {0}syncprov olcSpCheckpoint: 1000 1 The data database configuración is below: *dn: olcDatabase={1}mdb,cn=config* objectClass: olcMdbConfig objectClass: olcDatabaseConfig olcDatabase: {1}mdb ... olcDbIndex: objectClass eq olcDbIndex: entryCSN eq ... olcLastMod: TRUE olcSuffix: dc=local,dc=es ......... olcMirrorMode: TRUE olcSyncrepl: {0}rid=004 provider=ldap://wbsvisionNode1 bindmethod=simple binddn="cn=manager,dc=local,dc=es" credentials="test" starttls=no searchbase="dc=local,dc=es" scope=sub type=refreshAndPersist retry="5 5 300 +" olcSyncrepl: {1}rid=005 provider=ldap://wbsvisionNode2 bindmethod=simple binddn="cn=manager,dc=local,dc=es" credentials="test" starttls=no searchbase="dc=local,dc=es" scope=sub type=refreshAndPersist retry="5 5 300 +" olcSyncrepl: {2}rid=006 provider=ldap://wbsvisionNode3 bindmethod=simple binddn="cn=manager,dc=local,dc=es" credentials="test" starttls=no searchbase="dc=local,dc=es" scope=sub type=refreshAndPersist retry="5 5 300 +" olcSyncUseSubentry: FALSE dn: olcOverlay={0}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig olcOverlay: {0}dynlist olcDlAttrSet: {0}virtualGroup memberDnURL uniqueMember olcDlAttrSet: {1}virtualGroup memberUidURL memberUid:uid olcDlAttrSet: {2}virtualGroup memberSidURL sambaSIDList:sambaSID dn: olcOverlay={1}lastbind,olcDatabase={1}mdb,cn=config objectClass: olcLastBindConfig objectClass: olcOverlayConfig olcOverlay: {1}lastbind olcLastBindPrecision: 30 dn: olcOverlay={2}unique,olcDatabase={1}mdb,cn=config objectClass: olcUniqueConfig objectClass: olcOverlayConfig olcOverlay: {2}unique olcUniqueAttribute: uid olcUniqueAttribute: uidNumber olcUniqueAttribute: employeeNumber olcUniqueBase: dc=local,dc=es dn: olcOverlay={3}memberof,olcDatabase={1}mdb,cn=config objectClass: olcMemberOf objectClass: olcOverlayConfig olcOverlay: {3}memberof olcMemberOfDangling: ignore olcMemberOfGroupOC: groupOfUniqueNames olcMemberOfMemberAD: uniqueMember olcMemberOfMemberOfAD: memberOf olcMemberOfRefInt: TRUE dn: olcOverlay={4}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcAccessLogConfig objectClass: olcOverlayConfig olcAccessLogDB: cn=accesslog olcOverlay: {4}accesslog olcAccessLogOld: (|(objectClass=wbsagnitioGroup)(objectClass=wbsagnitioAccou nt)) olcAccessLogOldAttr: roles olcAccessLogOldAttr: objectClass olcAccessLogOps: writes olcAccessLogOps: bind olcAccessLogPurge: 7+00:00 1+00:00 dn: olcOverlay={5}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcPPolicyConfig objectClass: olcOverlayConfig olcOverlay: {5}ppolicy olcPPolicyDefault: cn=0-default,ou=passwordpolicies,ou=configuration,dc=loca l,dc=es olcPPolicyForwardUpdates: FALSE olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: FALSE dn: olcOverlay={6}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig olcOverlay: {6}syncprov olcSpCheckpoint: 1000 1 Below i show the sync log of some operations to show the behavior of my cluster: TEST 1: 3 Nodes up. Update in node 1 (correct):Log Node1: May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing 0x7fc7e0100a90 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing 0x7fc7e0108b40 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn: removing 0x7fc7e0108b40 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=002, cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003, cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn: removing 0x7fc7e0100a90 20190507150322.383471Z#000000#001#000000 Log Node2: May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=004 cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_message_to_entry: rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID: d6c282a0-00ff-1039-89ae-b1c1eec8fb13 May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid 23fff700 May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004 be_search (0) May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004 cn=Usuarios,ou=grupos,dc=local,dc=es May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing 0x7f80081057c0 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_matchops: skipping original sid 001 May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing 0x7f8008107700 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn: removing 0x7f8008107700 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_matchops: skipping original sid 001 May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=003, cookie=rid=005,sid=002,csn=20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn: removing 0x7f80081057c0 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004 be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0) May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing 0x7f8008105ea0 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn: removing 0x7f8008105ea0 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=006 cookie=rid=006,sid=003,csn=20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=006 CSN too old, ignoring 20190507150322.383471Z#000000#001#000000 (cn=Usuarios,ou=grupos,dc=local,dc=es) Log Node3: May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004 cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry: rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID: d6c282a0-00ff-1039-89ae-b1c1eec8fb13 May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid adbb2700 May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004 be_search (0) May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004 cn=Usuarios,ou=grupos,dc=local,dc=es May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing 0x7f428c1045c0 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping original sid 001 May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing 0x7f428c1069e0 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn: removing 0x7f428c1069e0 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping original sid 001 May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn: removing 0x7f428c1045c0 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=002, cookie=rid=006,sid=003,csn=20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004 be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0) May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing 0x7f428c104c90 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn: removing 0x7f428c104c90 20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005 cookie=rid=005,sid=002,csn=20190507150322.383471Z#000000#001#000000 May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005 CSN too old, ignoring 20190507150322.383471Z#000000#001#000000 (cn=Usuarios,ou=grupos,dc=local,dc=es) TEST 2: 3 Nodes up. Update in node 2 (correct) (later this will be the down node):Log Node1: May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=005 cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_message_to_entry: rid=005 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID: d6c282a0-00ff-1039-89ae-b1c1eec8fb13 May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid eaffd700 May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005 be_search (0) May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005 cn=Usuarios,ou=grupos,dc=local,dc=es May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing 0x7fc7d411fdd0 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_matchops: skipping original sid 002 May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing 0x7fc7d4105fa0 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn: removing 0x7fc7d4105fa0 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_matchops: skipping original sid 002 May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn: removing 0x7fc7d411fdd0 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005 be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0) May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing 0x7fc7d4121830 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003, cookie=rid=004,sid=001,csn=20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn: removing 0x7fc7d4121830 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=006 cookie=rid=006,sid=003,csn=20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=006 CSN too old, ignoring 20190507150531.748816Z#000000#002#000000 (cn=Usuarios,ou=grupos,dc=local,dc=es) Log Node2: May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing 0x7f8008106ed0 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing 0x7f80081050e0 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn: removing 0x7f80081050e0 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=003, cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn: removing 0x7f8008106ed0 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=001, cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000 Log Node3: May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005 cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry: rid=005 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID: d6c282a0-00ff-1039-89ae-b1c1eec8fb13 May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid acbb0700 May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005 be_search (0) May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005 cn=Usuarios,ou=grupos,dc=local,dc=es May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing 0x7f4288107310 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping original sid 002 May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing 0x7f4288109c60 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn: removing 0x7f4288109c60 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping original sid 002 May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn: removing 0x7f4288107310 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=001, cookie=rid=006,sid=003,csn=20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005 be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0) May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing 0x7f42881079f0 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn: removing 0x7f42881079f0 20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004 cookie=rid=004,sid=001,csn=20190507150531.748816Z#000000#002#000000 May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004 CSN too old, ignoring 20190507150531.748816Z#000000#002#000000 (cn=Usuarios,ou=grupos,dc=local,dc=es) TEST 3: 2 Nodes up. The node 2 is down. Update in node 1:Log Node1: May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing 0x7fc7dc125e50 20190507151016.178467Z#000000#001#000000 May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing 0x7fc7dc126f40 20190507151016.178467Z#000000#001#000000 May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn: removing 0x7fc7dc126f40 20190507151016.178467Z#000000#001#000000 May 7 17:10:16 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=002, cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000 May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn: removing 0x7fc7dc125e50 20190507151016.178467Z#000000#001#000000 May 7 17:10:16 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003, cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000 Log Node3: May 7 17:10:15 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004 cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000 May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry: rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID: d6c282a0-00ff-1039-89ae-b1c1eec8fb13 May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid a6ffd700 May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004 be_search (0) May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004 cn=Usuarios,ou=grupos,dc=local,dc=es May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing 0x7f42a0124640 20190507151016.178467Z#000000#001#000000 May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping original sid 001 May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing 0x7f42a01261a0 20190507151016.178467Z#000000#001#000000 May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn: removing 0x7f42a01261a0 20190507151016.178467Z#000000#001#000000 May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping original sid 001 May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn: removing 0x7f42a0124640 20190507151016.178467Z#000000#001#000000 May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=002, cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000 May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004 be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0) May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing 0x7f42a0124810 20190507151016.178467Z#000000#001#000000 May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn: removing 0x7f42a0124810 20190507151016.178467Z#000000#001#000000 TEST 4: 3 Nodes up. Logs of the sync produced by the Node2 start. The node2 resync correctly the change made in TEST3 (when this node was down). Log Node1: May 7 17:13:52 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing 0x7fc7dc122780 20190507151352.582436Z#000000#001#000000 May 7 17:13:52 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn: removing 0x7fc7dc122780 20190507151352.582436Z#000000#001#000000 May 7 17:13:52 wbsvisionNode1 slapd[14058]: syncprov_search_response: cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000;20190507150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000 Log Node2: May 7 17:13:52 wbsvisionNode2 slapd[591]: slapd starting May 7 17:13:52 wbsvisionNode2 slapd[435]: Starting OpenLDAP: slapd. May 7 17:13:52 wbsvisionNode2 systemd[1]: Started LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol). May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=003 LDAP_RES_INTERMEDIATE - REFRESH_DELETE May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004 LDAP_RES_INTERMEDIATE - SYNC_ID_SET May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006 LDAP_RES_INTERMEDIATE - SYNC_ID_SET May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_message_to_entry: rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID: d6c282a0-00ff-1039-89ae-b1c1eec8fb13 May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) tid f6021700 May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004 be_search (0) May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004 cn=Usuarios,ou=grupos,dc=local,dc=es May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_message_to_entry: rid=006 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID: d6c282a0-00ff-1039-89ae-b1c1eec8fb13 May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) tid f501f700 May 7 17:13:52 wbsvisionNode2 slapd[591]: dn_callback : entries have identical CSN cn=Usuarios,ou=grupos,dc=local,dc=es 20190507151016.178467Z#000000#001#000000 May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006 be_search (0) May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006 cn=Usuarios,ou=grupos,dc=local,dc=es May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006 entry unchanged, ignored (cn=Usuarios,ou=grupos,dc=local,dc=es) May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006 cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000;20190507150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000 May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006 present UUID d6b883e0-00ff-1039-898f-b1c1eec8fb13, dn dc=local,dc=es May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006 present UUID d6b88520-00ff-1039-8990-b1c1eec8fb13, dn ou=personas,dc=local,dc=es May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006 present UUID d6b8e51a-00ff-1039-8991-b1c1eec8fb13, dn ou=grupos,dc=local,dc=es May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006 present UUID d6b9494c-00ff-1039-8992-b1c1eec8fb13, dn ou=dominios,dc=local,dc=es May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006 present UUID d6b9b18e-00ff-1039-8993-b1c1eec8fb13, dn ou=dns,dc=local,dc=es May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006 present UUID d6b9eaaa-00ff-1039-8994-b1c1eec8fb13, dn ou=forward,ou=dns,dc=local,dc=es ................................. Similar lines with other entries. May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006 present UUID d6c282a0-00ff-1039-89ae-b1c1eec8fb13, dn cn=Usuarios,ou=grupos,dc=local,dc=es ............................... May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing 0x7f63d0123740 20190507151016.178467Z#000000#001#000000 May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004 be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0) May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004 cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000;20190507150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000 May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004 present UUID d6b883e0-00ff-1039-898f-b1c1eec8fb13, dn dc=local,dc=es May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004 present UUID d6b88520-00ff-1039-8990-b1c1eec8fb13, dn ou=personas,dc=local,dc=es May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004 present UUID d6b8e51a-00ff-1039-8991-b1c1eec8fb13, dn ou=grupos,dc=local,dc=es May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004 present UUID d6b9494c-00ff-1039-8992-b1c1eec8fb13, dn ou=dominios,dc=local,dc=es May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004 present UUID d6b9b18e-00ff-1039-8993-b1c1eec8fb13, dn ou=dns,dc=local,dc=es May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004 present UUID d6c282a0-00ff-1039-89ae-b1c1eec8fb13, dn cn=Usuarios,ou=grupos,dc=local,dc=es ............................. Similar lines with other entries. May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing 0x7f63d0121400 20190507151016.178467Z#000000#001#000000 May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn: removing 0x7f63d0121400 20190507151016.178467Z#000000#001#000000 May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn: removing 0x7f63d0123740 20190507151016.178467Z#000000#001#000000 Log Node3: May 7 17:13:52 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing 0x7f428c103b00 20190507151352.329505Z#000000#003#000000 May 7 17:13:52 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn: removing 0x7f428c103b00 20190507151352.329505Z#000000#003#000000 May 7 17:13:52 wbsvisionNode3 slapd[1100]: syncprov_search_response: cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000;20190507150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000 TEST 5: 3 Nodes up. Change is made in Node2 after resync and this is not sended to the other nodes in the cluster.Log Node1: Empty. Log Node2: May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing 0x7f63cc121370 20190507152835.873382Z#000000#002#000000 May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing 0x7f63cc125120 20190507152835.873382Z#000000#002#000000 May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn: removing 0x7f63cc125120 20190507152835.873382Z#000000#002#000000 May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn: removing 0x7f63cc121370 20190507152835.873382Z#000000#002#000000 Log Node3: Empty.

3 3

Re: Issue with OpenLDAP as a proxy to multiple Windows DCs backends
by David Sanchez Herrero 13 May '19

13 May '19

Hello Clement, Thank you for your answer. I tried some of these parameters before with no success. I can't remember exactily which values I probed because I tested them a few weeks ago, so I checked them again with this configuration, and I have the same wrong behaviour as without them: bind-timeout 1000000 (1 second) network-timeout 2 (2 seconds) ... ... ####################################################################### # MDB database definitions ####################################################################### ###Ad Principal database meta suffix "dc=ldapproxy-pre,dc=local" rootdn "cn=manager,dc=ldapproxy-pre,dc=local" rootpw ?????????????? chase-referrals no nretries 0 bind-timeout 1000000 network-timeout 2 ################################### # # Entrada LDAP para ONE # ################################### uri "ldap://1.2.3.1/ou=ONE,ou=Usuarios,dc=ldapproxy-pre,dc=local" ... ... Greetings, David.

2 2

slapindex vs reimport debug messages (mdb_index_read: failed (-30798))
by John Holder 10 May '19

10 May '19

Greetings OpenLDAP List! I have a quick question about the context and meaning of messages which show when using slapd debug and how/whether they impact indexes and performance. I recently ran into an issue where an attribute was not indexed, so I applied an index using #slapindex -F (config) (atr) When starting the daemon in debug mode and doing a search, there are many entries regarding mdb equality and index failure (see below) However, if I re-import the data using slapadd, and run the same search, all of those messages go away. I was hoping someone could assist with the meaning of the messages and why does it print the messages even after slapindex was run, but not if the olcDbIndex is added and then the ldif is re-imported? In particular I'm seeing : 5ccb5ed0 <= mdb_index_read: failed (-30798) and it seems to then search all attributes within the candidates. But this doesn't occur if the data is reimported using slapadd. Thank you! jh Debug from before export but after slapindex (key) was run: 5ccb5ed0 connection_get(13): got connid=1004 5ccb5ed0 connection_read(13): checking for input on id=1004 ber_get_next ber_get_next: tag 0x30 len 52 contents: 5ccb5ed0 op tag 0x60, time 1556831952 <callto:1556831952> ber_get_next 5ccb5ed0 conn=1004 op=1 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: 5ccb5ed0 >>> dnPrettyNormal: <uid=jbh,cn=esx,cn=net> 5ccb5ed0 <<< dnPrettyNormal: <uid=jbh,cn=esx,cn=net>, <uid=jbh,cn=esx,cn=net> 5ccb5ed0 do_bind: version=3 dn="uid=jbh,cn=admins,cn=esx" method=128 5ccb5ed0 mdb_dn2entry("uid=jbh,cn=admins,cn=esx") 5ccb5ed0 => mdb_dn2id("uid=jbh,cn=admins,cn=esx") 5ccb5ed0 <= mdb_dn2id: got id=0x3 5ccb5ed0 => mdb_entry_decode: 5ccb5ed0 <= mdb_entry_decode 5ccb5ed0 do_bind: v3 bind: "uid=jbh,cn=admins,cn=esx" to "uid=jbh,cn=admins,cn=esx" 5ccb5ed0 send_ldap_result: conn=1004 op=1 p=3 5ccb5ed0 send_ldap_response: msgid=5 tag=97 err=0 ber_flush2: 14 bytes to sd 13 5ccb5ed0 connection_get(13): got connid=1004 5ccb5ed0 connection_read(13): checking for input on id=1004 ber_get_next ber_get_next: tag 0x30 len 72 contents: 5ccb5ed0 op tag 0x63, time 1556831952 <callto:1556831952> ber_get_next 5ccb5ed0 conn=1004 op=2 do_search ber_scanf fmt ({miiiib) ber: 5ccb5ed0 >>> dnPrettyNormal: <cn=servers,cn=esx> 5ccb5ed0 <<< dnPrettyNormal: <cn=servers,cn=esx>, <cn=servers,cn=esx> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: 5ccb5ed0 ==> limits_get: conn=1004 op=2 self="uid=jbh,cn=admins,cn=esx" this="cn=servers,cn=esx" 5ccb5ed0 => mdb_search 5ccb5ed0 mdb_dn2entry("cn=servers,cn=esx") 5ccb5ed0 => mdb_dn2id("cn=servers,cn=esx") 5ccb5ed0 <= mdb_dn2id: got id=0xd 5ccb5ed0 => mdb_entry_decode: 5ccb5ed0 <= mdb_entry_decode 5ccb5ed0 search_candidates: base="cn=servers,cn=esx" (0x0000000d) scope=2 5ccb5ed0 => mdb_equality_candidates (objectClass) 5ccb5ed0 => key_read 5ccb5ed0 <= mdb_index_read: failed (-30798) 5ccb5ed0 <= mdb_equality_candidates: id=0, first=0, last=0 5ccb5ed0 => mdb_equality_candidates (cn) 5ccb5ed0 => key_read 5ccb5ed0 <= mdb_index_read 1 candidates 5ccb5ed0 <= mdb_equality_candidates: id=1, first=33, last=33 5ccb5ed0 mdb_search_candidates: id=1 first=33 last=33 5ccb5ed0 => mdb_entry_decode: 5ccb5ed0 <= mdb_entry_decode 5ccb5ed0 => send_search_entry: conn 1004 dn="cn=esxi-master.johnholder.net ,cn=servers,cn=esx" ber_flush2: 5545 bytes to sd 13esx 5ccb5ed0 <= send_search_entry: conn 1004 exit. 5ccb5ed0 send_ldap_result: conn=1004 op=2 p=3 5ccb5ed0 send_ldap_response: msgid=6 tag=101 err=0 ber_flush2: 14 bytes to sd 13 5ccb5ed0 slap_listener_activate(7): 5ccb5ed0 >>> slap_listener(ldap://host.esx.local:389) 5ccb5ed0 connection_get(14): got connid=1005 5ccb5ed0 connection_read(14): checking for input on id=1005 ber_get_next ber_get_next: tag 0x30 len 29 contents: 5ccb5ed0 op tag 0x77, time 1556831952 <callto:1556831952> ber_get_next 5ccb5ed0 conn=1005 op=0 do_extended ber_scanf fmt ({m) ber: 5ccb5ed0 send_ldap_extended: err=0 oid= len=0 5ccb5ed0 send_ldap_response: msgid=1 tag=120 err=0 ber_flush2: 14 bytes to sd 14 <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2 1

Unix groups information in LDAP server
by JC 10 May '19

10 May '19

I am a complete rookie when it comes to LDAP, so my apologies if what I am about to ask is something obvious. I have an LDIF file that contains entries like the following: # someuser, individuals, mydomain.comdn: uid=someuser,ou=individuals,dc=mydomain,dc=comuid: someusercn: someuserobjectClass: accountobjectClass: posixAccountloginShell: /bin/bashuidNumber: 1000gidNumber: 100homeDirectory: /home/someuser When used in conjunction with NSS in a Linux box, this allows me to centralize a number of Linux attributes for users - a specific one here called 'someuser'. The next thing I would like to do is to store information in the LDAP server about other groups that someuser belongs to. For example, besides 'users' (GID 100) someuser might belong to 'power' (GID 84) , 'mysql' (GID 27) and 'cdrom' (GID 19). Can anybody please point me in the right direction how to pull this off?

2 1

Issue with OpenLDAP as a proxy to multiple Windows DCs backends
by David Sanchez Herrero 10 May '19

10 May '19

Hello all, I'm having an issue with the configuration of an OpenLDAP working as a proxy to various Active Directory backends. The OpenLDAP proxy is in our network and we have various VPN to connect it to the remote Windows Domain Controllers (5 remote Domain Controlers of different customers, each one managing it's own domain). To configure the proxy, we use de META database. When all the Domain Controllers are up, everything works fine, but when one of then goes down (network problems, a machine reboot, etc.), the web app that uses the OpenLDAP proxy stops autheticating all users of all domains. The system process it's even hanged and when you try to stop or restart the service, it takes a long time to respond. I can't find a way to force a short timeout to ignore the offline DC and let the users of the other domains to continue working. The server OS is CentOS Linux release 7.4.1708 (Core), and the OpenLDAP version 2.4.44. To check if this is an issue of this old version, I have deployed another server with Fedora 30 and OpenLDAP 2.4.47, but same behaviour, so it's probably a configuration problem. Below are the slapd.conf file I'm using (with no private data). Any ideas about what to change in the configuration file? Thanks in advance and best regards, David. # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # Include /etc/openldap/schema/core.schema Include /etc/openldap/schema/corba.schema Include /etc/openldap/schema/cosine.schema Include /etc/openldap/schema/duaconf.schema Include /etc/openldap/schema/dyngroup.schema Include /etc/openldap/schema/inetorgperson.schema Include /etc/openldap/schema/java.schema Include /etc/openldap/schema/misc.schema Include /etc/openldap/schema/nis.schema Include /etc/openldap/schema/openldap.schema Include /etc/openldap/schema/collective.schema Include /etc/openldap/schema/pmi.schema Include /etc/openldap/schema/ppolicy.schema allow bind_v2 # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules: modulepath /usr/lib64/openldap moduleload rwm.la moduleload back_meta.la moduleload back_ldap.la moduleload back_null.la moduleload back_bdb.la moduleload back_hdb.la moduleload back_ldif.la moduleload back_shell.la moduleload back_perl.la loglevel 4095 ####################################################################### # MDB database definitions ####################################################################### ###Ad Principal database meta suffix "dc=ldapproxy-pre,dc=local" rootdn "cn=manager,dc=ldapproxy-pre,dc=local" rootpw ?????????????? chase-referrals no nretries 0 ################################### # # Entrada LDAP para ONE # ################################### uri "ldap://1.2.3.1/ou=ONE,ou=Usuarios,dc=ldapproxy-pre,dc=local" readonly yes lastmod off suffixmassage "ou=ONE,ou=Usuarios,dc=ldapproxy-pre,dc=local" "dc=ONE,dc=local" idassert-bind bindmethod=simple binddn="CN=USERONE,OU=Usuarios,DC=ONE,DC=local" credentials="??????????????" mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=manager,dc=ldapproxy-pre,dc=local" overlay rwm rwm-map attribute uid mail ################################### # # Entrada LDAP para TWO # ################################### uri "ldap://1.2.3.2/ou=TWO,ou=Usuarios,dc=ldapproxy-pre,dc=local" readonly yes lastmod off suffixmassage "ou=TWO,ou=Usuarios,dc=ldapproxy-pre,dc=local" "ou=TWO,ou=people,ou=users,dc=TWO,dc=local" idassert-bind bindmethod=simple binddn="CN=USERTWO,CN=Users,DC=TWO,DC=local" credentials="????????????" mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=manager,dc=ldapproxy-pre,dc=local" overlay rwm ################################### # # Entrada LDAP para THREE # ################################### uri "ldap://1.2.3.3/ou=THREE,ou=Usuarios,dc=ldapproxy-pre,dc=local" readonly yes lastmod off suffixmassage "ou=THREE,ou=Usuarios,dc=ldapproxy-pre,dc=local" "dc=THREE,dc=red" idassert-bind bindmethod=simple binddn="CN=USERTHREE,CN=Users,DC=THREE,DC=red" credentials="??????????????????????" mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=manager,dc=ldapproxy-pre,dc=local" overlay rwm ########################################## # # Entrada LDAP para FOUR # ######################################### uri "ldap://1.2.3.4/ou=FOUR,ou=Usuarios,dc=ldapproxy-pre,dc=local" readonly yes lastmod off suffixmassage "ou=FOUR,ou=Usuarios,dc=ldapproxy-pre,dc=local" "dc=FOUR,dc=loc" idassert-bind bindmethod=simple binddn="CN=USERFOUR,CN=Users,DC=FOUR,DC=loc" credentials="??????????????????????" mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=manager,dc=ldapproxy-pre,dc=local" overlay rwm ################################### # # Entrada LDAP para FIVE # ################################### uri "ldap://1.2.3.5/ou=FIVE,ou=Usuarios,dc=ldapproxy-pre,dc=local" readonly yes lastmod off suffixmassage "ou=FIVE,ou=Usuarios,dc=ldapproxy-pre,dc=local" "dc=FIVE,dc=local" idassert-bind bindmethod=simple binddn="CN=USERFIVE,CN=Users,DC=FIVE,DC=local" credentials="???????????????????" mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=manager,dc=ldapproxy-pre,dc=local" overlay rwm

2 1

Help
by A. Yuesuen 09 May '19

09 May '19

Hello, I'm trying to set up an LDAP Replication on two Ubuntu Server. Now i tried to set up the replication using this guide: https://systemausfall.org/wikis/howto/LDAP-Replikation By using this Command: >> ldapmodify -Y EXTERNAL -H ldapi:/// dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: {0}rid=2 provider=ldap://192.168.XX.YY type=refreshOnly bindmethod=simple binddn="cn=syncagent,dc=EXAMPLE,dc=COM" credentials=PASSWORD interval="00:00:03:00" retry="30 10 300 +" timeout=1 tls_reqcert=never schemachecking=off searchbase="dc=EXAMPLE,dc=COM" << *i got this Message:ldapmodify: invalid format (line 5) entry: 'olcDatabase={1}hdb,cn=config* i have this Data in my slapd file /etc/ldap/slapd.d/cn=config 'cn=module{0}.ldif' 'olcDatabase={0}config.ldif' 'cn=schema' 'olcDatabase={-1}frontend.ldif' 'cn=schema.ldif' 'olcDatabase={1}hdb' 'olcBackend={0}hdb.ldif' 'olcDatabase={1}hdb.ldif' 'olcDatabase={0}config' Thank you for you help best wishes Ajdar Yüsün

2 1

Open LDAP - How to define an additionnal "uid" like attribute equivalent to a RDMS unique key index
by pascal.foulon＠orange.com 02 May '19

02 May '19

Hi all 1) The context My team is working on a corporate directory using Open LDAP 2.4.38, managing about 200,000 employees. Each employee is constructed using a specific object class named ftperson, based on parent object class inetOrgPerson All the ftperson objects are are stored in an branch named ou=people . We use the standard uid attribute for he RDN 's ftperson object to identify an employee. So far, the full DN of an employee is something like : uid=CUID,ou=people,dc=intrannuaire,dc=orange,dc=com with CUID representing an alphanumeric string Precision : the CUID value is precalculated and provisioned by another corporate identity management system that checks and ensures the CUID value is unique. We have a new requirement consisting of adding an additionnal "uid" like attribute named xuid The value of xuid will also precalculated et provisioned by the corporate identity management system that will check and ensure the xuid value is unique. At first, we have choosen to simply add a new attribute to the ftperson object structrure using the following attribute definition : olcAttributeTypes: {76}( ORANGE-AT:77 NAME 'xuid' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) 2) My question We'd like to harden the xuid management policy on our Open LDAP server by adding an unicity constraint rule for the xuid attribute equivalent to a RDMS unique key index. I've found and read several LDAP documentations including : => uid attribute définition https://ldapwiki.com/wiki/0.9.2342.19200300.100.1.1 => extented flags https://ldapwiki.com/wiki/Extended%20Flags I've tried several configurations such as : - define xuid attribute using uid as a parent attribute type olcAttributeTypes: {76}( ORANGE-AT:77 NAME 'xuid' SUP uid EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) - define xuid attribute using uid as a parent attribute type with additional extended flags olcAttributeTypes: {76}( ORANGE-AT:77 NAME 'xuid' SUP uid EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE X-NDS_NAME 'uniqueID' X-NDS_LOWER_BOUND '1' X-NDS_UPPER_BOUND '64' X-NDS_PUBLIC_READ '0' X-NDS_NONREMOVABLE '0' ) Where injecting the modified configurations , the Open LDAP server seems to accept them (no error message). When we add the xuid attribute to an existing ftperson object, it works But the same xuid value can be set for different ftperson objects and so, the unicity constraint rule for xuid is not respected. :-( Any idea that idea that could help to fix this issue ? Regards [logo Orange]<http://www.orange.com/> Pascal Foulon Concepteur Développeur Responsable Technique / MOE portail Intranet France Mobile Expert technique VMPAL-E / Quartz / Web Admin / IFM / Annuaire Groupe Orange/TGI/OLS/SOFT/IDF-NANCY/DPI fixe : +33 3 90 31 25 79 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.…> mobile : +33 6 82 57 28 73 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.…> pascal.foulon(a)orange.com<mailto:pascal.foulon@orange.com> EDS Océane 58H « Annuaire Groupe » : BJC031 EDS Océane IFM « Intranet France Mobile » : BJC038 _________________________________________________________________________________________________________________________ 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.

4 3

Multiple memberOf overlays
by John C. Pfeifer 29 Apr '19

29 Apr '19

I am in the process of converting an existing LDAP infrastructure to OpenLDAP. I have a case where it would be convenient for two different objectClasses to map into the memberOf attribute. Is it possible to define two overlay configs or will they end up fighting each other over the memberOf attribute? For instance: dn: olcOverlay={5}memberofA,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {5}memberofA olcMemberOfDangling: error olcMemberOfRefInt: FALSE olcMemberOfGroupOC: objectClassA olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf dn: olcOverlay={6}memberofB,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {6}memberofB olcMemberOfDangling: error olcMemberOfRefInt: FALSE olcMemberOfGroupOC: objectClassB olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf // John Pfeifer Division of Information Technology University of Maryland, College Park

2 1

Re: OpenLdap with Zimbra Objectclasses
by Quanah Gibson-Mount 25 Apr '19

25 Apr '19

--On Thursday, April 25, 2019 3:49 PM +0200 Aidar Y�s�n <ajdar.yuesuen(a)in-factory.com> wrote: > Hello, > > Thanks for you help. I installed Zimbra the latest version but i couldn't > finde a Schema Data. Is there a other way? Hello, Please keep replies on the list if you would like assistance. You will need to search harder, as Zimbra always installs the schema file on a zimbra LDAP node. You may want to read over the zmldapschema script, particularly the "installZimbraSchema" function in that script, which clearly denotes where the schema file lives in the deployment. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

reverse search in dymanic group ?
by Olivier - 25 Apr '19

25 Apr '19

Hi all, I'm testing static group and dynamic group. * Dynmaic group : is it possible to do reverse search in dynamic group ? I reead something about the "ismemberof" attribute and ds-virtual-static-group. But i'm not sure we can do it with openldap * Static group seems to be fine for me. I have a newbie's question : can we have , for example, the mail attribute of all members of service Y in only one request ? I mean : make a request on service Y to have member's list and , in the same action , have the member's mail. Thanks all.

3 5

Implementing additional passwords with limited scope / "app passwords"
by Christoph Biedl 24 Apr '19

24 Apr '19

Hello, looking for a way to implement alternative passwords for a given object (i.e. account information). The tricky part, such passwords should not be usable in every application but e.g. for mail access only, not for interactive login. Such a feature can be seen in the nextcloud application where such "app passwords" may be unusable for accessing files while the calendar can still be read and written. The idea behind this is obviously being able to store such a password on a mobile device that might got stolen or lost otherwise - without compromising all other services the account credentials are be valid for. The global (or default) password should still be usable in any place - although users should avoid that. The "restriction to an application" logic could possibly be implemented using an attribute I'd call "capability", but I have no clue how to handle the passwords. Findings so far: It is possible to store more than one userPassword in an account object, but now I cannot see how to tell apart which of the ones was used for successful binding, and I reckon this is not possible at all in a sane way. Enhancing the schema I might store the the extra password/capabilities combos in separate objects. But this creates the question how to deal with applications that don't allow to enter the entire request string. Another idea I could think of was to have separate objects ("cn=john.doe", "cn=john.doe+login") - but I consider that ugly. Other ideas? Or even solutions that already exist? Christoph

2 1

OpenLdap with Zimbra Objectclasses
by Aidar Y�s�n 24 Apr '19

24 Apr '19

Hello, I'm trying to import Data to my Server and need for the the Entries Objectclasses wich contains Zimbra Attributes. Is there a way to implement a Schema which include Zimbra Objectclasses? best wishes Ajdar

2 1

Is there any directory server in public use?
by Tankman 六四 23 Apr '19

23 Apr '19

Hi everyone Can you give an example of directory server used by governments or certain authorities as to the source of truth? E.g. whether or not the person named so exists, or whether or not the land registered at certain street address belong to a Mr Smith? I'm asking for this because I'm researching how the source of truth is made publically available in a public database with a set of open query method (like openldap filter) before the invention of blockchain. I personally also want to see such effort being made by willing authorities. Thanks in advance!

4 3

[lmdb] Potential side effects of changing the MAXKEYSIZE?
by Claude Brisson 23 Apr '19

23 Apr '19

Hi. What would be the possible harmful side effects, under linux, of changing MDB_MAXKEYSIZE from 511 to, let say, 100000 ? -- Claude

2 1

Experimenting with a password plugin
by dee heffem 17 Apr '19

17 Apr '19

Is there a way to obtain the username (CN or UID attribute?) being authenticated when a LUTIL_PASSWD_CHK_FUNC function is called? I'd like to call a 2FA provider from within a password plugin but not sure how to get the user tied to the sc, passwd, or cred bervals. Thanks

4 7

Re: Strange slapadd behavior
by Ezsra McDonald 15 Apr '19

15 Apr '19

Yes, I did!! Thank you for the assistance everyone. -Ez On Mon, Apr 15, 2019 at 2:49 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Monday, April 15, 2019 3:44 PM -0500 Ezsra McDonald > <ezsra.mcdonald(a)gmail.com> wrote: > > > I figured it out. I had missed a attribute when I built my root object. > > Hi Ezsra, > > Glad you got it figured out! Hopefully you migrated the configuration > over > to using the new LMDB based backend (back-mdb) during the process. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Strange slapadd behavior
by Ezsra McDonald 15 Apr '19

15 Apr '19

We were hoping to carry over all the operational attributes associated with objects in the LDAP. If I remember correctly, ldapadd will not apply operational attributes. On Mon, Apr 15, 2019 at 11:31 AM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Monday, April 15, 2019 9:17 AM -0500 Ezsra McDonald > <ezsra.mcdonald(a)gmail.com> wrote: > > > I am in the process of migrating my OpenLdap 2.3 system to a new OpenLdap > > 2.4 system but something is not working right for the import(slapadd) to > > the new system. There are 35,895 objects defined in the LDIF generated by > > slapcat. > > I would suggest you start with ldapadd to import, rather than slapadd, as > you likely need the additional validation steps initially when doing the > migration from 2.3 to 2.4. > > I'd also avoid using RH's native packages and use a current release. The > LTB project and Symas both provide free alternatives to RH's builds. > > <https://ltb-project.org/download#openldap> > <https://repo.symas.com/sofl/rhel7/> > > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

3 5

Strange slapadd behavior
by Ezsra McDonald 15 Apr '19

15 Apr '19

I am in the process of migrating my OpenLdap 2.3 system to a new OpenLdap 2.4 system but something is not working right for the import(slapadd) to the new system. There are 35,895 objects defined in the LDIF generated by slapcat. RPM: openldap-servers-2.4.44-21.el7_6.x86_64 Example: Importing the following object by slapadd: dn: cn=demokag,ou=Groups,dc=somewhere,dc=org *cn*: demokag *description*: KAG Demo *owner*: cn=manager,dc=somewhere,dc=org objectClass: top objectClass: groupOfUniqueNames *uniqueMember*: uid=sombody,ou=People,dc=somewhere,dc=org *uniqueMember*: uid=somebodyelse,ou=People,dc=somewhere,dc=org structuralObjectClass: groupOfUniqueNames entryUUID: 78450864-a24e-1030-9086-8baf95aed3fc creatorsName: cn=Manager,dc=somewhere,dc=org createTimestamp: 20111113142106Z entryCSN: 20121116140519Z#000000#00#000000 modifiersName: cn=Manager,dc=somewhere,dc=org modifyTimestamp: 20121116140519Z Produces this object: dn: cn=demokag,ou=groups,dc=somewhere,dc=org *givenName*: demokag *owner*: KAG Demo *uniqueMember*: cn=manager,dc=somewhere,dc=org objectClass: top objectClass: groupOfUniqueNames *gidNumber*: uid=somebody,ou=People,dc=somewhere,dc=org *gidNumber*: uid=somebodyelse,ou=People,dc=somewhere,dc=org structuralObjectClass: groupOfUniqueNames entryUUID: 78450864-a24e-1030-9086-8baf95aed3fc creatorsName: cn=Manager,dc=somewhere,dc=org createTimestamp: 20111113142106Z entryCSN: 20121116140519Z#000000#00#000000 modifiersName: cn=Manager,dc=somewhere,dc=org modifyTimestamp: 20121116140519Z 1. I bolded the impacted attributes. 2. I am unable to do ldapsearch for this object. I believe this is because the cn is being replaced with givenName. 3. Spot checking it appears this is happening to all of the objects under the groups OU. Maybe other object types are bad too. I do not know yet. I have been beating my head on this for several days.Any help would be appreciated.

3 2

Help
by A. Yuesuen 15 Apr '19

15 Apr '19

hello, i'm trying to implement Ssha512 on my openldap server. i found out that the Building concepts on the www are old. there are nor slapd.conf file. So there is written i have to work with the cn=config file cause. Can someone help me please? I'm using ubuntu 18.10 and the openldap version slapd. Thank you best wishes Ajdar yüsün

3 2

Quick question about OpenLDAP Server CA certificate handling
by Mark Cairney 15 Apr '19

15 Apr '19

Hi, Having just updated our SSL certificates on our OpenLDAP server led us to review the contents of our "bundle" file referenced in "olcTLSCACertificateFile". According to the documentation at: https://www.openldap.org/doc/admin24/tls.html it states "This directive specifies the PEM-format file containing certificates for the CA's that slapd will trust. The certificate for the CA that signed the server certificate must be included among these certificates. If the signing CA was not a top-level (root) CA, certificates for the entire sequence of CA's from the signing CA to the top-level CA should be present. Multiple certificates are simply appended to the file; the order is not significant." However based on our understanding of how SSL works we should only actually need the intermediate(s) in there as the client should have the root and then compare the intermediate provided by the server and only trust it if it can use this in conjunction with it's copy of the root certificate to complete the chain of trust. Based on this we configure our web servers to only have the intermediate(s) in their chain (and in fact SSL Labs marks you down if you have the root in there too). Of course we do realise LDAP is not HTTP! We're running OpenLDAP 2.4.47 linked against OpenSSL on Scientific Linux 7.5. Kind regards, Mark -- /**************************** Mark Cairney ITI Enterprise Services Information Services University of Edinburgh Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk PGP: 0x435A9621 *******************************/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

3 3

strange regexp behaviour
by Dieter Kluenter 15 Apr '19

15 Apr '19

Hi, I face a strange behaviour of a authz regexp. This is part of my slapd.conf authz-regexp "gidNumber=(.*)\+uidNumber=(.*),cn=peercred,cn=external,cn= auth" "ldap:///o=avci,c=de?dn?sub?(&(uidNumber=$2)(gidNumber=$1))" The result of a ldapwhoami: SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth A result of search ldapsearch -Y EXTERNAL -H ldapi:/// -b o=avci,c=de -s sub "(&(gidNumber=100)(uidNumber=1000))" dn dn: cn=Dieter Kluenter,ou=Partner,o=avci,c=de result: 0 Success This regexp has been working for ages, in fact it hasn't been changed since Ando's first announcement. Any idea what might have been changed? -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

2 2

changes in libldap?
by Dieter Kluenter 15 Apr '19

15 Apr '19

Hi, I face some more strange error reports from some updated tools. There is for example ldapfuse, introduced in 2011, built with ldd /usr/bin/ldapfuse linux-vdso.so.1 (0x00007ffe8c92a000) libHX.so.28 => /usr/lib64/libHX.so.28 (0x00007fdf144de000) libfuse.so.2 => /lib64/libfuse.so.2 (0x00007fdf1449d000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007fdf1448c000) libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007fdf14436000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdf14415000) libc.so.6 => /lib64/libc.so.6 (0x00007fdf14250000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fdf14249000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fdf14230000) libsasl2.so.3 => /usr/lib64/libsasl2.so.3 (0x00007fdf14211000) libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007fdf141a3000) libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007fdf13f17000) /lib64/ld-linux-x86-64.so.2 (0x00007fdf1451f000) libz.so.1 => /lib64/libz.so.1 (0x00007fdf13efb000) § ldapfuse ldap://localhost ~/adbook Unhandled LDAP error code -1 LDAP Can't contact LDAP server Even gcc doesn't produce more information :-) What has been changed in libldap? -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

3 5

Help
by A. Yuesuen 15 Apr '19

15 Apr '19

Hello, When i try the Instruction on following page: https://github.com/winlibs/openldap/tree/master/contrib/slapd-modules/passw… i missed I'm not sure with point 1. and i can run the make function. Is there a example with pictures? Or could you please explain me easier how i can implement the sha2 / SSHA512 modul? Hope you can help me. Thank you in advance. best wishes Ajdar Yüsün

1 0

Re: Question about OID / feedback on schema
by Mikael Bak 10 Apr '19

10 Apr '19

Hi, On 2019. 04. 06. 21:19, Harry Jede wrote: > Am 05.04.19 um 16:36 schrieb Michael Ströder: >> You need to register an IANA enterprise ID to obtain your own OID space. >> >> AFAIK there is no OID space reserved for private use. > > Both statements are true. > > But Mikael Bak says that he wont register his organization. OK, if > someting goes wrong with the registered oid space, your company may get > reputation problems. That is what people told often to me. > I actually said that I would like to avoid it, if possible. I forsee a lot of paper work here to get this done properly. > The solution is register an oid for a private person aka Mikael Bak. If > all is Ok and everyone feels good transfer the registerd oid to your > company or register a new oid and modify your schema to match the new oid. > Since there seems to be no concept of private OID space, then I will start the procedure to register the Hungarian National Library with IANA to obtain OID number. Thank you all! Mikael

2 2

OID for ASN.1 type BinaryTime
by Weiwu Zhang 09 Apr '19

09 Apr '19

HI: RFC4049 recommended a type BinaryTime - like GeneralisedTime but for compatibility with older systems. Reading https://tools.ietf.org/html/rfc4049 I couldn't find the OID for this type, despite intensive Google search. Any hint? Thanks a lot!

2 1

Replication delay
by Ángel L. Mateo 08 Apr '19

08 Apr '19

Hello, I've been running a multi master configuration without any problem for years. This running servers are running in 5 ubuntu 14.04 servers with openldap 2.4.43. The configuration is: dn: olcDatabase={3}mdb,cn=config ... olcSyncrepl: {0}rid=31 provider=ldap://canis31.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1 olcSyncrepl: {1}rid=32 provider=ldap://canis32.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1 olcSyncrepl: {2}rid=33 provider=ldap://canis33.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1 olcSyncrepl: {3}rid=34 provider=ldap://canis34.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1 dn: olcOverlay={0}dynlist,olcDatabase={3}mdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {0}dynlist olcDlAttrSet: {0}labeledURIObject labeledURI dn: olcOverlay={1}ppolicy,olcDatabase={3}mdb,cn=config objectClass: olcPPolicyConfig objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {1}ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=Telematica dn: olcOverlay={2}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {2}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 where each server has 4 olcSyncrepl attributes pointing to the other servers. I had no problem with this configuration for years Now I'm deploying an update of these servers in a new ubuntu 18.04 server with openldap 2.4.47. In order to synchronize entries between them, I have linked this new server to one of the other (and this one to the new one). Configuration in the new one (named canis41) is: dn: olcDatabase={3}mdb,cn=config ... olcSyncrepl: {0}rid=39 provider=ldap://canis39.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="60 +" timeout=1 schemache cking=off scope=sub olcSyncrepl: {1}rid=42 provider=ldap://canis42.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="30 +" timeout=1 logbase=" cn=log" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemaCh ecking=on syncdata=accesslog exattrs="pwdFailureTime" dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 dn: olcOverlay={1}ppolicy,olcDatabase={3}mdb,cn=config objectClass: olcPPolicyConfig objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {1}ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=Telematica dn: olcOverlay={2}dynlist,olcDatabase={3}mdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {2}dynlist olcDlAttrSet: {0}labeledURIObject labeledURI where canis39 is one the former servers and canis42 is a new server too synchronizing just with canis41. My problem is that synchronization is working, but sometimes modifications done in the canis3x farm are delayed a lot of time until they are replicated to the new one (sometimes in the order of 40-60 minutes). I'm logging sync logs, but I haven't found much information about these logs. Is there any way to debug it? How? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868889150 Fax: 868888337

7 34

"Authentication failure" on Ubuntu 18.04...
by Robert Heller 07 Apr '19

07 Apr '19

I have a server running CentOS 6 on the bare metal, running the stock CentOS 6 OpenLDAP packages (openldap-2.4.40-16.el6.x86_64, openldap-clients-2.4.40-16.el6.x86_64, openldap-2.4.40-16.el6.i686, openldap-servers-2.4.40-16.el6.x86_64) [yes I know these are old, but they *work* -- "If it ain't broke, don't fix it."]. There are two VMs running on this server, one running Ubuntu 14.04 and the other Ubuntu 18.04. (These two VMs are/will be servers for DRBL.) The Ubuntu 14.04 VM (and all of its diskless clients) are perfectly happy to talk to the OpenLDAP server (slapd) running on the CentOS 6 machine. The Ubuntu 18.04 VM is not. ldapsearch works everywhere though, so it is NOT the server or the core ldap libraries on any of the machines (partitularly the Ubuntu 18.04 VM). I can only assume that there is something fishy with nslcd or the pam/ldap libraries or config on the Ubuntu 18.04 VM. I have checked everything, but I am coming up empty. I am thinking there might be some "trick" to getting LDAP Authentication to work under Ubuntu 18.04 that I am missing. -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

2 2

Question about OID / feedback on schema
by Mikael Bak 05 Apr '19

05 Apr '19

Hi list, After a previous discussion on this list[1] I've decided to define an object class and some attributes of my own to be able to turn users on/off and to be able to have their subscriptions expire. I got a lot of help from Michael Ströder, who pointed me in the right direction. Thank you for that! What I have so far looks like this: #objectidentifier oszkSchema x-hu-OSZK objectidentifier oszkSchema 1.3.6.1.4.1.4203.666 objectidentifier oszkAttrs oszkSchema:3 objectidentifier oszkOCs oszkSchema:4 attributetype ( oszkAttrs:1 NAME 'oszkAccountActive' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) attributetype ( oszkAttrs:2 NAME 'oszkAccountExpire' SINGLE-VALUE EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) objectclass ( oszkOCs:1 NAME 'oszkPerson' DESC 'OSZK person' SUP inetOrgPerson MUST ( oszkAccountActive ) MAY ( oszkAccountExpire ) ) My question is what I can use for OID in the beginning of the file? I tried to use a private name (beginning with "x-" as described here: http://www.openldap.org/doc/admin24/schema.html That did not work. Using the numeric OID above works, but I'm not sure what numbers are safe to use. This schema is going to be local on one server for the time being. So my question is: Is there a way to know what OID's I can use for private/local use only. I would like to avoid registering my organization with IANA fo now. I did not find that information in the above document. If I missed it and it's there, then I appologize. Secondly, if you find any errors or potential problems with my schema, then please let me know. I'm an LDAP beginner. TIA, Mikael [1] http://www.openldap.org/lists/openldap-technical/201904/msg00006.html

2 1

idassert-authzFrom: Proper way to include only non-anonymous binds
by Patrik Lundin 05 Apr '19

05 Apr '19

Hello, What is the proper way to make sure only non-anonymous binds are allowed to utilize idassert-bind credentials? Reading http://www.openldap.org/faq/data/cache/532.html the following is stated: === Authorize only non-anonymous: idassert-authzFrom "dn:*" === It also states: === The idassert-authzFrom mechanism controls whether a client's identity can be asserted or not. The idassert-authzFrom mechanism basically selects what identities can access the identity assertion feature, and indeed should be considered as the set of values of the authzFrom attribute associated to the administrative identity, with the essential difference that, if not present, by default every identity is authorized, including anonymous. === These excerpts makes me believe that the expected default behaviour is that a missing idassert-authzFrom will allow anyone, even anonymous binds. That a pattern of "*" is supposed to match non-anon binds is also stated in the slapd.conf man page (https://linux.die.net/man/5/slapd.conf): === A pattern of * means any non-anonymous DN. === Then there is this contradictory message I found while looking through the lists: https://www.openldap.org/lists/openldap-technical/200809/msg00096.html It states: === If you want idassert to work also for anonymous operations (not recommended, as this defeats the security model of the remote server, by letting it believe that the proxy authenticated users while it didn't), you need to explicitly enable it using an idassert-authzFrom rule that includes anonymous, like idassert-authzFrom "dn.regex:.*" === This is more in line with my tests, where removing the "idassert-authzFrom" all together stops an anonymous ldapsearch from returning a result, while adding 'idassert-authzFrom "dn:*"' makes it return results for the anon bind. I realize there is a difference between the the line from the FAQ ("dn:*") and the line from the mailing list ("dn.regex:.*") but looking at slap_idassert_authzfrom_parse(): https://github.com/openldap/openldap/blob/b06f5b0493937fc28f2cc86df1d7f464a… ... it appears to me that "*", "dn:*" and "dn.regex:.*" are supposed to be equivalent. I am using the meta backend, but I'm guessing they are sharing code in this case. The man page for slapd-meta does not state what the result of not configuring a "idassert-authzFrom" is though it seems to yield the results I want (that only properly authenticated connections can make use of the idassert-bind credentials). I'm guessing one way to make sure only authenticated clients can do anything is to add "require authc" to the config, but it is hard to tell how these things interact, and it would be nice to know what the expected way to configure idassert-authzFrom is (even if it means leaving it unset). Regards, Patrik Lundin

2 2

Re: Question: n-way multimaster syncrep cn=config and tree
by Dave Macias 04 Apr '19

04 Apr '19

Thank you very much Quanah for your response! > Sort of. If you added the schema and then an object, the other masters > should halt replication at that point until they have a matching schema. That's interesting. > Not really, no. It does depend on the version of OpenLDAP in use, as > there > were some bugs in older OpenLDAP versions that would allow the object to > partially replicate or the object to just get skipped, which could cause > headache. But those issues were fixed. > So then best practice with tree sync is add the schema to all masters first, then an object. which would make sense. > I would say that by doing cn=config replication, you've added a wide > surface area for new issues to occur. I generally view cn=config > replication as more of a beta feature. There are still ongoing issues > being resolved and fixed for it (For example, ITS#8616 in the most recent > 2.4.47 release) Hmm... so would you recommend removing the replication of cn=config for now? Individually adding the schema to each master is feasible for us. Thank you again -Dave

3 4

Re: Help needed: "glued" object.
by Alex Hebra 04 Apr '19

04 Apr '19

Hi Quanah, Thanks for your answer. Here are the details asked: OpenLDAP version 2.4.46. Mirror configuration on node A: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # Global section serverID 1 # database section # syncrepl directive syncrepl rid=001 provider=ldaps://02.host.com bindmethod=simple binddn="cn=root,dc=xxx" credentials=xxx searchbase="dc=xxx" schemachecking=on type=refreshAndPersist retry="10 +" tls_cacert=/usr/local/etc/openldap/cert/cert02.crt mirrormode on Mirror configuration on node B: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # Global section serverID 2 # database section # syncrepl directive syncrepl rid=001 provider=ldaps://01.host.com bindmethod=simple binddn="cn=root,dc=xxx" credentials=xxx searchbase="dc=xxx" schemachecking=on type=refreshAndPersist retry="10 +" tls_cacert=/usr/local/etc/openldap/cert/cert01.crt mirrormode on Thank you very much. On Tue, Apr 2, 2019 at 7:02 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, April 02, 2019 4:59 PM -0300 Alex Hebra <hebraalex(a)gmail.com> > > wrote: > > > > > > > Hi there, > > > > > > I have a very critical OpenLDAP environment running on mirror mode > > configuration. Is has about 800.000 users. > > Hello, > > You failed to provide any information on the release of OpenLDAP you are > using and did not provide any information on the replication mechanism in > use. By the sound of it, you are using standard syncrepl, where this sort > of problem is not uncommon, particularly with older versions of OpenLDAP. > I would suggest you start by noting the version of OpenLDAP in use and > providing information on the setup and configuration of the multimaster > nodes. > > Regards, > Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

5 9

Re: Question: n-way multimaster syncrep cn=config and tree
by Dave Macias 04 Apr '19

04 Apr '19

Ha! Of course. Thank you for support Best Regards, Dave On Apr 3, 2019, 4:41 PM -0400, Quanah Gibson-Mount <quanah(a)symas.com>, wrote: > --On Wednesday, April 03, 2019 5:27 PM -0400 Dave Macias <davama(a)gmail.com> > wrote: > > > > To which I should add -- And is only being fixed for OpenLDAP 2.5 and > > > later. > > > > ...2.5....any ETA on that? ;) > > "When it's ready"? ;) > > We've been reviewing our development process and are waiting on a writeup > from a project member on a new approach going forward to be debated by the > project team and then implemented as our process for 2.5 and future. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Re: Question: n-way multimaster syncrep cn=config and tree
by Dave Macias 03 Apr '19

03 Apr '19

Got it! Very helpful! Thank you! > >> Hmm... so would you recommend removing the replication of cn=config for > >> now? Individually adding the schema to each master is feasible for us. > > > > If it's not required then yes, I personally would not use it at this > > time. For example, ITS#8286, although it only discusses a single matching > > rule, ended up touching numerous files, and it's directly related to > > using cn=config and cn=config replication > > (< > https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h > > =3add82a3bb30b94afd23ff5e2c00c59ca8a931d8>). > > To which I should add -- And is only being fixed for OpenLDAP 2.5 and > later. > ...2.5....any ETA on that? ;) Best, dave

2 1

SLAMD resurrected (LDAP benchmarking tool)
by Quanah Gibson-Mount 03 Apr '19

03 Apr '19

One of my co-workers pointed this out to me the other day. If benchmarking LDAP is something that interests you: <https://nawilson.com/2019/03/18/so-i-guess-slamd-is-a-thing-again/> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Help needed: "glued" object.
by Alex Hebra 03 Apr '19

03 Apr '19

Hi Quanah, Thank your very much. Your reply is quite clear. After that I made a decision to migrate to delta-sync and to increase my session log (I have 800k users and 2.000.000 of entries). Please take a look on my new config after these changes, and let me know if it's ok: Node A: # Accesslog database definitions database mdb suffix cn=accesslog directory /var/db/openldap-data/accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE ##### # primary db config overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 2000000 # accesslog overlay definitions for primary db overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE # scan the accesslog DB every day, and purge entries older than 7 days logpurge 07+00:00 01+00:00 # Global section serverID 1 # database section # syncrepl directive syncrepl rid=001 provider=ldaps://02.host.com bindmethod=simple binddn="cn=root,dc=xxx" credentials=xxx searchbase="dc=xxx" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="10 +" syncdata=accesslog tls_cacert=/usr/local/etc/openldap/cert/certServerID2.crt mirrormode on Node B: # Accesslog database definitions database mdb suffix cn=accesslog directory /var/db/openldap-data/accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE ##### # primary db config overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 2000000 # accesslog overlay definitions for primary db overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE # scan the accesslog DB every day, and purge entries older than 7 days logpurge 07+00:00 01+00:00 # Global section serverID 2 # database section # syncrepl directive syncrepl rid=001 provider=ldaps://01.host.com bindmethod=simple binddn="cn=root,dc=xxx" credentials=xxx searchbase="dc=xxx" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="10 +" syncdata=accesslog tls_cacert=/usr/local/etc/openldap/cert/certServerID1.crt mirrormode on After that I made a change on Node A and it replicated to node B, then I made a change on node B and it replicated to A. So seems it's working. My doubt is how can I make sure it's working with delta-sync mode? Another question, changing to delta-sync can I use more than 2 nodes, for instance, 3 servers receiving writing and replicating between them? Thank you. On Wed, Apr 3, 2019 at 1:09 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, April 03, 2019 11:14 AM -0300 Alex Hebra > <hebraalex(a)gmail.com> wrote: > > > Thanks for your answer. Here are the details asked: > > > > > > OpenLDAP version 2.4.46. > > > > syncprov-sessionlog 100 > > syncprov-sessionlog 100 > > Hi Alex, > > Your sessionlog value is way too small. It needs to be something a little > larger than the entire size of your database (so > 800,000 in your case). > I also see you're using standard syncrepl rather than delta-syncrepl. > > Generally, having a "glued" object on a server indicates that at some > point, the server was in a REFRESH mode (either you populated the server > using syncrepl instead of slapcat, or it had some reason to fall back to > REFRESH at a later date). > > In the REFRESH mode, the server may get entries "out of order". In this > case, a stub (glue) object is created to "hold" the place for tha entry > until it gets fully replicated. Unfortunately, this doesn't always > happen, > and you end up being stuck with the glued object on the server. > > You may be able to force replication of the object onto the server where > it's missing by doing a MOD op against the affected entry on the master > where it exists. If one master is "complete" (I.e., no glued objects), > you > could also slapcat that master and import the database into the othe > rmaster via slapadd to resolve the problem for now. > > Overally, I strongly advise using delta-syncrepl as it largely avoids > these > issues (as long as it never has to fall back to standard syncrepl REFRESH > mode). > > I would note that there was a fix in OpenLDAP 2.4.47 specific to > delta-syncrepl when ppolicy is in use, so if using delta-sync you likely > want that fix. > > --Quanah > > > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

2 1

Question: n-way multimaster syncrep cn=config and tree
by Dave Macias 03 Apr '19

03 Apr '19

Hello, we recently adjusted our sync from n-way multimaster replication of the tree (searchbase="dc=organization,dc=com") and now included our "cn=config" replication. Some concerns/questions I have: Before with only tree replication, it was my understanding that one could NOT add a new schema along with an object unless said schema already existed in the other masters. yes? Our process was to turn off the sync add the schema to each master then normalize. Probably turning off the sync was unnecessary but just to be safe. Regardless if a new object with new schemas was added then one could ruin all the masters. Correct? Ok, so now with cn=config synchronized as well. Does this issue, if an issue, go away? Also, if upgrading one masters openldap software, should the sync be off? Recommendations? Any input is much appreciated. Thank you, Dave

2 1

Help needed: "glued" object.
by Alex Hebra 03 Apr '19

03 Apr '19

Hi there, I have a very critical OpenLDAP environment running on mirror mode configuration. Is has about 800.000 users. Unfortunately I'm facing some critical issues with OpenLDAP and I don't know if it's an issue with replication or not. After some time I found some objects with glue attribute, sometimes on both sides sometimes in just one side. I's bringing a big problem for me, many users can't auth after that and I can't stop this environment. I'd like to understand what's happening and how I could fix this problem. Any help is welcome. Thank you.

2 1

LMDB, doing the impossible
by Abilio Marques 02 Apr '19

02 Apr '19

Hello everyone, About a week ago, I wrote about moving a piece of software out of writing multiple files and into LMDB. Currently, the software will run on UBIFS (which is unsafe for NOSYNC option). Is multi-threaded and has no concept of transactions. Write operations are spread between threads. It only uses a mutex to avoid multiple writers, and tend to happen in a burst. Storage is implemented by a layer that has a similar API (read, write, delete) to LMDB. My main goal is to replace the guts of this layer with LMDB (while keeping the API), to get an idea on how the program would work. Because of the lack of transaction concept in the current API, my initial approach was to accumulate transactions (after the first sync) for a couple of seconds, and then call env_sync. This solution is not power failure robust because of UBIFS characteristics. I was trying to figure out other solutions that can be put this deferred concept in place, again, with the goal of proving worthiness of a full refactoring of the code in order to properly use LMDB. Any suggestions? Best, Abilio Marques

1 0

Question about ppolicy usage
by Mikael Bak 02 Apr '19

02 Apr '19

Hi list, I realize I'm trying to use the ppolicy overlay a little differently from how it was designed to be used. The problem is that the ppolicy overlay is the closest thing I have found. My use case: 1) I want to be able to disable users. I can do this by setting: pwdAccountLockedTime: 000001010000Z That works. Great! 2) I want to be able to set a date in the future when a user account will expire / deactivate. I was hoping to be able to set "pwdAccountLockedTime" to a date in the future and after that date the user account would be locked. Unfortunately this isn't the case. ppolicy seems to lock out every account that has the "pwdAccountLockedTime" attribute set to a valid value. Reading the source code for ppolicy I find an interesting block in the function "account_locked()" at line 356: /* Still in the future? not yet in effect */ if (now < then) return 0; This leads me to believe that the author's intension may have been to allow what I want to do. Perhaps is there another attribute I need to set in order to tweek ppolicy to do wat I want. Here's how the default policy looks like: dn: cn=passwordDefault,ou=Policies,ou=local objectClass: pwdPolicy objectClass: person objectClass: top cn: passwordDefault sn: passwordDefault pwdAttribute: userPassword pwdCheckQuality: 0 pwdMinAge: 0 pwdMaxAge: 0 pwdMinLength: 0 pwdInHistory: 0 pwdMaxFailure: 0 pwdFailureCountInterval: 0 pwdLockout: TRUE pwdLockoutDuration: 0 pwdAllowUserChange: FALSE pwdExpireWarning: 0 pwdGraceAuthNLimit: 0 pwdMustChange: FALSE pwdSafeModify: FALSE All help greatly appreciated! TIA, Mikael

3 4

RE: mdb_equality_candidates: (entryUUID) not indexed, with olcDbIndex=entryUUID pres, eq
by Marc Roos 02 Apr '19

02 Apr '19

Yes, I have a default hdb slap.d tree setup from the el7 rpm install. I also noticed this olcHdbConfig. I have decided to stick with the hdb for now. -----Original Message----- From: Quanah Gibson-Mount Sent: 02 April 2019 15:37 To: Marc Roos; openldap-technical Subject: RE: mdb_equality_candidates: (entryUUID) not indexed, with olcDbIndex=entryUUID pres, eq --On Tuesday, April 02, 2019 2:48 PM +0200 Marc Roos> wrote: > > Hi Quanah, > > Missed your response, I am not sure if I understand your info request, > so I am sending you these. Thanks for looking. > > dn: olcDatabase={2}mdb > objectClass: olcDatabaseConfig > objectClass: olcHdbConfig The above is clearly an invalid configuration, it looks like you tried to convert from HDB to MDB manually? I doubt slapd is really able to function correctly at all. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: mdb_equality_candidates: (entryUUID) not indexed, with olcDbIndex=entryUUID pres, eq
by Marc Roos 02 Apr '19

02 Apr '19

Hi Quanah, Missed your response, I am not sure if I understand your info request, so I am sending you these. Thanks for looking. [@cn=config]# ls -arlt total 20 -rw------- 1 ldap ldap 378 Mar 30 13:21 cn=schema.ldif -rw------- 1 ldap ldap 562 Mar 30 13:21 olcDatabase={1}monitor.ldif -rw------- 1 ldap ldap 678 Mar 30 14:58 olcDatabase={0}config.ldif drwxr-x--- 2 ldap ldap 284 Mar 30 15:03 cn=schema -rw------- 1 ldap ldap 905 Mar 30 15:04 olcDatabase={-1}frontend.ldif -rw------- 1 ldap ldap 2333 Mar 31 23:42 olcDatabase={2}mdb.ldif [@ cn=config]# cat 'olcDatabase={1}monitor.ldif' # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 ff86e0ea dn: olcDatabase={1}monitor objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=extern al,cn=auth" read by dn.base="cn=Manager,dc=my-domain,dc=com" read by * none structuralObjectClass: olcDatabaseConfig entryUUID: 06b54f3e-e732-1038-8480-f782455a1e70 creatorsName: cn=config createTimestamp: 20190330122101Z entryCSN: 20190330122101.772335Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20190330122101Z [@ cn=config]# head 'olcDatabase={2}mdb.ldif' # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 29266174 dn: olcDatabase={2}mdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap olcDbIndex: objectClass eq,pres olcDbIndex: sendmailMTACluster pres,eq olcDbIndex: sendmailMTAHost pres,eq -----Original Message----- From: Quanah Gibson-Mount Sent: 01 April 2019 16:30 To: Marc Roos; openldap-technical Subject: Re: mdb_equality_candidates: (entryUUID) not indexed, with olcDbIndex=entryUUID pres, eq --On Monday, April 01, 2019 12:53 AM +0200 Marc wrote: > > First time I am installing the slapd with a mdb backend. Could this be > because the syntax has changed? > > I am getting these messages: > > mdb_equality_candidates: (entryUUID) not indexed > > While I have in {2}mdb > > olcDbIndex entryUUID pres,eq What database is in index {1}? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

mdb_equality_candidates: (entryUUID) not indexed
by Marc Roos 02 Apr '19

02 Apr '19

I am getting mdb_equality_candidates: (entryUUID) not indexed While I have [@ slapd.d]# grep entryUU cn\=config/olcDatabase\=\{2\}mdb.ldif olcDbIndex: entryUUID pres,eq entryUUID: 06b55588-e732-1038-8481-f782455a1e70 openldap-servers-2.4.44-21.el7_6.x86_64

1 0

mdb_equality_candidates: (entryUUID) not indexed, with olcDbIndex=entryUUID pres, eq
by Marc Roos 01 Apr '19

01 Apr '19

First time I am installing the slapd with a mdb backend. Could this be because the syntax has changed? I am getting these messages: mdb_equality_candidates: (entryUUID) not indexed While I have in {2}mdb olcDbIndex entryUUID pres,eq CentOS Linux release 7.6.1810 (Core) openldap-clients-2.4.44-21.el7_6.x86_64 openldap-2.4.44-21.el7_6.x86_64 openldap-servers-2.4.44-21.el7_6.x86_64

2 1

back_mdb: does rtxnsize affect slapcat live backups?
by Maxime Besson 01 Apr '19

01 Apr '19

Hi! I am running OpenLDAP 2.4.47 with significant write activity (in the hundreds of modify/add/del ops per second), and a large volume of data compared to available RAM (about 20G) For backups, I am trying to do a live slapcat dump to maintain availability, and encountered the growth in MDB database size described in those ITS: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7904 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8226 I am however a little puzzled over the rtxnsize option. My understanding is that this option splits large read transactions (such as backups) into smaller transactions, allowing freed pages to be reused before the end of the full operation. This is critical for me because backups take more than 10 minutes and a significant portion of my MDB file (100G) gets filled up during that time. However, setting rtxnsize to a smaller value from the default does not seem to have any effect on the growth of my MDB file. I have made several tries with different rtxnsizes from 1M to 100, starting from a freshly rebuilt MDB database every time. I saw that the rtxnsize option was added to handle an issue with replication, so perhaps it was never supposed to help in my particular case. For the whole duration of a slapcat backup, I see the same transaction ID from the slapcat process in mdb_stat -r. I noticed that using ldapsearch for backups behaves much better (MDB only grows by a few thousand pages in my workload), but takes a while longer, regardless of the rtxnsize setting Is it normal that rtxnsize does not affect slapcat dumps while slapd is running, or am I missing something? How would you handle live backups of a database with lots of write activity? -- Maxime Besson Systems Engineer - Worteks maxime.besson(a)worteks.com

5 6

LMDB mdb_txn_begin parent in other thread
by Abilio Marques 29 Mar '19

29 Mar '19

Hello, I read the documentation for the mdb_txn_begin function, and the note reads "a transaction and its cursors must only be used by a single thread". Does this rule also apply to being a parent for another thread transaction? I gave it a quick shot, and it seems to work for me, but I'm not sure if I'm breaking the rules. Can anybody confirm this? Best, Abilio

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical