openldap-technical

openldap-technical@openldap.org

1 participants
9898 discussions

Replication suddenly broken
by Prentice Bisbal 16 Jan '20

16 Jan '20

One of my coworkers just noticed that replication is broken between our primary and secondary LDAP servers. It appears to have been broken for about 1 week now. Nothing has changed relative to the LDAP configuration on either of our servers, so this is an odd thing to suddenly happen. When I look at the consumer with some debugging on, I see these messages (/usr/sbin/slapd -d 1638 was used to get these messages): It looks like the consumer host/voltron-b.pppl.gov,cn=pppl.gov,cn=gssapi,cn=auth,is being rejected as not being authorized, but this has been working for years w/o issue. Any idea what has changed and how I may fix it? ldap_write: want=22, written=22 0000: 30 14 02 01 02 60 0f 02 01 03 04 00 a3 08 04 06 0....`.......... 0010: 47 53 53 41 50 49 GSSAPI ldap_read: want=8, got=8 0000: 30 4a 02 01 02 61 45 0a 0J...aE. ldap_read: want=68, got=68 0000: 01 0e 04 00 04 1c 53 41 53 4c 28 30 29 3a 20 73 ......SASL(0): s 0010: 75 63 63 65 73 73 66 75 6c 20 72 65 73 75 6c 74 uccessful result 0020: 3a 20 87 20 05 04 05 ff 00 0c 00 00 00 00 00 00 : . ............ 0030: 3a f9 e0 c9 07 00 00 00 fd e6 0d 82 df 31 29 00 :............1). 0040: a7 27 90 6a .'.j ldap_write: want=116, written=116 0000: 30 72 02 01 03 60 6d 02 01 03 04 00 a3 66 04 06 0r...`m......f.. 0010: 47 53 53 41 50 49 04 5c 05 04 04 ff 00 0c 00 00 GSSAPI.\........ 0020: 00 00 00 00 36 3c fc 1d 04 ff ff ff 64 6e 3a 75 ....6<......dn:u 0030: 69 64 3d 68 6f 73 74 2f 76 6f 6c 74 72 6f 6e 2d id=host/voltron- 0040: 62 2e 70 70 70 6c 2e 67 6f 76 2c 63 6e 3d 70 70 b.pppl.gov,cn=pp 0050: 70 6c 2e 67 6f 76 2c 63 6e 3d 67 73 73 61 70 69 pl.gov,cn=gssapi 0060: 2c 63 6e 3d 61 75 74 68 c2 5d 9b 4a ce d9 d6 8b ,cn=auth.].J.... 0070: 23 5f b4 1d #_.. ldap_read: want=8, got=8 0000: 30 3c 02 01 03 61 37 0a 0<...a7. ldap_read: want=54, got=54 0000: 01 32 04 00 04 30 53 41 53 4c 28 2d 31 34 29 3a .2...0SASL(-14): 0010: 20 61 75 74 68 6f 72 69 7a 61 74 69 6f 6e 20 66 authorization f 0020: 61 69 6c 75 72 65 3a 20 6e 6f 74 20 61 75 74 68 ailure: not auth 0030: 6f 72 69 7a 65 64 orized 5e20cedc slap_client_connect: URI=ldap://ldap1.pppl.gov ldap_sasl_interactive_bind_s failed (50) ldap_write: want=7, written=7 0000: 30 05 02 01 04 42 00 0....B. 5e20cedc do_syncrepl: rid=001 rc 50 retrying -- Prentice

2 1

two slapd processes accessing one MDB env
by Michael Ströder 16 Jan '20

16 Jan '20

HI! I vaguely remember that it's possible that two slapd processes can access a single MDB env. Is that supported? Any pre-cautions needed? Ciao, Michael.

2 1

Replication account problem
by Vincent Ducot 16 Jan '20

16 Jan '20

