openldap-technical

openldap-technical@openldap.org

9773 discussions

RE: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 25 Jun '17

25 Jun '17

--On Friday, June 23, 2017 8:30 AM +0000 Juergen.Sprenger(a)swisscom.com wrote: > Have also added these entries to syncrepl now, but without any success: > > tls_cert=/etc/ssl/openldap/dannatu.ch.pem > tls_key=/etc/ssl/openldap/dannatu.ch.key > tls_cacert=/etc/ssl/certs/dannatuCA-cacert.pem This would indicate you want to do client cert authentication with the syncrepl client, which as far as I know, you are not using (based on your earlier configuration). You need to remove the tls_cert and tls_key lines. I've tested with OpenLDAP 2.4.45 and TLS works as expected with replication. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: ldapsearch on accesslog hangs in OpenLDAP 2.4.40 on RHEL 6.9 ( works ok w/ slapcat -b "cn=accesslog")
by Quanah Gibson-Mount 24 Jun '17

24 Jun '17

--On Thursday, June 22, 2017 9:19 PM +0000 Ron Lamarche <Ron.Lamarche(a)innovapost.com> wrote: > I've installed the RHEL 6.9 OpenLDAP bundled product and have a working > suffix based on cn=config vs. slapd.conf model but cannot get the > accesslog overlays/DB's to work properly (ldapsearch returns accesslog > records but never completes and instead hangs showing > "ldap_int_select" . Need to ctl –c to exit ) Hi Ron, The OpenLDAP build distributed by RedHat is known to have severe issues. It is strongly recommended to avoid their OpenLDAP builds because of this and their advanced age. If you are not able to build OpenLDAP yourself, the LTB project provides standard OpenLDAP builds for free: <http://ltb-project.org/wiki/download#openldap> If you require support, Symas (my employer) has such an offering. Our OpenLDAP builds also include features not yet available from the OpenLDAP project. You may be well facing any of a number of bugs that have been fixed in the 2.5 years since 2.4.40 was released, in particular: Fixed slapd cn=config when updating olcAttributeTypes (ITS#8199) Fixed slapo-accesslog to honor pauses during purge for cn=config update (ITS#8423) Finally, I would also note that the back-bdb backend has been deprecated since OpenLDAP 2.3, and as of OpenLDAP 2.4, back-hdb is also deprecated. The recommended backend is back-mdb, which is built on top of LMDB (<http://www.symas.com/lmdb/>, <https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database>) In general, issues with RedHat's build will not be explored unless you can reproduce the same problem with a current build of OpenLDAP. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: Using TLS
by Quanah Gibson-Mount 23 Jun '17

23 Jun '17

--On Friday, June 23, 2017 10:08 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Hi Quanah, > > No, I'm fairly new to OpenLDAP and wasn't aware of such global context > requirement. > > Does that only apply to client TLS options? > > Is global option set by passing a NULL LDAP handle? > > I found ITS#8573 wrt your TLS patch, but the URL: > <http://www.openldap.org/lists/openldap-devel/attachments/20170608/2ae39d > 03/attachment.bin> is not found. Can you point me to where to download or > see the patch? Has it been integrated into 2.4.45? Hi Daniel, You can view it here: <https://github.com/quanah/openldap-scratch/commit/cff66313706c607d4df6f0742…> and no, it would be part of 2.5 once submitted, although it applies just fine for me to 2.4 --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: Using TLS
by Quanah Gibson-Mount 23 Jun '17

23 Jun '17

Hi Daniel, You are aware that you must use the global context when changing the TLS options for a client, correct? It does not work on the specific filehandle. See my TLS patch for the command line client tools for an example (that is posted to the openldap-devel list). --Quanah --On Friday, June 23, 2017 9:20 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Hello, > > Is there a unit tester where the client LDAP_OPT_X_TLS_REQUIRE_CERT > option is set to LDAP_OPT_X_TLS_NEVER that I can try? I was looking at > openldap-2.4.44/clients/tools/ldapsearch but it doesn't configure this > option. > > My application program sets LDAP_OPT_X_TLS_NEVER. Why does LDAP client > still check for server certificate which fails in the case of bad > certificate? > > int opt; > opt = LDAP_OPT_X_TLS_NEVER; > ldap_retcode = ldap_set_option(m_tLDAP, LDAP_OPT_X_TLS_REQUIRE_CERT, > &opt); ... > > Daniel > > -----Original Message----- > From: Daniel Le > Sent: Monday, June 19, 2017 3:58 PM > To: 'Paulm' <paulm(a)tetrardus.net> > Cc: openldap-technical(a)openldap.org > Subject: RE: Using TLS > > I rebuilt with libssl (an OpenSSL library which supports SSL and TLS) and > that worked. Thanks. > > However, I got into the connect error "14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self > signed certificate)", even though the LDAP_OPT_X_TLS_REQUIRE_CERT option > is set to LDAP_OPT_X_TLS_NEVER. Isn't LDAP client supposed to bypass > server certificate validation when LDAP_OPT_X_TLS_NEVER is configured? > > Daniel > > -----Original Message----- > From: Paulm [mailto:paulm@tetrardus.net] > Sent: Sunday, June 18, 2017 10:13 PM > > On Fri, Jun 16, 2017 at 03:26:20PM +0000, Daniel Le wrote: >> Hi, >> >> >> I'm seeing some critical error which causes the application program to >> exit/terminate when ldap_start_tls_s(LDAP-handle, NULL, NULL) is >> called. Tracing the code execution, ldap_start_tls_s => >> ldap_int_tls_start => tls_init, it appears the crash is at the >> statement "return impl->ti_tls_init()" in the tls_init function. >> >> >> Can someone give a pointer to help debugging this? And does OpenLDAP >> need to be linked to OpenSSL library for TLS to work? > > If your ldap libs are linked to gnutls, then it might be worthwhile to > rebuild and link to the openssl library; then test your code again. > > I don't use gnutls because it has given me problems. > >> I use LDAPv3, port 389 and the default LDAP_OPT_X_TLS_NEVER option. >> HAVE_TLS is defined but not LDAP_R_COMPILE. >> >> >> Thanks, >> >> Daniel > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Using TLS
by Daniel Le 23 Jun '17

23 Jun '17

Hi, I'm seeing some critical error which causes the application program to exit/terminate when ldap_start_tls_s(LDAP-handle, NULL, NULL) is called. Tracing the code execution, ldap_start_tls_s => ldap_int_tls_start => tls_init, it appears the crash is at the statement "return impl->ti_tls_init()" in the tls_init function. Can someone give a pointer to help debugging this? And does OpenLDAP need to be linked to OpenSSL library for TLS to work? I use LDAPv3, port 389 and the default LDAP_OPT_X_TLS_NEVER option. HAVE_TLS is defined but not LDAP_R_COMPILE. Thanks, Daniel

2 3

Re: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 23 Jun '17

23 Jun '17

--On Thursday, June 22, 2017 10:25 AM +0000 Juergen.Sprenger(a)swisscom.com wrote: > syncrepl rid=000 > provider=ldaps://ldap.dannatu.ch:636 > type=refreshAndPersist > retry="5 5 300 +" > searchbase="dc=dannatu,dc=ch" > attrs="*,+" > scope=sub > bindmethod=simple > binddn="cn=Manager,dc=dannatu,dc=ch" > credentials=************** I don't see anything here configuring for syncrepl to find the CA for your server cert. I.e., something like tls_cacertdir=<path> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

ldapsearch on accesslog hangs in OpenLDAP 2.4.40 on RHEL 6.9 ( works ok w/ slapcat -b "cn=accesslog")
by Ron Lamarche 22 Jun '17

22 Jun '17

Hi. My company has decided to migrate from Oracle Directory Server 7.0 (ODSEE ) to OpenLDAP due to end of life supportability issues . I've installed the RHEL 6.9 OpenLDAP bundled product and have a working suffix based on cn=config vs. slapd.conf model but cannot get the accesslog overlays/DB's to work properly (ldapsearch returns accesslog records but never completes and instead hangs showing "ldap_int_select" . Need to ctl -c to exit ) Here's the details: - more /etc/redhat-release o Red Hat Enterprise Linux Server release 6.9 (Santiago) - yum list installed | grep openldap o compat-openldap.x86_64 1:2.3.43-2.el6 o openldap.x86_64 2.4.40-16.el6 o openldap-clients.x86_64 2.4.40-16.el6 o openldap-devel.x86_64 2.4.40-16.el6 o openldap-servers.x86_64 2.4.40-16.el6 - ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b "olcDatabase={2}bdb,cn=config" | egrep "olcRo|olcSu" < - -------- main suffix DB o olcSuffix: dc=mydomain,dc=ca o olcRootDN: cn=dev13,dc=mydomain,dc=ca o olcRootPW: {SSHA}ZODaH7MZuRjuG+FTzIZvdPg5edL2WDjg - ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b "olcDatabase={3}bdb,cn=config" < - ---accesslog DB and overlay o dn: olcDatabase={3}bdb,cn=config o objectClass: olcDatabaseConfig o objectClass: olcBdbConfig o olcDatabase: {3}bdb o olcDbDirectory: /var/lib/ldap/accesslog o olcSuffix: cn=accesslog o olcRootDN: cn=dev13,dc=mydomain,dc=ca o olcDbIndex: default eq o olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart - o dn: olcOverlay={0}accesslog,olcDatabase={3}bdb,cn=config o objectClass: olcOverlayConfig o objectClass: olcAccessLogConfig o olcOverlay: {0}accesslog o olcAccessLogDB: cn=accesslog o olcAccessLogOps: writes reads session o olcAccessLogPurge: 07+00:00 01+00:00 o olcAccessLogSuccess: TRUE - ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b "cn=module{0},cn=config" |< - --------------loaded modules o dn: cn=module{0},cn=config o objectClass: olcModuleList o cn: module{0} o olcModulePath: /usr/lib64/openldap o olcModuleLoad: {0}syncprov.la o olcModuleLoad: {1}accesslog.la When I execute the ldapsearch on cn=accesslog I get the following ( ctl-c needed to exit from the hang ) : ldapsearch -d 1 -H ldap:// -v -x -LLL -D "cn=dev13,dc=mailposte,dc=ca" -b cn=accesslog -W ldap_url_parse_ext(ldap://) ldap_initialize( ldap://:389/??base ) ldap_create ldap_url_parse_ext(ldap://:389/??base) Enter LDAP Password: ... stuff omitted due to length ... reqDN: reqStart=20170620210816.000003Z,cn=accesslog ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: reqResult: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: reqMod: objectClass:+ auditSearch reqMod: structuralObjectClass:+ auditSearch reqMod: reqStart:+ 20170620210816.000003Z reqMod: reqEnd:+ 20170620210816.000004Z reqMod: reqType:+ search reqMod: reqSession:+ 18446744073709551615 reqMod: reqAuthzID:+ cn=dev13,dc=mailposte,dc=ca reqMod: reqDN:+ cn=accesslog reqMod: reqResult:+ 0 reqMod: reqScope:+ one reqMod: reqDerefAliases:+ never reqMod: reqAttrsOnly:+ TRUE reqMod: reqFilter:+ (reqStart<=20170613210816Z) reqMod: reqAttr:+ 1.1 reqMod: reqEntries:+ 0 reqMod: reqTimeLimit:+ -1 reqMod: reqSizeLimit:+ -1 reqMod: entryUUID:+ 52bef5ee-ea48-1036-9807-2fa6ad6fded4 reqMod: creatorsName:+ cn=dev13,dc=mailposte,dc=ca reqMod: createTimestamp:+ 20170620210816Z reqMod: entryCSN:+ 20170620210816.416676Z#000000#000#000000 reqMod: modifiersName:+ cn=dev13,dc=mailposte,dc=ca reqMod: modifyTimestamp:+ 20170620210816Z ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: reqEntryUUID: 52bef5ee-ea48-1036-9807-2fa6ad6fded4 ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x14c91c0 msgid -1 wait4msg ld 0x14c91c0 msgid -1 (infinite timeout) wait4msg continue ld 0x14c91c0 msgid -1 all 0 ** ld 0x14c91c0 Connections: * host: (null) port: 389 (default) refcnt: 2 status: Connected last used: Wed Jun 21 13:46:58 2017 ** ld 0x14c91c0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x14c91c0 request count 1 (abandoned 0) ** ld 0x14c91c0 Response Queue: Empty ld 0x14c91c0 response count 0 ldap_chkResponseList ld 0x14c91c0 msgid -1 all 0 ldap_chkResponseList returns ld 0x14c91c0 NULL ldap_int_select ^C When I do an strace of the working suffix ( dc=mydomain,dc=ca ) I get the following termination : - strace ldapsearch -d 1 -H ldap:// -v -x -LLL -D "cn=dev13,dc=mydomain,dc=ca" -b dc=mydomain,dc=ca -w my_passwd ..... stuff omitted due to length .... write(3, "0\5\2\1\3B\0", 7) = 7 shutdown(3, SHUT_RDWR) = 0 close(3) = 0 write(2, "ldap_free_connection: actually f"..., 37ldap_free_connection: actually freed ) = 37 exit_group(0) = ? +++ exited with 0 +++ When I do an strace of cn=accesslog I get the following termination : - strace ldapsearch -d 1 -H ldap:// -v -x -LLL -D "cn=dev13,dc=mydomain,dc=ca" -b cn=accesslog -w my_passwd ..... stuff omitted due to length .... write(1, "reqEntryUUID: 52bef5ee-ea48-1036"..., 51reqEntryUUID: 52bef5ee-ea48-1036-9807-2fa6ad6fded4) = 51 write(2, "ldap_get_attribute_ber\n", 23ldap_get_attribute_ber) = 23 write(2, "ldap_msgfree\n", 13ldap_msgfree) = 13 write(2, "ldap_result ld 0x24381e0 msgid -"..., 34ldap_result ld 0x24381e0 msgid -1) = 34 write(2, "wait4msg ld 0x24381e0 msgid -1 ("..., 50wait4msg ld 0x24381e0 msgid -1 (infinite timeout)) = 50 write(2, "wait4msg continue ld 0x24381e0 m"..., 46wait4msg continue ld 0x24381e0 msgid -1 all 0) = 46 write(2, "** ld 0x24381e0 Connections:\n", 29** ld 0x24381e0 Connections:) = 29 write(2, "* host: (null) port: 389 (defa"..., 37* host: (null) port: 389 (default)) = 37 write(2, " refcnt: 2 status: Connected\n", 31 refcnt: 2 status: Connected) = 31 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3477, ...}) = 0 write(2, " last used: Wed Jun 21 14:07:30"..., 39 last used: Wed Jun 21 14:07:30 2017) = 39 write(2, "\n", 1) = 1 write(2, "** ld 0x24381e0 Outstanding Requ"..., 38** ld 0x24381e0 Outstanding Requests:) = 38 write(2, " * msgid 2, origid 2, status In"..., 41 * msgid 2, origid 2, status InProgress) = 41 write(2, " outstanding referrals 0, pare"..., 43 outstanding referrals 0, parent count 0) = 43 write(2, " ld 0x24381e0 request count 1 ("..., 45 ld 0x24381e0 request count 1 (abandoned 0)) = 45 write(2, "** ld 0x24381e0 Response Queue:\n", 32** ld 0x24381e0 Response Queue:) = 32 write(2, " Empty\n", 9 Empty) = 9 write(2, " ld 0x24381e0 response count 0\n", 32 ld 0x24381e0 response count 0) = 32 write(2, "ldap_chkResponseList ld 0x24381e"..., 49ldap_chkResponseList ld 0x24381e0 msgid -1 all 0) = 49 write(2, "ldap_chkResponseList returns ld "..., 47ldap_chkResponseList returns ld 0x24381e0 NULL) = 47 write(2, "ldap_int_select\n", 16ldap_int_select) = 16 poll([{fd=3, events=POLLIN|POLLPRI}], 1, -1 < - ------------------------------- This means poll is waiting for something on this File descriptor which never gets returned ^C Process 7844 detached <detached ...> Here is the ldif file used for moduleload by ldapadd : cat addModule.ldif dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap #olcModuleLoad: {0}back_bdb olcModuleLoad: syncprov.la olcModuleLoad: accesslog.la Here is the ldif file to add the accesslog db and overlay by ldapadd: cat addAccesslog2DB # Accesslog database definitions dn: olcDatabase={3}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {3}bdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=dev13,dc=mydomain,dc=ca olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart # accesslog overlay definitions for primary db dn: olcOverlay=accesslog,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes reads session olcAccessLogSuccess: TRUE # scan the accesslog DB every day and purge entries older than 7 days olcAccessLogPurge: 07+00:00 01+00:00 I have also created /var/lib/ldap/accesslog owned by ldap:ldap : ls -l /var/lib/ldap/accesslog total 11232 -rw-r-----. 1 ldap ldap 4096 Jun 20 17:08 alock -rw-------. 1 ldap ldap 24576 Jun 20 17:08 __db.001 -rw-------. 1 ldap ldap 188416 Jun 21 14:07 __db.002 -rw-------. 1 ldap ldap 270336 Jun 21 13:46 __db.003 -rw-------. 1 ldap ldap 98304 Jun 21 13:46 __db.004 -rw-------. 1 ldap ldap 753664 Jun 21 14:07 __db.005 -rw-------. 1 ldap ldap 32768 Jun 21 14:07 __db.006 -rw-------. 1 ldap ldap 8192 Jun 20 17:08 dn2id.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 entryCSN.bdb -rw-------. 1 ldap ldap 32768 Jun 20 17:08 id2entry.bdb -rw-------. 1 ldap ldap 10485760 Jun 20 17:08 log.0000000001 -rw-------. 1 ldap ldap 8192 Jun 20 17:08 objectClass.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 reqEnd.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 reqResult.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 reqStart.bdb I am new to this forum so If I've missed something please let me know. Constructive comments and suggestions are greatly appreciated. regards RON LAMARCHE Technical Specialist, Online Channel Innovapost

1 0

Re: Limit which database is reachable on which port (slapd is listening on)?
by Howard Chu 22 Jun '17

22 Jun '17

Karsten Heymann wrote: > Hi, > > short question: If I configure slapd to listen to several ports and > have several databases configured, is there a way to limit which > database is visible on which port? I want to use a single slapd > instance to serve multiple databases (slapd-meta instances to be > exact) and for each database want to use a dedicated listening port, > somehow like port-based virtual hosts in the apache web server. The > reason is that I want to define different firewall rules for the > different databases. Is this possible with openldap? Read the slapd.access(5) manpage, use an ACL specifying sockname=xxx for the local port identifier. > Best regards > Karsten > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 7

syncrepl fails after upgrade to openldap 2.4.45
by Juergen.Sprenger＠swisscom.com 22 Jun '17

22 Jun '17

Hi, after upgrading from openldap-2.4.44-r1 to openldap-2.4.45 on my Gentoo machine multi-master-replication does not work anymore. Has anything changed in configuration options for syncrepl or are certificates treated differently now? In the logs I found the following message: Jun 22 10:33:13 ids00000 slapd[30734]: [ID 000001 (local4.debug)] slap_client_connect: URI=ldaps://ldap.dannatu.ch:636 DN="cn=manager,dc=dannatu,dc=ch" ldap_sasl_bind_s failed (-1) Running slapd in foreground with -d -1 revealed this message: TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain). 594b8120 slap_client_connect: URI=ldaps://ldap.dannatu.ch:636 DN="cn=manager,dc=dannatu,dc=ch" ldap_sasl_bind_s failed (-1) My syncrepl configuriation: syncrepl rid=000 provider=ldaps://ldap.dannatu.ch:636 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=dannatu,dc=ch" attrs="*,+" scope=sub bindmethod=simple binddn="cn=Manager,dc=dannatu,dc=ch" credentials=************** I have verified the certificate and my selfsigned ca-certificate with openssl, and both are ok: # openssl verify /etc/ssl/certs/dannatuCA-cacert.pem /etc/ssl/certs/dannatuCA-cacert.pem: OK # openssl verify /etc/ssl/openldap/dannatu.ch.pem /etc/ssl/openldap/dannatu.ch.pem: OK Also verification with openssl s_client seems ok: # openssl s_client -connect ldap.dannatu.ch:636 -tls1_2 CONNECTED(00000003) depth=1 C = CH, ST = Solothurn, L = Solothurn, O = Dannatu AG, OU = IT, CN = Dannatu AG CA, emailAddress = admin(a)dannatu.ch verify return:1 depth=0 C = CH, ST = Solothurn, L = Solothurn, O = Dannatu AG, OU = IT, CN = dannatu.ch, emailAddress = admin(a)dannatu.ch verify return:1 --- Certificate chain 0 s:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=dannatu.ch/emailAddress=admin(a)dannatu.ch i:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=Dannatu AG CA/emailAddress=admin(a)dannatu.ch 1 s:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=Dannatu AG CA/emailAddress=admin(a)dannatu.ch i:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=Dannatu AG CA/emailAddress=admin(a)dannatu.ch --- After downgrading to openldap-2.4.44-r1 everything worked fine again. Seems certificate handling has changed. Any hints? Juergen Sprenger

1 0

Delete the root entry of a DIT (mdb as backend)
by Hongfu Huang 21 Jun '17

21 Jun '17

Hi all, I have defined a DIT (LMDB) as follows: > dn: olcDatabase={3}mdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcMdbConfig > olcDatabase: {3}mdb > olcDbDirectory: /var/lib/ldap/mycompany/o=mycompany > olcSuffix: o=mycompany > olcRootDN: uid=admin,ou=system > olcAccess: {0}to attrs=userPassword,shadowLastChange by > dn="uid=admin,ou=system" write by anonymous auth by self write by * none > olcAccess: {1}to * by dn="uid=admin,ou=system" write by * none > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcSyncUseSubentry: FALSE > olcMonitoring: TRUE > olcDbEnvFlags: writemap > olcDbEnvFlags: nometasync > olcDbNoSync: FALSE > olcDbIndex: objectClass pres,eq > olcDbIndex: cn pres,eq,sub > olcDbIndex: uid pres,eq,sub > olcDbIndex: uidNumber pres,eq > olcDbIndex: gidNumber pres,eq > olcDbIndex: mail pres,eq,sub > olcDbIndex: ou pres,eq,sub > olcDbIndex: sn pres,eq,sub > olcDbIndex: givenName pres,eq,sub > olcDbIndex: loginShell pres,eq > olcDbIndex: memberUid pres,eq,sub > olcDbIndex: nisMapName pres,eq,sub > olcDbIndex: nisMapEntry pres,eq,sub > olcDbMaxReaders: 0 > olcDbMaxSize: 4294967296 > olcDbMode: 0600 > olcDbSearchStack: 16 I can add the root entry as: > dn: o=mycompany > objectClass: organization > objectClass: top > o: mycompany And I can also add and delete sub-entries under o=mycompany. But I can not delete the root entry o=mycompany, even there is no sub-entry below it. Please no that the rootdn (uid=admin,ou=system) is not under the subffix (o=mycompany), that is why no rootPW is defined for this DIT. The rootDN and rootPW are defined in the second DIT (in BDB) The weird thing was that I could search and found it: > ldapsearch -x -D uid=admin,ou=system -w XXXXXXXXX -H > ldap://localhost:389 -b o=mycompany > # extended LDIF > # > # LDAPv3 > # base <o=cornerbank> with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # mycompany > dn: o=mycompany > o: mycompany > objectClass: organization > objectClass: top > > # search result > search: 2 > result: 0 Success But it would fail if I tried to delete it: > $ ldapdelete -x -D uid=admin,ou=system -w XXXXXXXXX -H > ldap://localhost:389 o=mycompany > ldap_delete: No such object (32) > 32 In the other words, I could import the whole DIT for o=mycompany, but could not delete the whole DIT (the root entry o=mycompany could not be deleted). Does somebody know how to solve this problem? Thanks! Regards -- Hongfu Huang, Senior System Integrator M.Sc. Computer Science AdNovum Informatik AG Roentgenstrasse 22, 8005 Zurich, Switzerland phone +41 44 272 6111, direct +41 44 270 5266 hongfu.huang(a)adnovum.ch, www.adnovum.ch Locations: Zurich (HQ), Bern, Lausanne, Budapest, Ho Chi Minh City, Singapore

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical