openldap-technical January 2019

openldap-technical@openldap.org

30 participants
21 discussions

Shared memory error after reboot
by Marc Roos 17 Jan '19

17 Jan '19

I am getting this error after (re)booting, if I restart slapd it is gone. I guess I can ignore this message because slapd will recover from this eventually? Or do I need to give it a restart every time? After reboot: jan 16 14:57:19 mail04 slapd[3283]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 2018 23:14:27) $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap -2.4.44/openldap-2.4.44/servers/slapd Jan 16 14:57:19 mail04 slapd[3283]: syncrepl rid=504 searchbase="dc=backoffice,dc=local": no retry defined, using default Jan 16 14:57:19 mail04 slapd[3285]: bdb(dc=backoffice,dc=local): BDB0118 shmat: id 884736: unable to attach to shared system memory region: Invalid argument Jan 16 14:57:19 mail04 slapd[3285]: hdb_db_open: database "dc=backoffice,dc=local": shared memory env open failed, assuming stale env. Jan 16 14:57:19 mail04 slapd[3285]: slapd starting Jan 16 14:57:20 mail04 slapd[3285]: do_syncrep2: rid=504 LDAP_RES_INTERMEDIATE - REFRESH_DELETE After restart: Jan 16 14:58:59 mail04 slapd[3285]: daemon: shutdown requested and initiated. Jan 16 14:58:59 mail04 slapd[3285]: slapd shutdown: waiting for 1 operations/tasks to finish Jan 16 14:58:59 mail04 slapd[3285]: slapd stopped. Jan 16 14:58:59 mail04 slapd[3402]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 2018 23:14:27) $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap -2.4.44/openldap-2.4.44/servers/slapd Jan 16 14:58:59 mail04 slapd[3402]: syncrepl rid=504 searchbase="dc=backoffice,dc=local": no retry defined, using default Jan 16 14:58:59 mail04 slapd[3404]: slapd starting Jan 16 14:58:59 mail04 slapd[3404]: do_syncrep2: rid=504 LDAP_RES_INTERMEDIATE - REFRESH_DELETE openldap-2.4.44-20.el7.x86_64 openldap-clients-2.4.44-20.el7.x86_64 Linux mail04 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 29 14:49:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux CentOS Linux release 7.6.1810 (Core)

4 5

RE: Shared memory error after reboot
by Marc Roos 16 Jan '19

16 Jan '19

>> >> >> I am getting this error after (re)booting, if I restart slapd it is >> gone. I guess I can ignore this message because slapd will recover from >> this eventually? Or do I need to give it a restart every time? >> >> >> After reboot: >> >> jan 16 14:57:19 mail04 slapd[3283]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 >> 2018 23:14:27) >> $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap >> -2.4.44/openldap-2.4.44/servers/slapd >> Jan 16 14:57:19 mail04 slapd[3283]: syncrepl rid=504 >> searchbase="dc=backoffice,dc=local": no retry defined, using default >> Jan 16 14:57:19 mail04 slapd[3285]: bdb(dc=backoffice,dc=local): BDB0118 >> shmat: id 884736: unable to attach to shared system memory region: >> Invalid argument > >It means: > >a) You're using shared memory regions with a BDB backend >b) That slapd is not cleanly shut down on a reboot. It sounds like perhaps >you have a broken init system. > >I would note that BDB based backends are deprecated. It's advised to use >back-mdb instead. I just did a service slapd stop before a reboot, gives the same. What does Slapd do when "assuming stale env.". Tries it to recover? Jan 16 17:41:47 mail04 slapd[3404]: slapd stopped. ... ... ... Jan 16 17:42:18 mail04 slapd[3286]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 2018 23:14:27) $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap -2.4.44/openldap-2.4.44/servers/slapd Jan 16 17:42:18 mail04 slapd[3286]: syncrepl rid=504 searchbase="dc=backoffice,dc=local": no retry defined, using default Jan 16 17:42:18 mail04 slapd[3288]: bdb(dc=backoffice,dc=local): BDB0118 shmat: id 0: unable to attach to shared system memory region: Invalid argument Jan 16 17:42:18 mail04 slapd[3288]: hdb_db_open: database "dc=backoffice,dc=local": shared memory env open failed, assuming stale env. Jan 16 17:42:18 mail04 slapd[3288]: slapd starting Jan 16 17:42:18 mail04 slapd[3288]: do_syncrep2: rid=504 LDAP_RES_INTERMEDIATE - REFRESH_DELETE

1 0

OpenLDAP Proxy - user authentification problem
by Martin Toth 12 Jan '19

12 Jan '19

Hi all, I am trying to configure OpenLDAP proxy to proxy searches to my 2 (two) different AD servers. I am testing/trying to login as domain user to application that is configured to verify users against this proxy. Context is : - allowed app users from AD1 will be placed to "AllowAPP group" on AD1 - i.e. - CN=AllowAPP,OU=Groups,OU=Something,DC=domain,DC=xy - allowed app users from AD2 will be placed to "AllowAPP group" on AD2 - i.e. - CN=Allow,OU=App,OU=Group,DC=domain2,DC=local - these two groups are be placed in different OUs on both ADs (Active Directories) so special rewriting have to be done on both URIs Problem is that I don't know how to correctly authentificate users. App configuration is that it will allow login only to user which is member of CN=AllowAPP,OU=Groups,DC=grouped,DC=all "virtual” group. All working fine when I am searching group membership of users with ldapsearch. I can find members of both groups by searching virtual group mentioned upper. I suspect there is problem with passing user credentials to one of AD servers that I am proxying to. I am using sAMAccountName as user login. This is debug search base when I am trying to login from app : SRCH base="dc=grouped,dc=all" scope=2 deref=2 filter="(?SAMACCOUNTNAME=test.user)” This is error produced while I am trying to login as user : meta_back_search[0] match="" err=1 (Operations error) text="000004DC: LdapErr: DSID-0C09075A, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1". Am I doing something wrong? Can you advise? I am probably missing something that refers to validating users credentials.. Thanks, BR, Martin This is my configuration so far : database meta suffix "dc=grouped,dc=all” rootdn "cn=admin,dc=grouped,dc=all” rootpw "password” readonly yes lastmod off uri ldap://AD1/dc=grouped,dc=all suffixmassage "dc=grouped,dc=all" "dc=domain,dc=xy" idassert-bind bindmethod=simple binddn="CN=bind,CN=Users,dc=domain,dc=xy" credentials="password" mode=none flags=non-prescriptive rewriteEngine on chase-referrals yes rewriteContext default rewriteContext searchBase rewriteRule "CN=AllowAPP,OU=Groups,DC=grouped,DC=all$" "CN=AllowAPP,OU=Groups,OU=Something,DC=domain,DC=xy" "@" uri ldap://AD2/dc=grouped,dc=all suffixmassage "dc=grouped,dc=all" "dc=domain2,dc=local" idassert-bind bindmethod=simple binddn="CN=binduser,CN=Users,dc=domain2,dc=local" credentials=“password" mode=none flags=non-prescriptive rewriteEngine on chase-referrals yes rewriteContext default rewriteContext searchBase rewriteRule "CN=AllowAPP,OU=Groups,DC=grouped,DC=all$" "CN=Allow,OU=App,OU=Group,DC=domain2,DC=local" "@"

1 0

Switch OpenLDAP backend database from HDB to MDB
by SHarbich＠t-online.de 12 Jan '19

12 Jan '19

Hello my dears, I have a question about my approach. I want to migrate the backend database of my OpenLDAP server from HDB to MDB. I would do this as follows: Backup my LDAP nice slapcat -n 0 > ${BACKUP_PATH}/config.ldif nice slapcat -n 1 > ${BACKUP_PATH}/meinedomain.local.ldif cp -rp /var/lib/ldap /var/lib/ldap.bak cp -rp /etc/ldap/slapd.d /etc/ldap/slapd.d.bak Modify entries in these two dates with a text editor from hdb to mdb. Stop the OpenLDAP service sudo systemctl stop sldap.service Delete the directories of the LDAP tree rm -r /var/lib/ldap /etc/ldap/slapd.d Rebuild the LDAP database sudo dpkg-reconfigure slapd In the options select the database MDB and leave everything else as before. Then restore the LDAP tree. sudo slapadd -F /etc/ldap/slapd.d -n 0 -l ${BACKUP_PATH}/config.ldif sudo slapadd -F /etc/ldap/slapd.d -n 1 -l ${BACKUP_PATH}/meinedomain.local.ldif Restart the OpenLDAP service sudo systemctl restart slapd.service That should have been my opinion. Can you think of something else I have to pay attention to? Greetings from Stefan Harbich

2 1

Add supportedExtensions to LDAP proxy
by Philip Brusten 11 Jan '19

11 Jan '19

Hi We have set up an LDAP proxy (slapd-ldap) in front of a NetIQ eDirectory. The LDAP-client which connects to the proxy uses an extended operation, but the request fails because the proxy is not aware of this extension: do_extended: unsupported operation "2.16.840.1.113719.1.39.42.100.... RESULT tag=120 err=2 text=unsupported extended operation # ldapsearch -H ldaps://proxy:port -b '' -s base -D <snip> -W -LLL supportedExtension Enter LDAP Password: dn: supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 Whereas the NetIQ eDirectory back-end supports lots of custom NetIQ extensions: # ldapsearch -H ldaps://backend:port -b '' -s base -D <snip> -W -LLL supportedExtension Enter LDAP Password: dn: supportedExtension: 2.16.840.1.113719.1.39.42.100.1 supportedExtension: 2.16.840.1.113719.1.39.42.100.3 supportedExtension: 2.16.840.1.113719.1.39.42.100.5 supportedExtension: 2.16.840.1.113719.1.39.42.100.7 supportedExtension: 2.16.840.1.113719.1.39.42.100.9 supportedExtension: 2.16.840.1.113719.1.39.42.100.11 supportedExtension: 2.16.840.1.113719.1.39.42.100.13 supportedExtension: 2.16.840.1.113719.1.39.42.100.15 supportedExtension: 2.16.840.1.113719.1.39.42.100.17 supportedExtension: 2.16.840.1.113719.1.39.42.100.19 supportedExtension: 2.16.840.1.113719.1.39.42.100.21 supportedExtension: 2.16.840.1.113719.1.39.42.100.23 supportedExtension: 2.16.840.1.113719.1.39.42.100.25 supportedExtension: 2.16.840.1.113719.1.39.42.100.27 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 2.16.840.1.113719.1.39.42.100.29 supportedExtension: 2.16.840.1.113719.1.14.100.1 supportedExtension: 2.16.840.1.113719.1.14.100.3 supportedExtension: 2.16.840.1.113719.1.14.100.5 supportedExtension: 2.16.840.1.113719.1.14.100.7 supportedExtension: 2.16.840.1.113719.1.14.100.9 supportedExtension: 2.16.840.1.113719.1.14.100.11 supportedExtension: 2.16.840.1.113719.1.14.100.13 supportedExtension: 2.16.840.1.113719.1.14.100.15 supportedExtension: 2.16.840.1.113719.1.14.100.17 supportedExtension: 2.16.840.1.113719.1.14.100.21 supportedExtension: 2.16.840.1.113719.1.14.100.23 supportedExtension: 2.16.840.1.113719.1.14.100.25 supportedExtension: 2.16.840.1.113719.1.14.100.27 supportedExtension: 2.16.840.1.113719.1.14.100.29 supportedExtension: 2.16.840.1.113719.1.14.100.31 supportedExtension: 2.16.840.1.113719.1.14.100.33 supportedExtension: 2.16.840.1.113719.1.14.100.35 supportedExtension: 2.16.840.1.113719.1.14.100.37 supportedExtension: 2.16.840.1.113719.1.14.100.39 supportedExtension: 2.16.840.1.113719.1.14.100.41 supportedExtension: 2.16.840.1.113719.1.14.100.43 supportedExtension: 2.16.840.1.113719.1.14.100.45 supportedExtension: 2.16.840.1.113719.1.14.100.47 supportedExtension: 2.16.840.1.113719.1.14.100.49 supportedExtension: 2.16.840.1.113719.1.14.100.51 supportedExtension: 2.16.840.1.113719.1.14.100.53 supportedExtension: 2.16.840.1.113719.1.14.100.55 supportedExtension: 2.16.840.1.113719.1.14.100.57 supportedExtension: 2.16.840.1.113719.1.14.100.59 supportedExtension: 2.16.840.1.113719.1.14.100.61 supportedExtension: 2.16.840.1.113719.1.14.100.63 supportedExtension: 2.16.840.1.113719.1.14.100.65 supportedExtension: 2.16.840.1.113719.1.14.100.67 supportedExtension: 2.16.840.1.113719.1.14.100.69 supportedExtension: 2.16.840.1.113719.1.14.100.71 supportedExtension: 2.16.840.1.113719.1.14.100.73 supportedExtension: 2.16.840.1.113719.1.14.100.75 supportedExtension: 2.16.840.1.113719.1.14.100.77 supportedExtension: 2.16.840.1.113719.1.14.100.79 supportedExtension: 2.16.840.1.113719.1.14.100.81 supportedExtension: 2.16.840.1.113719.1.14.100.19 supportedExtension: 2.16.840.1.113719.1.14.100.83 supportedExtension: 2.16.840.1.113719.1.14.100.85 supportedExtension: 2.16.840.1.113719.1.14.100.87 supportedExtension: 2.16.840.1.113719.1.14.100.89 supportedExtension: 2.16.840.1.113719.1.14.100.91 supportedExtension: 2.16.840.1.113719.1.14.100.93 supportedExtension: 2.16.840.1.113719.1.148.100.1 supportedExtension: 2.16.840.1.113719.1.148.100.3 supportedExtension: 2.16.840.1.113719.1.148.100.5 supportedExtension: 2.16.840.1.113719.1.148.100.7 supportedExtension: 2.16.840.1.113719.1.148.100.9 supportedExtension: 2.16.840.1.113719.1.148.100.11 supportedExtension: 2.16.840.1.113719.1.148.100.13 supportedExtension: 2.16.840.1.113719.1.148.100.15 supportedExtension: 2.16.840.1.113719.1.148.100.17 supportedExtension: 2.16.840.1.113719.1.27.100.1 supportedExtension: 2.16.840.1.113719.1.27.100.3 supportedExtension: 2.16.840.1.113719.1.27.100.5 supportedExtension: 2.16.840.1.113719.1.27.100.7 supportedExtension: 2.16.840.1.113719.1.27.100.11 supportedExtension: 2.16.840.1.113719.1.27.100.13 supportedExtension: 2.16.840.1.113719.1.27.100.15 supportedExtension: 2.16.840.1.113719.1.27.100.17 supportedExtension: 2.16.840.1.113719.1.27.100.19 supportedExtension: 2.16.840.1.113719.1.27.100.21 supportedExtension: 2.16.840.1.113719.1.27.100.23 supportedExtension: 2.16.840.1.113719.1.27.100.25 supportedExtension: 2.16.840.1.113719.1.27.100.27 supportedExtension: 2.16.840.1.113719.1.27.100.29 supportedExtension: 2.16.840.1.113719.1.27.100.31 supportedExtension: 2.16.840.1.113719.1.27.100.33 supportedExtension: 2.16.840.1.113719.1.27.100.35 supportedExtension: 2.16.840.1.113719.1.27.100.37 supportedExtension: 2.16.840.1.113719.1.27.100.39 supportedExtension: 2.16.840.1.113719.1.27.100.41 supportedExtension: 2.16.840.1.113719.1.27.100.96 supportedExtension: 2.16.840.1.113719.1.27.100.98 supportedExtension: 2.16.840.1.113719.1.27.100.101 supportedExtension: 2.16.840.1.113719.1.27.100.103 supportedExtension: 2.16.840.1.113719.1.142.100.1 supportedExtension: 2.16.840.1.113719.1.142.100.4 supportedExtension: 2.16.840.1.113719.1.142.100.6 supportedExtension: 2.16.840.1.113719.1.27.100.9 supportedExtension: 2.16.840.1.113719.1.27.100.43 supportedExtension: 2.16.840.1.113719.1.27.100.45 supportedExtension: 2.16.840.1.113719.1.27.100.47 supportedExtension: 2.16.840.1.113719.1.27.100.49 supportedExtension: 2.16.840.1.113719.1.27.100.51 supportedExtension: 2.16.840.1.113719.1.27.100.53 supportedExtension: 2.16.840.1.113719.1.27.100.55 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 2.16.840.1.113719.1.27.100.79 supportedExtension: 2.16.840.1.113719.1.27.100.84 supportedExtension: 2.16.840.1.113719.1.27.103.1 supportedExtension: 2.16.840.1.113719.1.27.103.2 Is there a way to allow these extensions on the proxy? Thx, Philip

3 7

dynlist and entryUUID
by Jon C Kidder 10 Jan '19

10 Jan '19

I have a very rigid LDAP client and I need to present the entryUUID as both entryUUID and nsUniqueID in the user records. I have chosen to do this with the dynlist overlay rather than build a process to replicate the data. I've had the overlay deployed for quite some time and have several dynamically generated attributes. However, I'm finding that this doesn't work with entryUUID? Here's the relevant configuration: dn: olcOverlay={0}dynlist,olcDatabase={2}mdb,cn=config olcDlAttrSet: {4}aepAuxUser nsUniqueIDURL nsUniqueID nsUniqueID:entryUUID dn: uid=TestEmployee,ou=Employees,ou=Users,dc=global,dc=aep,dc=com nsUniqueIDURL: ldap:///uid= TestEmployee,ou=Employees,ou=Users,dc=global,dc=aep,dc=com?entryUUID?base?(objectClass=*) When I execute a search on the above user DN the nsUniqueID attribute doesn't appear but all of my other dynamic attributes do appear and have correct values. I have modified both of the above entries replacing entryUUID with any number of attributes and nsUniqueID will suddenly appear as expected and contain the value of the attribute chosen. I can't get this to work using entryUUID. I have not tried it with other operational attributes yet. Is this because the overlay doesn’t work with operational attributes? Is this a bug? JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215

3 2

openldap proxy to kerberos
by vadud3＠gmail.com 09 Jan '19

09 Jan '19

I am using openldap proxy today with ldap backend. Any suggestions on how to use kerberos as the backend? Here is my config (sanitized) $ cat slapd.conf ### Schema includes ########################################################### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema ## Module paths ############################################################## modulepath /usr/lib64/openldap/ moduleload back_ldap # Main settings ############################################################### pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args sizelimit unlimited TLSCertificateFile /root/data/certs/ldap.crt TLSCertificateKeyFile /root/data/certs/ldap.key ### Database definition (Proxy to AD) ######################################### database ldap readonly yes protocol-version 3 rebind-as-user yes uri "ldaps://ldap.example.com:1636" suffix "ou=People,dc=example,dc=net" ### Logging ################################################################### loglevel 0 -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

5 7

Re: OpenLDAP 2.4.47 available, LMDB 0.9.23 available
by Clément OUDOT 08 Jan '19

08 Jan '19

Hello, for information, LDAP Tool Box packages for OpenLDAP 2.4.47 are available: * https://ltb-project.org/documentation/openldap-rpm * https://ltb-project.org/documentation/openldap-deb Thanks a lot to OpenLDAP community for this great software! Clément.

1 0

How should a cron jobb handle modify(cn=config) error?
by Hallvard Breien Furuseth 06 Jan '19

06 Jan '19

We have a cn=config database with olcDbDirectory: /ldap/var/db/foobar-<directory version> A cron job in a quandary can clear things up thus: Rebuild the database in a new directory with slapadd, ldapmodify cn=config so olcDbDirectory points at the new DB directory, and finally throw away the old DB dir. ldapmodify -H ldapi:// -Q -Y EXTERNAL <<EOF # hdb can have more "interesting" problems than mdb:-) dn: olcDatabase={3}hdb,cn=config changetype: modify replace: olcDbDirectory olcDbDirectory: /ldap/var/db/foobar-$NEW_DIR_VERSION EOF Now if ldapmodify fails, what should the cron job do - in addition to alerting a human? When can it assume that the new DB dir is unused and can be deleted? ...that the old DB dir can be deleted? How complicated code should I have to examine the situation and decide what to do? Do we just wait for a human to fix things? Or is it time to restart slapd? Yet that can fail too, so next question becomes what to do next - reboot? A cron job which keeps escalating the problem in order to fix it makes me nervous - LDAP must be up. It's load balanced, so a single server in trouble is OK - unless the problem is a systemic one so all servers hiccup at once. Do others have something like this implemented? -- Hallvard

2 2

storing large blob in LDAP
by Derek Zhou 02 Jan '19

02 Jan '19

Hi, Is is possible to store large blob outside the main database, and only keep file names in the LDAP database? The blobs I want to stored are not as often used as other attributes and not indexed, so it seems to me that bloating up the main database is not economical in terms of fast disk space and overall database efficiency. Then I suppose I need a middle ware or something to combine the data from file system and data from LDAP server. Has anyone try that before? Or I should just store the blobs inside, and live with the bloated database? Thanks a lot Derek

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2019