Hi all, I'm testing multi-master replication between (at least 2) openldap nodes (2.4.45, on Ubuntu 18.04) and facing a problem with replication account. I set up configuration for node1 and node2 (see configuration below), and rpuser account for replication (with same hashed password on both nodes). I can connect to node1 and node2 with rpuser account : ldapsearch -H ldap://node1-vpn -W -D "uid=rpuser,dc=foo,dc=bar" -b "dc=foo,dc=bar" Then I add a group or a user to a node to test replication with ldapadd -H ldap://node1-vpn -W -D "cn=admin,dc=foo,dc=bar" -f /tmp/openldap/rep_test_groupadd.ldif and rep_test_groupadd.ldif: dn: cn=testgroup,dc=foo,dc=bar objectClass: top objectClass: posixGroup gidNumber: 456 The new group or user is replicated on the other node, but then the rpuser's password doesn't work anymore on the other node. I can't connect anymore with ldapsearch -H ldap://node2-vpn -W -D "uid=rpuser,dc=foo,dc=bar" -b "dc=foo,dc=bar" and I got errors messages for replication in /var/log/syslog slap_client_connect: URI=ldap://node2-vpn DN="uid=rpuser,dc=foo,dc=bar" ldap_sasl_bind_s failed (49) rpuser's password is still valid on node1 Any idea of what could cause this problem ? Thanks Vincent # config dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcDisallows: bind_anon olcLogLevel: any olcPidFile: /var/run/slapd/slapd.pid olcRequires: authc olcToolThreads: 1 olcServerID: 0 ldap:/// olcServerID: 1 ldap://node1-vpn olcServerID: 2 ldap://node2-vpn # module{0}, config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_mdb # module{1}, config dn: cn=module{1},cn=config objectClass: olcModuleList cn: module{1} olcModuleLoad: {0}syncprov.la # {0}mdb, config dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb # {-1}frontend, config dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=Subschema" by * read olcSizeLimit: 500 # {0}config, config dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break # {1}mdb, config dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=nodomain 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 olcRequires: authc olcRootDN: cn=admin,dc=nodomain olcRootPW: {SSHA}HdZbPd66TxCjeYEIAASbAQTnvFh3GOTw olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbMaxSize: 1073741824 # {2}mdb, config dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/lab/ldap olcSuffix: dc=foo,dc=bar olcAccess: {0}to attrs=userPassword by self =xw by anonymous auth by * none olcAccess: {1}to * by dn="cn=admin,dc=foo,dc=bar" write by self write by user s read by * none olcAccess: {2}to * by dn="uid=rpuser,dc=foo,dc=bar" read olcAccess: {3}to * by dn="uid=rpuser,dc=foo,dc=bar" write olcLastMod: TRUE olcLimits: {0}dn.exact="uid=rpuser,dc=foo,dc=bar" time.soft=unlimited time.h ard=unlimited size.soft=unlimited size.hard=unlimited olcRequires: authc olcRootDN: cn=admin,dc=foo,dc=bar olcRootPW: {SSHA}zL8CSrnkBacsebLUsJ+dzva6eQ7xcyZJ olcSyncrepl: {0}rid=101 provider=ldap://node1-vpn binddn="uid=rpuser,dc=foo, dc=bar" bindmethod=simple credentials=rppwd searchbase="dc=foo,dc=bar" type=r efreshOnly interval=00:00:00:20 retry="5 10 20 10" timeout=1 olcSyncrepl: {1}rid=102 provider=ldap://node2-vpn binddn="uid=rpuser,dc=foo, dc=bar" bindmethod=simple credentials=rppwd searchbase="dc=foo,dc=bar" type=r efreshOnly interval=00:00:00:20 retry="5 10 20 10" timeout=1 olcMirrorMode: TRUE olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbMaxSize: 1073741824 # {0}syncprov, {2}mdb, config dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov

5 13

Re: Openldap support SHA-256 or SHA-3.
by Quanah Gibson-Mount 15 Jan '20

15 Jan '20

--On Tuesday, January 7, 2020 11:52 AM -0800 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Thanks for the quick reply, is there any plans to make SSHA512 default? No. As I said, SHA1 is mandated by RFC. > also is there any migration steps to move from SHA-1 to SSHA512 ? After deploying the sha2 module, all users must change their password so the hash gets updated. There is no way to magically convert existing hashes from SSHA1 to another scheme. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 19

Segmentation Fault on ldap_chain_op
by Jeremy Diaz 14 Jan '20

14 Jan '20

Hi everyone, I am currently looking into an issue with an environment that consists of 3 producers and 6 consumers all on OpenLdap 2.4.48. All the masters share an identical master config and all of the consumers share an identical consumer config. One consumer server in particular is crashing on a random time interval with no obvious reason. Each ldap server has sasl pass through auth setup and there is an additional slapd process on each server being used as a ldap meta to AD. One server in particular, is crashing at seemingly random intervals. Upon initial inspection, we noticed that around the time of a crash, saslauthd logs would have an increase in failed write messages: Dec 11 07:23:20 {REDACTED} saslauthd[2720]: user ldap_search_st() failed: Timed out Dec 11 07:23:30 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out Dec 11 07:23:40 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out Dec 11 07:23:56 {REDACTED} saslauthd[2717]: user ldap_search_st() failed: Timed out Dec 11 07:23:57 {REDACTED} saslauthd[2720]: user ldap_search_st() failed: Timed out Dec 11 07:23:57 {REDACTED} saslauthd[2719]: user ldap_search_st() failed: Timed out Dec 11 07:24:05 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out Dec 11 07:24:06 {REDACTED} saslauthd[2717]: user ldap_search_st() failed: Timed out Dec 11 07:24:54 {REDACTED} saslauthd[2719]: : write failure Dec 11 07:24:54 {REDACTED} saslauthd[2717]: : write failure Dec 11 07:24:54 {REDACTED} saslauthd[2719]: : write: Broken pipe Dec 11 07:24:54 {REDACTED} saslauthd[2717]: : write: Broken pipe Dec 11 07:24:54 {REDACTED} saslauthd[2718]: : write failure Dec 11 07:24:54 {REDACTED} saslauthd[2720]: : write failure Dec 11 07:24:54 {REDACTED} saslauthd[2718]: : write: Broken pipe Dec 11 07:24:54 {REDACTED} saslauthd[2720]: : write: Broken pipe Dec 11 07:25:04 {REDACTED} saslauthd[2721]: : write failure Dec 11 07:25:04 {REDACTED} saslauthd[2721]: : write: Broken pipe Initially we thought this meant that the crashes were caused by performance issues with AD, saslauthd or the ldap meta instance. We also ran slapd in full debugging mode to see if the logs have some kind of hints to the source of the issue. The resulting slapd logs were normal. To obtain further information we obtained the following trace of the segfault using gdb: starting [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". frames-invalid [New Thread 0x7ffbf19be700 (LWP 22956)] new-thread [New Thread 0x7ffbf11bd700 (LWP 22957)] new-thread [New Thread 0x7ffbf09bc700 (LWP 22958)] new-thread [New Thread 0x7ffbebfff700 (LWP 22959)] new-thread [New Thread 0x7ffbeb7fe700 (LWP 22963)] new-thread [New Thread 0x7ffbe9cfb700 (LWP 22965)] new-thread [New Thread 0x7ffbd3fff700 (LWP 22966)] new-thread signal Program received signal signal-name SIGSEGV signal-name-end , signal-string Segmentation fault signal-string-end . [Switching to Thread 0x7ffbf09bc700 (LWP 22958)] thread-changed frame-begin 0 0x4e52e3 frame-function-name ldap_chain_op frame-args ( arg-begin op=op@entry arg-name-end = arg-value * 0x7ffbe41f0870 arg-end , arg-begin rs=rs@entry arg-name-end = arg-value * 0x7ffbf09bbb20 arg-end , arg-begin op_f arg-name-end = arg-value * 0x4a845e <ldap_back_search> arg-end , arg-begin ref=ref@entry arg-name-end = arg-value * 0x0 arg-end , arg-begin depth=depth@entry arg-name-end = arg-value - 0 arg-end ) frame-source-begin at frame-source-file chain.c frame-source-file-end : frame-source-line 422 frame-source-end source ${REDACTED DIR}/chain.c:422:11629:beg:0x4e52e3 frame-end stopped post-prompt #0 ldap_chain_op (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20, op_f=0x4a845e <ldap_back_search>, ref=ref@entry=0x0, depth=depth@entry=0) at chain.c:422 #1 0x00000000004e61da in ldap_chain_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at chain.c:1090 #2 0x000000000049d323 in over_back_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at backover.c:237 #3 0x0000000000447c1a in slap_response_play (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:508 #4 0x00000000004480f5 in send_ldap_response (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:583 #5 0x0000000000448d1f in slap_send_ldap_result (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at result.c:861 #6 0x00000000004bd8c3 in mdb_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:558 #7 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677 #8 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #9 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #10 0x00000000004d1a02 in relay_back_op (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=which@entry=2) at op.c:211 #11 0x00000000004d1b07 in relay_back_op_search (op=<optimized out>, rs=<optimized out>) at op.c:251 #12 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3af00, on=0x0) at backover.c:677 #13 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #14 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #15 0x000000000043c33f in fe_op_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:402 #16 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0x980e00, on=0x0) at backover.c:677 #17 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #18 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #19 0x000000000043bef6 in do_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:247 #20 0x0000000000439bc4 in connection_operation (ctx=0x7ffbf09bbbd0, arg_v=0x7ffbe41f0870) at connection.c:1158 #21 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #22 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf09bc700) at pthread_create.c:307 #23 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 #1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6 #2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39 #3 0x000000000058bbc6 in ber_error_print (data=0x7ffbd3ffdc10 " aaf9: 04 3a 75 69 64 3d 53 49 41 53 47 52 50 2c 6f 75 .:uid=SIASGRP,ou \n") at bprint.c:87 #4 0x000000000058be41 in ber_bprint (data=0x7ffbcd83df04 "0\203\n\036\273\004\funiqueMember1\203\n\036\250\004\071uid=wtso732,ou={REDACTED}“…, len=len@entry=663561) at bprint.c:202 #5 0x000000000058c053 in ber_dump (ber=ber@entry=0x7ffbcc122e20, inout=inout@entry=1) at bprint.c:276 #6 0x000000000058c0ab in ber_log_dump (errlvl=errlvl@entry=16, loglvl=<optimized out>, ber=ber@entry=0x7ffbcc122e20, inout=inout@entry=1) at bprint.c:247 #7 0x00000000005894c1 in ber_scanf (ber=0x7ffbcc122e20, fmt=fmt@entry=0x5b09b3 "{mW}") at decode.c:723 #8 0x0000000000492ba8 in syncrepl_message_to_entry (syncUUID=0x7ffbd3ffdf40, syncstate=<optimized out>, entry=<synthetic pointer>, modlist=0x7ffbd3ffe320, msg=<optimized out>, op=0x7ffbd3ffe510, si=0xa3e9e0) at syncrepl.c:2658 #9 do_syncrep2 (op=op@entry=0x7ffbd3ffe510, si=si@entry=0xa3e9e0) at syncrepl.c:1043 #10 0x00000000004976db in do_syncrepl (ctx=<optimized out>, arg=0xa3e670) at syncrepl.c:1571 #11 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #12 0x00007ffff754cdd5 in start_thread (arg=0x7ffbd3fff700) at pthread_create.c:307 #13 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 0x00007ffff673e16d in write () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007ffff66c91a3 in _IO_new_file_write (f=0x937c20, data=0x7ffff7ff8000, n=162) at fileops.c:1258 #2 0x00007ffff66ca9be in new_do_write (to_do=162, data=0x7ffff7ff8000 " 4530: 62 61 6c 2c 64 63 3d 61 65 70 2c 64 63 3d 63 6f bal,dc={REDACTED} \n5e0a2340 >>> dnPretty: <uid={REDACTED}>\n.. \n5e0a2340 daemon: epoll: listen=19"..., fp=0x937c20) at fileops.c:519 #3 _IO_new_do_write (fp=0x937c20, data=0x7ffff7ff8000 " 4530: 62 61 6c 2c 64 63 3d 61 65 70 2c 64 63 3d 63 6f bal,dc={REDACTED} \n5e0a2340 >>> dnPretty: <uid={REDACTED}>\n.. \n5e0a2340 daemon: epoll: listen=19"..., to_do=162) at fileops.c:495 #4 0x00007ffff66c87f8 in _IO_new_file_sync (fp=0x937c20) at fileops.c:869 #5 0x00007ffff66bd5f3 in __GI__IO_fflush (fp=0x937c20) at iofflush.c:40 #6 0x000000000058c21a in lutil_debug (debug=<optimized out>, level=level@entry=1, fmt=fmt@entry=0x59c7a6 ">>> dnPretty: <%s>\n") at debug.c:81 #7 0x000000000044c792 in dnPretty (syntax=syntax@entry=0x8c4810, val=val@entry=0x7ffbe9cf9d00, out=out@entry=0x7ffbe9cf9de0, ctx=ctx@entry=0x0) at dn.c:539 #8 0x000000000046c614 in nameUIDPretty (syntax=0x8c4810, val=0x7ffbd9845600, out=0x7ffbe9cf9de0, ctx=0x0) at schema_init.c:1350 #9 0x000000000045383d in ordered_value_pretty (ad=ad@entry=0xa40470, val=0x7ffbd9845600, out=out@entry=0x7ffbe9cf9de0, ctx=ctx@entry=0x0) at value.c:511 #10 0x000000000044f676 in slap_mods_check (op=op@entry=0x7ffbe9cfa510, ml=0x7ffbd992c410, text=text@entry=0x7ffbe9cf9f60, textbuf=textbuf@entry=0x7ffbe9cfa180 "H\034\032\330\373\177", textlen=textlen@entry=256, ctx=ctx@entry=0x0) at modify.c:575 #11 0x0000000000492e10 in syncrepl_message_to_entry (syncUUID=0x7ffbe9cf9f40, syncstate=<optimized out>, entry=<synthetic pointer>, modlist=0x7ffbe9cfa320, msg=<optimized out>, op=0x7ffbe9cfa510, si=0xa3fb20) at syncrepl.c:2715 #12 do_syncrep2 (op=op@entry=0x7ffbe9cfa510, si=si@entry=0xa3fb20) at syncrepl.c:1043 #13 0x00000000004976db in do_syncrepl (ctx=<optimized out>, arg=0xa40060) at syncrepl.c:1571 #14 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #15 0x00007ffff754cdd5 in start_thread (arg=0x7ffbe9cfb700) at pthread_create.c:307 #16 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 #1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6 #2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39 #3 0x000000000058bbc6 in ber_error_print (data=0x7ffbeb7fcc10 " 4530: 62 61 6c 2c 64 63 3d 61 65 70 2c 64 63 3d 63 6f bal,dc={REDACTED} \n") at bprint.c:87 #4 0x000000000058be41 in ber_bprint (data=0x7ffbd576fee7 "0\027\004\002cn1\021\004\017CSC User Access0-\004\025structuralObjectClass1\024\004\022groupOfUniqueNames03\004\tentryUUID1&\004$13257271-b706-49bc-a2a9-a5f3e7f4a0dd0L\004\fcreatorsName1<\004:cn={REDACTED}”…, len=len@entry=61665) at bprint.c:202 #5 0x000000000058c053 in ber_dump (ber=ber@entry=0x7ffbd4319130, inout=inout@entry=1) at bprint.c:276 #6 0x000000000058c0ab in ber_log_dump (errlvl=errlvl@entry=16, loglvl=<optimized out>, ber=ber@entry=0x7ffbd4319130, inout=inout@entry=1) at bprint.c:247 #7 0x00000000005894c1 in ber_scanf (ber=0x7ffbd4319130, fmt=fmt@entry=0x5b09b3 "{mW}") at decode.c:723 #8 0x0000000000492ba8 in syncrepl_message_to_entry (syncUUID=0x7ffbeb7fcf40, syncstate=<optimized out>, entry=<synthetic pointer>, modlist=0x7ffbeb7fd320, msg=<optimized out>, op=0x7ffbeb7fd510, si=0xa3f3b0) at syncrepl.c:2658 #9 do_syncrep2 (op=op@entry=0x7ffbeb7fd510, si=si@entry=0xa3f3b0) at syncrepl.c:1043 #10 0x00000000004976db in do_syncrepl (ctx=<optimized out>, arg=0xa3f8b0) at syncrepl.c:1571 #11 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #12 0x00007ffff754cdd5 in start_thread (arg=0x7ffbeb7fe700) at pthread_create.c:307 #13 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 #1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6 #2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39 #3 0x000000000058bbc6 in ber_error_print (data=0x7ffbebe6cf20 " b6c6: 03 0a 01 04 30 22 02 03 02 38 56 17 0d 31 38 30 ....0\"...8V..180 \n") at bprint.c:87 #4 0x000000000058be41 in ber_bprint (data=0x7ffbe04282a0 "0\203UK\275\002\001\001d\203UK\265\004\062cn={REDACTED}0\203UK|0\203UKw\004 certificateRevocationList;binary1\203UKP\004\203UKK0\203UKF0\203UJ-\002\001\001\060\r\006\t*\206H\206\367\r\001\001\v\005", len=len@entry=5589954) at bprint.c:202 #5 0x000000000058bfb3 in ber_log_bprint (errlvl=errlvl@entry=16, loglvl=<optimized out>, data=<optimized out>, len=len@entry=5589954) at bprint.c:175 #6 0x000000000058b179 in ber_flush2 (sb=0x7ffbe17f55b0, ber=ber@entry=0x7ffbebe6d0f0, freeit=freeit@entry=0) at io.c:240 #7 0x0000000000447ee5 in send_ldap_ber (op=op@entry=0x7ffbe41bd940, ber=ber@entry=0x7ffbebe6d0f0) at result.c:339 #8 0x000000000044b290 in slap_send_search_entry (op=0x7ffbe41bd940, rs=<optimized out>) at result.c:1430 #9 0x00000000004bf3b4 in mdb_search (op=<optimized out>, rs=0x7ffbebffeaa0) at search.c:1085 #10 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41bd940, rs=0x7ffbebffeaa0, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677 #11 0x000000000049de86 in over_op_func (op=0x7ffbe41bd940, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #12 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #13 0x000000000043c33f in fe_op_search (op=0x7ffbe41bd940, rs=0x7ffbebffeaa0) at search.c:402 #14 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41bd940, rs=0x7ffbebffeaa0, which=op_search, oi=0x980e00, on=0x0) at backover.c:677 #15 0x000000000049de86 in over_op_func (op=0x7ffbe41bd940, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #16 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #17 0x000000000043bef6 in do_search (op=0x7ffbe41bd940, rs=0x7ffbebffeaa0) at search.c:247 #18 0x0000000000439bc4 in connection_operation (ctx=ctx@entry=0x7ffbebffebd0, arg_v=arg_v@entry=0x7ffbe41bd940) at connection.c:1158 #19 0x000000000043a9cb in connection_read_thread (ctx=0x7ffbebffebd0, argv=<optimized out>) at connection.c:1294 #20 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #21 0x00007ffff754cdd5 in start_thread (arg=0x7ffbebfff700) at pthread_create.c:307 #22 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 ldap_chain_op (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20, op_f=0x4a845e <ldap_back_search>, ref=ref@entry=0x0, depth=depth@entry=0) at chain.c:422 #1 0x00000000004e61da in ldap_chain_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at chain.c:1090 #2 0x000000000049d323 in over_back_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at backover.c:237 #3 0x0000000000447c1a in slap_response_play (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:508 #4 0x00000000004480f5 in send_ldap_response (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:583 #5 0x0000000000448d1f in slap_send_ldap_result (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at result.c:861 #6 0x00000000004bd8c3 in mdb_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:558 #7 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677 #8 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #9 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #10 0x00000000004d1a02 in relay_back_op (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=which@entry=2) at op.c:211 #11 0x00000000004d1b07 in relay_back_op_search (op=<optimized out>, rs=<optimized out>) at op.c:251 #12 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3af00, on=0x0) at backover.c:677 #13 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #14 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #15 0x000000000043c33f in fe_op_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:402 #16 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0x980e00, on=0x0) at backover.c:677 #17 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #18 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #19 0x000000000043bef6 in do_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:247 #20 0x0000000000439bc4 in connection_operation (ctx=0x7ffbf09bbbd0, arg_v=0x7ffbe41f0870) at connection.c:1158 #21 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #22 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf09bc700) at pthread_create.c:307 #23 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 #1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6 #2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39 #3 0x000000000058bbc6 in ber_error_print (data=0x7ffbf102af20 " e54c: 33 5a 30 0c 30 0a 06 03 55 1d 15 04 03 0a 01 04 3Z0.0...U....... \n") at bprint.c:87 #4 0x000000000058be41 in ber_bprint (data=0x7ffbe42cc110 "0\203UK\275\002\001\021d\203UK\265\004\062cn={REDACTED}0\203UK|0\203UKw\004 certificateRevocationList;binary1\203UKP\004\203UKK0\203UKF0\203UJ-\002\001\001\060\r\006\t*\206H\206\367\r\001\001\v\005", len=len@entry=5589954) at bprint.c:202 #5 0x000000000058bfb3 in ber_log_bprint (errlvl=errlvl@entry=16, loglvl=<optimized out>, data=<optimized out>, len=len@entry=5589954) at bprint.c:175 #6 0x000000000058b179 in ber_flush2 (sb=0x7ffbe422daa0, ber=ber@entry=0x7ffbf102b0f0, freeit=freeit@entry=0) at io.c:240 #7 0x0000000000447ee5 in send_ldap_ber (op=op@entry=0x7ffbe42197b0, ber=ber@entry=0x7ffbf102b0f0) at result.c:339 #8 0x000000000044b290 in slap_send_search_entry (op=0x7ffbe42197b0, rs=<optimized out>) at result.c:1430 #9 0x00000000004bf3b4 in mdb_search (op=<optimized out>, rs=0x7ffbf11bcaa0) at search.c:1085 #10 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe42197b0, rs=0x7ffbf11bcaa0, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677 #11 0x000000000049de86 in over_op_func (op=0x7ffbe42197b0, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #12 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #13 0x000000000043c33f in fe_op_search (op=0x7ffbe42197b0, rs=0x7ffbf11bcaa0) at search.c:402 #14 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe42197b0, rs=0x7ffbf11bcaa0, which=op_search, oi=0x980e00, on=0x0) at backover.c:677 #15 0x000000000049de86 in over_op_func (op=0x7ffbe42197b0, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #16 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #17 0x000000000043bef6 in do_search (op=0x7ffbe42197b0, rs=0x7ffbf11bcaa0) at search.c:247 #18 0x0000000000439bc4 in connection_operation (ctx=ctx@entry=0x7ffbf11bcbd0, arg_v=arg_v@entry=0x7ffbe42197b0) at connection.c:1158 #19 0x000000000043a9cb in connection_read_thread (ctx=0x7ffbf11bcbd0, argv=<optimized out>) at connection.c:1294 #20 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #21 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf11bd700) at pthread_create.c:307 #22 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 0x00007ffff674d603 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81 #1 0x000000000043618b in slapd_daemon_task (ptr=<optimized out>) at daemon.c:2539 #2 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf19be700) at pthread_create.c:307 #3 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 0x00007ffff754df47 in pthread_join (threadid=140720067045120, thread_return=thread_return@entry=0x0) at pthread_join.c:90 #1 0x00000000005642b8 in ldap_pvt_thread_join (thread=<optimized out>, thread_return=thread_return@entry=0x0) at thr_posix.c:197 #2 0x0000000000437766 in slapd_daemon () at daemon.c:2932 #3 0x0000000000420b84 in main (argc=<optimized out>, argv=0x7fffffffe408) at main.c:1017 The above trace seems to suggest the source of the segfault is coming from the ldap_chain_op function at chain.c:422. We use chain forwarding for ppolicy operations on the consumers. This is the line: for ( ; !BER_BVISNULL( ref ); ref++ ) { BER_BVISNULL is not a function but a macro which is defined (lber_pvt.h:216) as follows: #define BER_BVISNULL(bv) ((bv)->bv_val == NULL) The above seems suggests that ref is set to null at the time of the check. When I double checked my chain configs I noticed there was an entry that did not contain the olcDbURI attribute that I did not create. It seems that this particular entry was created by the cn=config conversion for the following slapd.conf configuration: Overlay chain chain-proxy-whoami yes chain-uri {REDACTED URI 1} Chain-cache-uri FALSE Chain-max-depth 1 Chain-return-error TRUE Chain-idassert-bind bindmethod=“simple” binddn={REDACTED} credentials={REDACTED} Chain-protocol-version 3 chain-uri {REDACTED URI 2} Chain-cache-uri FALSE Chain-max-depth 1 Chain-return-error TRUE Chain-idassert-bind bindmethod=“simple” binddn={REDACTED} credentials={REDACTED} Chain-protocol-version 3 chain-uri {REDACTED URI 3} Chain-cache-uri FALSE Chain-max-depth 1 Chain-return-error TRUE Chain-idassert-bind bindmethod=“simple” binddn={REDACTED} credentials={REDACTED} Chain-protocol-version 3 After the conversion to cn=config: dn: olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {1}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: TRUE dn: olcDatabase={0}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbStartTLS: ldaps starttls=no olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 dn: olcDatabase={1}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: “{REDACTED URI 1}“ olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/ cacerts.cer" tls_reqcert=demand tls_crlcheck=none olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 dn: olcDatabase={2}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {2}ldap olcDbURI: “{REDACTED URI 2}“ olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/ cacerts.cer" tls_reqcert=demand tls_crlcheck=none olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 dn: olcDatabase={3}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {3}ldap olcDbURI: “{REDACTED URI 3}“ olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/ cacerts.cer" tls_reqcert=demand tls_crlcheck=none olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 I am wondering if the following is causing the segfaults: When setting up the configs during the slapd.d conversion, the slapd.conf -> cn=config converter added an extra unnecessary entry for the chain config (there are 4 ldap proxy entries instead of 3). This particular entry that was added does not have an olcDbURI value. Since the referral string is set by the olcDbURI attribute value the missing value results in NULL being set for ref. However, I have not yet been able to manually trigger the segfault by invoking ppolicy. I also found a red hat ticket that seemd to detail the same issue (see https://bugzilla.redhat.com/show_bug.cgi?id=1644654). Any ideas on this? I can also obtain a trace of all the threads if needed. 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 1

what the error "ldap_sasl_interactive_bind_s: Unknown authentication method (-6)" means?
by Peter Sui 13 Jan '20

13 Jan '20

I'm trying to test SASL EXTERNAL to an AD server, which saying support EXTERNAL. the command I ran is: ldapwhoami -H ldap://example.com:389 -YEXTERNAL but it returned: ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: what does this error message mean? I already installed the necessary package, here is my dpkg return: ~$ dpkg -l | grep sasl ii libauthen-sasl-perl 2.1600-1 all Authen::SASL - SASL Authentication framework ii libsasl2-2:amd64 2.1.27~101-g0780600+dfsg-3ubuntu2 amd64 Cyrus SASL - authentication abstraction library ii libsasl2-dev 2.1.27~101-g0780600+dfsg-3ubuntu2 amd64 Cyrus SASL - development files for authentication abstraction library ii libsasl2-modules:amd64 2.1.27~101-g0780600+dfsg-3ubuntu2 amd64 Cyrus SASL - pluggable authentication modules ii libsasl2-modules-db:amd64 2.1.27~101-g0780600+dfsg-3ubuntu2 amd64 Cyrus SASL - pluggable authentication modules (DB) ii libsasl2-modules-gssapi-mit:amd64 2.1.27~101-g0780600+dfsg-3ubuntu2 amd64 Cyrus SASL - pluggable authentication modules (GSSAPI) and I can run ldapwhoami with SASL GSSAPI against the above mentioned AD server successfully. the error seems the "EXTERNAL" is not even supported, is not about invalid credential. I also tried to created a new certificate with the server credential, and modified the .ldaprc to point to the new certificate. still does not work. who can tell me how ? Thanks ahead! Peter

4 4

Replication of olcAccess
by Stefan Kania 13 Jan '20

13 Jan '20

Hello, I try to replicate the olcAccess, olcLimits and olcDbIndex Attributes here is the Database where the olcx Attributes located on the Master ---------------- dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to dn.exact="" by * read olcAccess: {1}to attr=entry,uid by anonymous auth by * break ... ---------------- I created an ldif to add there olcSyncrepl to the slave: ---------------- dn: olcDatabase={1}mdb,cn=config changetype: modify add:olcSyncrepl olcSyncrepl: rid=001 provider=ldap://ldapserver.example.net type=refreshandpersist retry="60 10 120 5" searchbase="olcDatabase={1}mdb,cn=config" attrs="olcAccess,olcLimits,olcDbIndex" bindmethod=simple binddn="cn=admin,cn=config" credentials=***** ---------------- When I try to add it to my config i always get: ---------------- root@ldapserver-02:/daten# ldapmodify -Y EXTERNAL -H ldapi:/// -f sync-config.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={1}mdb,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: Base DN "olcDatabase={1}mdb,cn=config" is not within the database naming context ---------------- Here are all dn-entries from the master: ---------------- dn: cn=config dn: cn=module{0},cn=config dn: cn=schema,cn=config dn: cn={0}core,cn=schema,cn=config dn: cn={1}cosine,cn=schema,cn=config dn: cn={2}nis,cn=schema,cn=config dn: cn={3}inetorgperson,cn=schema,cn=config dn: cn={4}kerberos,cn=schema,cn=config dn: cn={5}sshkey,cn=schema,cn=config dn: olcBackend={0}mdb,cn=config dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config dn: olcDatabase={1}mdb,cn=config dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config dn: olcOverlay={1}syncprov,olcDatabase={1}mdb,cn=config dn: olcDatabase={2}mdb,cn=config ---------------- And from the slave: ---------------- dn: cn=config dn: cn=module{0},cn=config dn: cn=schema,cn=config dn: cn={0}core,cn=schema,cn=config dn: cn={1}cosine,cn=schema,cn=config dn: cn={2}nis,cn=schema,cn=config dn: cn={3}inetorgperson,cn=schema,cn=config dn: cn={4}kerberos,cn=schema,cn=config dn: cn={5}sshkey,cn=schema,cn=config dn: olcBackend={0}mdb,cn=config dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcDatabase={1}mdb,cn=config ---------------- What do I have to put into the "searchbase"? Replication of the object-DB is working. But I want the ACLs to be replicated too. Here is the ldif-file I used to set up the object-db replication --------------- dn: olcDatabase={1}mdb,cn=config changetype: modify add:olcSyncrepl olcSyncrepl: rid=000 provider=ldap://ldapserver.example.net type=refreshandpersist retry="60 10 120 5" searchbase="dc=example,dc=net" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=admin,dc=example,dc=net" credentials=***** --------------- thank's for any help Stefan

4 9

structural objectclass checking
by Markus.Storm＠t-systems.com 11 Jan '20

11 Jan '20

Hi, is there a way to disable OpenLDAP checking entries for existence of STRUCTURAL objectclasses? I know it's illegal per standard to have either no or multiple objectclasses of STRUCTURAL type on an entry. Unfortunately in the enterprise world it is very common that you have to deal with existing data which is even beyond your control. Our LDAP is full of such 'bad' records, making imports into OpenLDAP fail for 50% of our entries. I'm trying to present OpenLDAP as an alternative to the commercial LDAP software my company is currently running but I need to come up with a solution to this in order to convince our managers and engineering. Competition such as Oracle Unified Dir have an option to selectively disable this type of checking. Is there a way to do it in OpenLDAP via config? If no, would it be rather easy or hard to add that to the code myself ? I once made a similar patch but it had to be applied in a single location within the source only. Thanks Best regards Markus

5 6

Re: ldapsearch utility
by Peter Sui 08 Jan '20

08 Jan '20

Hi Quanah, Thanks for your response, another question about the SASL. I know for the ldap server, some settings must be done, what about for the client side? If I only installed the open ldap library and client tools, and if I want to use SASL GSSAPI, will this be enough ? do I need to install other modules like Kerberos V? Thank you in advance! Peter On Tue, Jan 7, 2020 at 2:15 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Tuesday, January 7, 2020 7:49 AM -0500 Peter Sui <peters(a)qnext.com> > wrote: > > so question here, what password it asked here? since it's not asking for > > a DN. There could be many credentials here, will the server figure out > > the user by the password input? > > Hi Peter, > > The OpenLDAP admin guide specifically discusses in detail how to set up > and > configure SASL/DIGEST-MD5. Please see > <https://www.openldap.org/doc/admin24/sasl.html#DIGEST-MD5> > > 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: Openldap support SHA-256 or SHA-3.
by Quanah Gibson-Mount 08 Jan '20

08 Jan '20

--On Tuesday, January 7, 2020 10:44 AM -0800 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Does openldap support SHA-256 or SHA-3 schemes? to address the below > issues? There is a module in contrib that is included with most vendor builds that allows up to SSHA512. I've long suggested using it. The default of SSHA1 is mandated by RFC (which IMHO needs updating at this point). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical