openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 07 Oct '17

07 Oct '17

On Fri, Sep 15, 2017 at 07:54:22PM -0700, Paul B. Henson wrote: > I've been running 2.4.44 with the test patch since May and haven't seen > a crash since, for what that's worth. We upgraded to 2.4.45 last week, > without that patch. I'm going to see if the crash shows up again, and if > it does, apply the patch to 2.4.45 and see if it goes away again. Well, since upgrading, I've now seen two crashes; I don't have it compiled with debugging right now so the trace is limited: #0 0x0000000000483eb9 in modify_add_values () #1 0x00007f7b80d45bc3 in mdb_modify_internal () from /usr/lib64/openldap/openldap/back_mdb.so #2 0x00007f7b80d46f55 in mdb_modify () from /usr/lib64/openldap/openldap/back_mdb.so #3 0x000000000049a6d2 in overlay_op_walk () #4 0x000000000049a82a in ?? () #5 0x000000000048bbef in ?? () #6 0x000000000048f8cf in ?? () #7 0x0000000000493ae3 in ?? () #8 0x00007f7b858327f2 in ?? () from /usr/lib64/libldap_r-2.4.so.2 #9 0x00007f7b84bb03e4 in start_thread () from /lib64/libpthread.so.0 #10 0x00007f7b848f23ed in clone () from /lib64/libc.so.6 but it looks like the same issue to me. I'm going to go ahead and recompile 2.4.45 with the ignore-invalid-accesslog-ops.patch and run that for a while and see what happens. Thanks...

1 0

(ITS#8752) MMR delta-sync deadlock using slapd.conf
by quanah＠openldap.org 05 Oct '17

05 Oct '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) There is a reproducible lockup with delta-sync based multimaster replication. The more masters exist the easier it is to trigger, with 100% reproducibility at 4 masters. Generally: Load a database onto a server with no syncprov/accesslog configuration. Stop slapd Reconfigure slapd.conf to include syncprov/accesslog overlays, and cn=accesslog DB for changes, and replication agreements with other servers Configure other servers for syncprov/accesslog, but no database start slapd on all servers execute a MOD operation sequentially across the servers (1, 2, 3, 4) slapd will deadlock on server 3 or 4 100% of the time

1 0

(ITS#8751) deref aliases with back meta goes wrong in db_cache_find_ndn()
by paul＠subsignal.org 04 Oct '17

04 Oct '17

Full_Name: Paul K.lle Version: 24.44 OS: omnios URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.43.201.48) Disclaimer: I don't know C very well and I'm a complete noob wrt OpenLDAP source meta (dc=btu,dc=local) with two olcMetaSub URI: 0 -> olcDbURI ldap://localhost/ou=Fak6,dc=btu,dc=local olcDbRewrite {0}suffixmassage "ou=Fak6,dc=btu,dc=local" "ou=Fak6,dc=IT,dc=local" 1 -> olcDbURI ldap://ldap.xxxxx.de/ou=People,dc=btu,dc=local olcDbRewrite » {0}suffixmassage "ou=People,dc=btu,dc=local" "ou=People,o=XXXXXXXXXXXXX XXXXX,c=De" no deref search: [root@smb01 ~]# ldapsearch -x -h 192.168.70.101 -b ou=users,ou=Fak6,dc=btu,dc=local '(cn=Paul*)' '*' # extended LDIF # # LDAPv3 # base <ou=users,ou=Fak6,dc=btu,dc=local> with scope subtree # filter: (cn=Paul*) # requesting: * # # Paul Koelle, Users, Fak6, btu.local dn: cn=Paul Koelle,ou=Users,ou=Fak6,dc=btu,dc=local aliasedObjectName: cn=Paul Koelle,ou=People,dc=btu,dc=local cn: Paul Koelle objectClass: alias objectClass: extensibleObject # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 with deref: [root@smb01 ~]# ldapsearch -a always -x -h 192.168.70.101 -b ou=users,ou=Fak6,dc=btu,dc=local '(cn=Paul*)' '*' # extended LDIF # # LDAPv3 # base <ou=users,ou=Fak6,dc=btu,dc=local> with scope subtree # filter: (cn=Paul*) # requesting: * # # search result search: 2 result: 0 Success # numResponses: 1 debug log reveals: 59d38a50 bdb_idl_fetch_key: [01872a84] 59d38a50 <= bdb_index_read 1 candidates 59d38a50 <= bdb_equality_candidates: id=1, first=19, last=19 59d38a50 <= bdb_filter_candidates: id=1 first=19 last=19 59d38a50 => hdb_dn2idl("ou=users,ou=fak6,dc=it,dc=local") 59d38a50 bdb_dn2entry("cn=paul koelle,ou=people,dc=btu,dc=local") 59d38a50 => hdb_dn2id("c=btu,dc=local") 59d38a50 <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) 59d38a50 bdb_search_candidates: failed (rc=33) breakpoint for hdb_dn2id (gdb) bt #0 hdb_dn2id (op=0xa05510, in=0xfffffd7ffc87f208, ei=0xfffffd7ffc87f1f0, txn=0x8e6950, cursor=0xfffffd7ffc87f1e0) at dn2id.c:705 #1 0x000000000059beed in hdb_cache_find_ndn (op=0xa05510, txn=0x8e6950, ndn=0xfffffd7ffc87f350, res=0xfffffd7ffc87f2e0) at cache.c:462 #2 0x00000000005a3d81 in hdb_dn2entry (op=0xa05510, tid=0x8e6950, dn=0xfffffd7ffc87f350, e=0xfffffd7ffc87f348, matched=0, lock=0xfffffd7ffc87f330) at dn2entry.c:47 #3 0x000000000053756c in deref_base (op=0xa05510, rs=0xfffffd7ffc9ffb40, e=0x91c0b8, matched=0xfffffd7ffc87f460, txn=0x8e6950, lock=0xfffffd7ffc87f3c0, tmp=0x10e3010, visited=0xf63010) at search.c:104 #4 0x0000000000537be7 in search_aliases (op=0xa05510, rs=0xfffffd7ffc9ffb40, e=0xfffffd7ffc87f750, txn=0x8e6950, ids=0xfffffd7ffc8ff7a0, scopes=0xfffffd7ffc87f7a0, stack=0xde3010) at search.c:250 #5 0x000000000053ab3d in search_candidates (op=0xa05510, rs=0xfffffd7ffc9ffb40, e=0xfffffd7ffc87f750, txn=0x8e6950, ids=0xfffffd7ffc8ff7a0, scopes=0xfffffd7ffc87f7a0) at search.c:1258 #6 0x0000000000538e27 in hdb_search (op=0xa05510, rs=0xfffffd7ffc9ffb40) at search.c:616 #7 0x000000000048438d in fe_op_search (op=0xa05510, rs=0xfffffd7ffc9ffb40) at search.c:402 #8 0x0000000000483bcc in do_search (op=0xa05510, rs=0xfffffd7ffc9ffb40) at search.c:247 #9 0x0000000000480537 in connection_operation (ctx=0xfffffd7ffc9ffc70, arg_v=0xa05510) at connection.c:1158 #10 0x0000000000480acc in connection_read_thread (ctx=0xfffffd7ffc9ffc70, argv=0xf) at connection.c:1294 #11 0x0000000000622afd in ldap_int_thread_pool_wrapper (xpool=0x7d8840) at tpool.c:696 #12 0xfffffd7ffeb9e43a in _thrp_setup () from /lib/64/libc.so.1 #13 0xfffffd7ffeb9e750 in ?? () from /lib/64/libc.so.1 #14 0x0000000000000000 in ?? () if you look at the arguments in (h|b)db_cache_find_ndn there are mixed values from pre/post meta rewrite? #1 0x000000000059beed in hdb_cache_find_ndn (op=0xa05510, txn=0x8e6950, ndn=0xfffffd7ffc87f350, res=0xfffffd7ffc87f2e0) at cache.c:462 462 rc = bdb_dn2id( op, &ei.bei_nrdn, &ei, txn, &cursor ); (gdb) p *ndn $8 = {bv_len = 40, bv_val = 0x9fdd06 "cn=paul koelle,ou=people,dc=btu,dc=local"} (gdb) p *res $9 = (EntryInfo *) 0x0 (gdb) p ndn->bv_val $13 = 0x9fdd06 "cn=paul koelle,ou=people,dc=btu,dc=local" (gdb) p op->o_bd->be_nsuffix[0] $16 = {bv_len = 14, bv_val = 0x9f17d0 "dc=it,dc=local"} and the code in bdb_cache_find_ndn constructs a new BV from *ndn and *op which have different bases (cache.c line 426): /* we're searching a full DN from the root */ ptr = ndn->bv_val + ndn->bv_len - op->o_bd->be_nsuffix[0].bv_len; ei.bei_nrdn.bv_val = ptr; ei.bei_nrdn.bv_len = op->o_bd->be_nsuffix[0].bv_len; where op->o_bd_>be_nsuffix[0] is the post-rewrite suffix and ndn has the pre-rewrite suffix?? continuing lead to the following debug output: 59d38434 => hdb_dn2id("c=btu,dc=local") 59d38434 <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) note the incomplete "c=btu,dc=local" probably because "dc=it,dc=local" is one char less than "dc=btu,dc=local"

1 0

Re: (ITS#8747) LDAP load balancer daemon (lloadd)
by ondra＠mistotebe.net 02 Oct '17

02 Oct '17

On Thu, Sep 28, 2017 at 04:13:46PM +0000, ondra(a)openldap.org wrote: > The 'lloadd' branch linked above contains the load balancer code that > is now ready for review. > > This adds a new server to the OpenLDAP project, a load balancing proxy > (prototype). To summarise the reasons for this project to exist and highlight its features, limitations: - most LDAP load balancers pin a connection to another server and then just ship data, lloadd can distribute operations from a single client connection across LDAP servers - to make the above possible, lloadd sets up connections to the backend servers on startup and manages them as per configuration (independent on the clients) - bind operations are forwarded over dedicated bind connections or using the VC exop if feature 'vc' is enabled in its config, the designated identity is then passed on with the operations with proxyauth control (if feature 'proxyauthz' is enabled) - it is expected that all backends are indistinguishable (same features, suffixes, data) - no SASL bind support yet - if an operation cannot be processed or forwarded for any reason (overload, connection loss, ...), it is never re-sent, client will however still be sent an appropriate result in that case The lloadd.8 and lloadd.conf.5 manpages are provided, Admin guide and further documentation will come as the implementation matures. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: AW: (ITS#8749) Proxy: LDAP-querry doesn't work for e.g(userAccountControl:1.2.840.113556.1.4.803:=2)
by michael＠stroeder.com 01 Oct '17

01 Oct '17

steffen.krahl(a)nexio.de wrote: > Regarding segmentation fault: that's true, but I have to investigate > further Please make sure to install with debug symbols and read how to use gdb to obtain a stack back trace: https://www.openldap.org/faq/data/cache/59.html Ciao, Michael.

1 0

AW: (ITS#8749) Proxy: LDAP-querry doesn't work for e.g (userAccountControl:1.2.840.113556.1.4.803:=2)
by Steffen.Krahl＠nexio.de 01 Oct '17

01 Oct '17

RGVhciBNaWNoYWVsLA0KDQptYW55IHRoYW5rcyBmb3IgeW91ciBleHBsYWluYXRpb24uIFJlZ2FyZGlu ZyBzZWdtZW50YXRpb24gZmF1bHQ6IHRoYXQncyB0cnVlLCBidXQgSSBoYXZlIHRvIGludmVzdGlnYXRl IGZ1cnRoZXINCg0KQlINClN0ZWZmZW4gDQoNCi0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0t LS0NClZvbjogTWljaGFlbCBTdHLDtmRlciBbbWFpbHRvOm1pY2hhZWxAc3Ryb2VkZXIuY29tXSANCkdl c2VuZGV0OiBTb25udGFnLCAxLiBPa3RvYmVyIDIwMTcgMTA6MjUNCkFuOiBLcmFobCwgU3RlZmZlbjsg b3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZw0KQmV0cmVmZjogUmU6IChJVFMjODc0OSkgUHJveHk6IExE QVAtcXVlcnJ5IGRvZXNuJ3Qgd29yayBmb3IgZS5nICh1c2VyQWNjb3VudENvbnRyb2w6MS4yLjg0MC4x MTM1NTYuMS40LjgwMzo9MikNCg0Kc3RlZmZlbi5rcmFobEBuZXhpby5kZSB3cm90ZToNCj4gSSdtIHVz aW5nIE9wZW5MREFQIHdpdGggTERBUC1iYWNrZW5kIGFzIHByb3h5IGZvciBBY3RpdmVEaXJlY3Rvcnkg DQo+IEl0J3Mgd29ya2luZyB3ZWxsIHNvIGZhciwgb25seSBMREFQLXF1ZXJpZXMgd2hpY2ggc2hvdWxk IGV4Y2x1ZGUNCj4gZGVhY3RpdmF0ZWQgdXNlcnMgZG9uJ3Qgd29yay4gSXQgc2VlbXMgc2xhcGQgZG9l cyBub3QgYWNjZXB0IHF1ZXJpZXMNCj4gbGlrZSAoYXR0cmlidXRlOk9JRDo9dmFsdWUpDQoNCk9wZW5M REFQIGRvZXMgc3VwcG9ydCBleHRlbmRlZCBmaWx0ZXJzIHdpdGggYSBtYXRjaGluZyBydWxlLiBCdXQg b25seQ0Kd2l0aCBtYXRjaGluZyBydWxlcyBpbXBsZW1lbnRlZCBpbiBPcGVuTERBUC4NCg0KPiBpbiBw YXJ0aWN1bGFyDQo+ICghKHVzZXJBY2NvdW50Q29udHJvbDoxLjIuODQwLjExMzU1Ni4xLjQuODAzOj0y KSkpDQoNClRoZSBtYXRjaGluZyBydWxlIGRlZmluZWQgYnkgMS4yLjg0MC4xMTM1NTYuMS40LjgwMyBp cyBhIHByb3ByaWV0YXJ5DQptYXRjaGluZyBydWxlIGRlZmluZWQgYnkgTWljcm9zb2Z0IGZvciBiaXQt d2lzZSBtYXRjaGluZy4gQUZBSUNTIHRoZXkNCm5ldmVyIHdyb3RlIGEgcHVibGljIGZvcm1hbCBzcGVj IGZvciBpdC4gU28gdGhpcyBwYXJ0aWN1bGFyIG1hdGNoaW5nDQpydWxlIGlzIG5vdCBpbXBsZW1lbnRl ZCBpbiBPcGVuTERBUC4NCg0KPiBwZXJmb3JtaW5nIHVwcGVyIHF1ZXJ5IGdldHM6IE9jdCAgMSAwMDo0 NTozMyBueGxkMDEgc2xhcGRbMzAwMl06DQo+IHN0cjJmaWx0ZXIgIigmKHNBTUFjY291bnRUeXBlPSA4 MDUzMDYzNjgpKD89ZXJyb3IpKSIgT2N0ICAxIDAwOjQ1OjMzDQo+IG54bGQwMSBrZXJuZWw6IFs0OTQz Ni45MzM3MzVdIHNsYXBkWzMwMDVdOiBzZWdmYXVsdCBhdCAxOCBpcCANCj4gMDAwMDdmZjRmNzgzZDUx MiBzcCAwMDAwN2ZmNGYxYWZjODEwIGVycm9yIDQgaW4gDQo+IGxpYmMtMi4yMy5zb1s3ZmY0Zjc3Yjkw MDArMWMwMDAwXQ0KDQpEb2VzIHRoYXQgbWVhbiBzbGFwZCBzZWcgZmF1bHRzPyBJdCBzaG91bGRuJ3Qu DQoNCj4gcGVyZm9ybWluZyB0aGUgZm9sbG93aW5nIHF1ZXJ5DQo+ICAoJihvYmplY3RDbGFzcz0qKSh1 c2VyQWNjb3VudENvbnRyb2w6MS4yLjg0MC4xMTM1NTYuMS40LjgwMzo9MikpDQo+IHdpbGwgZ2V0IGZv bGxvd2luZyBsb2cgd250cnk6DQo+IE9jdCAgMSAwMDo0OTowNyBueGxkMDEgc2xhcGRbMzAzM106IHN0 cjJmaWx0ZXINCj4gIigmKG9iamVjdENsYXNzPSopKCEob2JqZWN0Q2xhc3M9KikpKSINCg0KSU1PIGl0 IG1ha2VzIHBlcmZlY3Qgc2Vuc2UgdG8gdHJlYXQgZXh0ZW5kZWQgZmlsdGVyIHBhcnQgd2l0aCBhDQpu b24tc3VwcG9ydGVkIG1hdGNoaW5nIHJ1bGUgYXMgYSBmaWx0ZXIgd2hpY2ggYWx3YXlzIGV2YWx1YXRl cyB0byBGYWxzZS4NCg0KQ2lhbywgTWljaGFlbC4NCg0KCgpTaXR6IGRlciBHZXNlbGxzY2hhZnQ6IE5p ZWRlci1PbG0gCkFtdHNnZXJpY2h0IE1haW56LCBIUkIgNzE4NQpVU3QuLUlEOiBERSAyMDggMzAzIDY2 NgpHZXNjaMOkZnRzZsO8aHJlcjogQW5kcmVhIE1hbmRhbmljaQoKRGllc2UgRS1NYWlsIGVudGjDpGx0 IHZlcnRyYXVsaWNoZSBvZGVyIHJlY2h0bGljaCBnZXNjaMO8dHp0ZSBJbmZvcm1hdGlvbmVuLiBXZW5u IFNpZSBuaWNodCBkZXIgcmljaHRpZ2UgQWRyZXNzYXQgc2luZCBvZGVyIGRpZXNlIEUtTWFpbCBpcnJ0 w7xtbGljaCBlcmhhbHRlbiBoYWJlbiwgaW5mb3JtaWVyZW4gU2llIGJpdHRlIHNvZm9ydCBkZW4gQWJz ZW5kZXIgdW5kIHZlcm5pY2h0ZW4gU2llIGRpZXNlIEUtTWFpbC4gRGFzIHVuZXJsYXVidGUgS29waWVy ZW4gc293aWUgZGllIHVuYmVmdWd0ZSBXZWl0ZXJnYWJlIGRpZXNlciBFLU1haWwgaXN0IG5pY2h0IGdl c3RhdHRldC4KClRoaXMgRS1NYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQvb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCAob3Ig aGF2ZSByZWNlaXZlZCB0aGlzIEUtTWFpbCBpbiBlcnJvcikgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkZXN0cm95IHRoaXMgRS1NYWlsLiBBbnkgdW5hdXRob3Jpc2VkIGNvcHlp bmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRoZSBtYXRlcmlhbCBpbiB0aGlzIEUtTWFp bCBpcyBzdHJpY3RseSBmb3JiaWRkZW4u

1 0

(ITS#8750) About the implementation of mutex lock(li_log_mutex) in accesslog_purge()
by yos-nishino＠ys.jp.nec.com 01 Oct '17

01 Oct '17

Full_Name: Yoshinori Nishino Version: 2.4.45 OS: CentOS 7.3.1611 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.143.35.20) Dear sir, I saw the deadlock between accesslog_purge() and accesslog_responce(), both of which are implemented in servers/slapd/overlays/accesslog.c. The deadlock was caused by __db_hybrid_mutex_suspend() in libdb-5.3.so(hdb). ==[the output of pstack]== Thread 22 (Thread 0x7f1c845ec700 (LWP 23001)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 21 (Thread 0x7f1c82dea700 (LWP 23002)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 20 (Thread 0x7f1c825e9700 (LWP 23003)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 19 (Thread 0x7f1c81de8700 (LWP 23004)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 18 (Thread 0x7f1c815e7700 (LWP 23005)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 17 (Thread 0x7f1c80de6700 (LWP 23006)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 16 (Thread 0x7f1c477f0700 (LWP 23007)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 15 (Thread 0x7f1c46fef700 (LWP 23009)): #0 0x00007f2e17e856d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f2e1860b2f3 in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so #2 0x00007f2e1860a640 in __db_tas_mutex_lock () from /lib64/libdb-5.3.so #3 0x00007f2e186b4d3a in __lock_get_internal () from /lib64/libdb-5.3.so #4 0x00007f2e186b5820 in __lock_get () from /lib64/libdb-5.3.so #5 0x00007f2e186e1142 in __db_lget () from /lib64/libdb-5.3.so #6 0x00007f2e18612602 in __bamc_writelock () from /lib64/libdb-5.3.so #7 0x00007f2e186cd079 in __dbc_idel () from /lib64/libdb-5.3.so #8 0x00007f2e186d1113 in __dbc_del () from /lib64/libdb-5.3.so #9 0x00007f2e186dc3db in __dbc_del_pp () from /lib64/libdb-5.3.so #10 0x00007f2e1913b382 in hdb_dn2id_delete () #11 0x00007f2e191394ca in hdb_delete () #12 0x00007f2e190d6996 in overlay_op_walk () #13 0x00007f2e190d6b04 in over_op_func () #14 0x00007f2e110f3399 in accesslog_purge () from /usr/lib64/openldap/accesslog-2.4.so.2 #15 0x00007f2e18bb9fba in ldap_int_thread_pool_wrapper () from /lib64/libldap_r-2.4.so.2 #16 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #17 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 14 (Thread 0x7f1c467ee700 (LWP 23008)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x7f1c45fed700 (LWP 23010)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x7f1c457ec700 (LWP 23011)): #0 0x00007f2e17e856d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f2e18bba00b in ldap_int_thread_pool_wrapper () from /lib64/libldap_r-2.4.so.2 #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x7f1c44feb700 (LWP 23012)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 10 (Thread 0x7f1c447ea700 (LWP 23013)): #0 0x00007f2e17e856d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f2e18bba00b in ldap_int_thread_pool_wrapper () from /lib64/libldap_r-2.4.so.2 #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x7f1c43fe9700 (LWP 23014)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x7f1c437e8700 (LWP 23015)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x7f1c42fe7700 (LWP 23016)): #0 0x00007f2e17e856d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f2e1860b2f3 in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so #2 0x00007f2e1860a640 in __db_tas_mutex_lock () from /lib64/libdb-5.3.so #3 0x00007f2e186b4d3a in __lock_get_internal () from /lib64/libdb-5.3.so #4 0x00007f2e186b5820 in __lock_get () from /lib64/libdb-5.3.so #5 0x00007f2e186e1142 in __db_lget () from /lib64/libdb-5.3.so #6 0x00007f2e18628605 in __bam_search () from /lib64/libdb-5.3.so #7 0x00007f2e18613256 in __bamc_search () from /lib64/libdb-5.3.so #8 0x00007f2e1861790f in __bamc_put () from /lib64/libdb-5.3.so #9 0x00007f2e186ce514 in __dbc_iput () from /lib64/libdb-5.3.so #10 0x00007f2e186c9a0e in __db_put () from /lib64/libdb-5.3.so #11 0x00007f2e186defa4 in __db_put_pp () from /lib64/libdb-5.3.so #12 0x00007f2e1913acec in hdb_dn2id_add () #13 0x00007f2e1913261b in hdb_add () #14 0x00007f2e190d6996 in overlay_op_walk () #15 0x00007f2e190d6b04 in over_op_func () #16 0x00007f2e110f44e4 in accesslog_response () from /usr/lib64/openldap/accesslog-2.4.so.2 #17 0x00007f2e190d5d48 in over_back_response () #18 0x00007f2e19078243 in slap_response_play () #19 0x00007f2e19078800 in send_ldap_response () #20 0x00007f2e19079392 in slap_send_ldap_result () #21 0x00007f2e190f438d in hdb_modify () #22 0x00007f2e190d6996 in overlay_op_walk () #23 0x00007f2e190d6b04 in over_op_func () #24 0x00007f2e190c7bae in syncrepl_message_to_op () #25 0x00007f2e190cab57 in do_syncrep2 () #26 0x00007f2e190cf95b in do_syncrepl () #27 0x00007f2e190689f1 in connection_read_thread () #28 0x00007f2e18bb9fba in ldap_int_thread_pool_wrapper () from /lib64/libldap_r-2.4.so.2 #29 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #30 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x7f1c427e6700 (LWP 23018)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x7f1c41fe5700 (LWP 23017)): #0 0x00007f2e17e881bd in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f2e17e83d02 in _L_lock_791 () from /lib64/libpthread.so.0 #2 0x00007f2e17e83c08 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007f2e110f3f54 in accesslog_response () from /usr/lib64/openldap/accesslog-2.4.so.2 #4 0x00007f2e190d5d48 in over_back_response () #5 0x00007f2e19078243 in slap_response_play () #6 0x00007f2e19078800 in send_ldap_response () #7 0x00007f2e19079392 in slap_send_ldap_result () #8 0x00007f2e190f438d in hdb_modify () #9 0x00007f2e190d6996 in overlay_op_walk () #10 0x00007f2e190d6b04 in over_op_func () #11 0x00007f2e1909d7d3 in passwd_extop () #12 0x00007f2e1909bccc in fe_extended () #13 0x00007f2e1909ba7d in do_extended () #14 0x00007f2e19067d0c in connection_operation () #15 0x00007f2e1906807b in connection_read_thread () #16 0x00007f2e18bb9fba in ldap_int_thread_pool_wrapper () from /lib64/libldap_r-2.4.so.2 #17 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #18 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7f1c417e4700 (LWP 23019)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f1c40fe3700 (LWP 23020)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f1c3bfff700 (LWP 23021)): #0 0x00007f2e17344d13 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f2e19062ee8 in slapd_daemon_task () #2 0x00007f2e17e81dc5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f2e1734473d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f2e1900d740 (LWP 22992)): #0 0x00007f2e17e82ef7 in pthread_join () from /lib64/libpthread.so.0 #1 0x00007f2e19064de1 in slapd_daemon () #2 0x00007f2e1904bb62 in main () ==== ==[the output of "db_stat -C A"]== Default locking region information: 9 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 3600 Initial number of locks allocated 0 Initial number of lockers allocated 3600 Initial number of lock objects allocated 26000 Maximum number of locks possible 26000 Maximum number of lockers possible 26000 Maximum number of lock objects possible 3600 Current number of locks allocated 18 Current number of lockers allocated 3600 Current number of lock objects allocated 720 Number of lock object partitions 32771 Size of object hash table 15 Number of current locks 2044 Maximum number of locks at any one time 4 Maximum number of locks in any one bucket 1 Maximum number of locks stolen by for an empty partition 1 Maximum number of locks stolen for any one partition 17 Number of current lockers 17 Maximum number of lockers at any one time 11 Number of current lock objects 1456 Maximum number of lock objects at any one time 3 Maximum number of lock objects in any one bucket 0 Maximum number of objects stolen by for an empty partition 0 Maximum number of objects stolen for any one partition 301M Total number of locks requested (301292352) 301M Total number of locks released (301292334) 0 Total number of locks upgraded 7 Total number of locks downgraded 3 Lock requests not available due to conflicts, for which we waited 2 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 2GB 524MB 688KB Region size 0 The number of partition locks that required waiting (0%) 0 The maximum number of times any partition lock was waited for (0%) 0 The number of object queue operations that required waiting (0%) 0 The number of locker allocations that required waiting (0%) 0 The number of region locks that required waiting (0%) 3 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Environment Region type 1 Region ID /var/lib/ldap/accesslog_db/__db.001 Region name 0x7f0ffe75b000 Region address 0x7f0ffe75b0a0 Region allocation head 0x7f0ffe95b5b0 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 1032145 allocations, 0 failures, 1030659 frees, 1 longest Allocations by power-of-two sizes: 1KB 1032140 2KB 0 4KB 0 8KB 0 16KB 0 32KB 0 64KB 1 128KB 0 256KB 0 512KB 0 1024KB 4 REGION_SHARED Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock region parameters: 2 Lock region region mutex [0/11M 0% 6376/139709380257600] 32771 locker table size 32771 object table size 2099280 obj_off 5570968 locker_off 0 need_dd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock conflict matrix: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd= 0 locks held 1 write locks 0 pid/thread 22992/139835964708672 flags 10 priority 100 1 READ 1 HELD id2entry.bdb handle 0 2 dd= 0 locks held 1 write locks 0 pid/thread 22992/139835964708672 flags 10 priority 100 2 READ 1 HELD dn2id.bdb handle 0 3 dd= 0 locks held 0 write locks 0 pid/thread 22992/139835964708672 flags 0 priority 100 4 dd= 0 locks held 1 write locks 0 pid/thread 22992/139760456615680 flags 10 priority 100 4 READ 1 HELD entryCSN.bdb handle 0 5 dd= 0 locks held 0 write locks 0 pid/thread 22992/139759426926336 flags 0 priority 100 6 dd= 0 locks held 1 write locks 0 pid/thread 22992/139759426926336 flags 10 priority 100 6 READ 1 HELD objectClass.bdb handle 0 7 dd= 0 locks held 1 write locks 0 pid/thread 22992/139759426926336 flags 10 priority 100 7 READ 1 HELD reqStart.bdb handle 0 8 dd= 0 locks held 1 write locks 0 pid/thread 22992/139759384962816 flags 10 priority 100 8 READ 1 HELD reqEnd.bdb handle 0 9 dd= 0 locks held 1 write locks 0 pid/thread 22992/139759384962816 flags 10 priority 100 9 READ 1 HELD reqResult.bdb handle 0 80000003 dd= 0 locks held 0 write locks 0 pid/thread 22992/139835964708672 flags 0 priority 100 80000004 dd= 0 locks held 0 write locks 0 pid/thread 22992/139835964708672 flags 0 priority 100 80000006 dd= 0 locks held 0 write locks 0 pid/thread 22992/139759384962816 flags 0 priority 100 80000007 dd= 0 locks held 0 write locks 0 pid/thread 22992/139759426926336 flags 0 priority 100 8007dd08 dd= 0 locks held 2 write locks 0 pid/thread 22992/139759359784704 flags 0 priority 100 8007dd08 READ 1 HELD 0x652a90 len: 9 data: 010000000000000000 8007dd08 READ 1 HELD dn2id.bdb page 3 8007dd09 dd= 0 locks held 2 write locks 0 pid/thread 22992/139759426926336 flags 0 priority 100 8007dd09 READ 1 HELD 0x652a90 len: 9 data: 010000000000000000 8007dd09 READ 1 HELD 0x6716e8 len: 9 data: cfea8d000000000000 8007dd0a dd= 0 locks held 2 write locks 0 pid/thread 22992/139759426926336 flags 0 priority 100 8007dd0a WRITE 1 WAIT dn2id.bdb page 3 8007dd0a READ 1 HELD dn2id.bdb page 3 8007dd0a READ 1 HELD dn2id.bdb page 444591 8007dd0b dd= 0 locks held 0 write locks 0 pid/thread 22992/139759359784704 flags 0 priority 100 8007dd0b WRITE 1 WAIT dn2id.bdb page 3 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 8007dd08 READ 1 HELD dn2id.bdb page 3 8007dd0a READ 1 HELD dn2id.bdb page 3 8007dd0b WRITE 1 WAIT dn2id.bdb page 3 8007dd0a WRITE 1 WAIT dn2id.bdb page 3 2 READ 1 HELD dn2id.bdb handle 0 1 READ 1 HELD id2entry.bdb handle 0 4 READ 1 HELD entryCSN.bdb handle 0 8007dd09 READ 1 HELD 0x652a90 len: 9 data: 010000000000000000 8007dd08 READ 1 HELD 0x652a90 len: 9 data: 010000000000000000 9 READ 1 HELD reqResult.bdb handle 0 8 READ 1 HELD reqEnd.bdb handle 0 8007dd0a READ 1 HELD dn2id.bdb page 444591 7 READ 1 HELD reqStart.bdb handle 0 8007dd09 READ 1 HELD 0x6716e8 len: 9 data: cfea8d000000000000 6 READ 1 HELD objectClass.bdb handle 0 ==== #pid/thread 22992/139759426926336:Thread 7f1c46fef700 - accesslog_purge() #pid/thread 22992/139759359784704:Thread 7f1c42fe7700 - accesslog_responce() I am going to consider the tentative fix for openldap because I anticipate it would take so long time to pursue the fix for bdb(hdb), The tentative fix is like the following. Would you let me know whethere or not there are any concern about the fix? ==[accesslog_purge() in accesslog.c]== for (i=0; i<pd.used; i++) { op->o_req_dn = pd.dn[i]; op->o_req_ndn = pd.ndn[i]; if ( !slapd_shutdown ) { ldap_pvt_thread_mutex_lock( &li->li_log_mutex ); rs_reinit( &rs, REP_RESULT ); op->o_bd->be_delete( op, &rs ); ldap_pvt_thread_mutex_unlock( &li->li_log_mutex ); } ch_free( pd.ndn[i].bv_val ); ch_free( pd.dn[i].bv_val ); ldap_pvt_thread_pool_pausecheck( &connection_pool ); } ==== I know openldap itself currently recommend NOT using hdb/bdb as backend database. However, I should seek any workaround in the hdb backend case. Best Regards,

1 0

Re: (ITS#8749) Proxy: LDAP-querry doesn't work for e.g (userAccountControl:1.2.840.113556.1.4.803:=2)
by michael＠stroeder.com 01 Oct '17

01 Oct '17

This is a cryptographically signed message in MIME format. --------------ms020703060800000901000202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable steffen.krahl(a)nexio.de wrote: > I'm using OpenLDAP with LDAP-backend as proxy for ActiveDirectory=20 > It's working well so far, only LDAP-queries which should exclude > deactivated users don't work. It seems slapd does not accept queries > like (attribute:OID:=3Dvalue) OpenLDAP does support extended filters with a matching rule. But only with matching rules implemented in OpenLDAP. > in particular > (!(userAccountControl:1.2.840.113556.1.4.803:=3D2))) The matching rule defined by 1.2.840.113556.1.4.803 is a proprietary matching rule defined by Microsoft for bit-wise matching. AFAICS they never wrote a public formal spec for it. So this particular matching rule is not implemented in OpenLDAP. > performing upper query gets: Oct 1 00:45:33 nxld01 slapd[3002]: > str2filter "(&(sAMAccountType=3D 805306368)(?=3Derror))" Oct 1 00:45:3= 3 > nxld01 kernel: [49436.933735] slapd[3005]: segfault at 18 ip=20 > 00007ff4f783d512 sp 00007ff4f1afc810 error 4 in=20 > libc-2.23.so[7ff4f77b9000+1c0000] Does that mean slapd seg faults? It shouldn't. > performing the following query > (&(objectClass=3D*)(userAccountControl:1.2.840.113556.1.4.803:=3D2)) > will get following log wntry: > Oct 1 00:49:07 nxld01 slapd[3033]: str2filter > "(&(objectClass=3D*)(!(objectClass=3D*)))" IMO it makes perfect sense to treat extended filter part with a non-supported matching rule as a filter which always evaluates to False. Ciao, Michael. --------------ms020703060800000901000202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMDAxMDgyNDQ2WjAvBgkq hkiG9w0BCQQxIgQgjVnm8ahsW8UjSaHg8/QsoGPfsTkcNQMlzcj5iApV0cQwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEAGnpf1uxiIUjLgQv+x7RBn79145ns9HfcJUDIVtW3QOwB1uXmjJBwIuaEWqtFAy9r2OOC zLsp8GYgc4OAl/2BFOCq+CR09TkGxDHK+n6UBG5vQ0oeSUSbMQD2wgTSNChQ2gdCOhrRAjWP AQiN7YyYOM2sJBdJEVkruG0NlzPa/9lSHHH8ljMkmIhDjFukAME5L0TTbLQN3PDo8C+IITHH OuYzwBsQ/ZBnXBZ1D9RrkdkfnT4aSYUv0bJ93t++tv4bI6yQvax7WbIJ5BuOlLUpNaLEd+4R rCKf/fO5QUkMxFICJG7Jd+qq8LpQuRcb02985OnKKgvPFM3L3e9oNn/fqgAAAAAAAA== --------------ms020703060800000901000202--

1 0

(ITS#8749) Proxy: LDAP-querry doesn't work for e.g (userAccountControl:1.2.840.113556.1.4.803:=2)
by steffen.krahl＠nexio.de 30 Sep '17

30 Sep '17

Full_Name: Steffen Krahl Version: 2.4-2 OS: Ubuntu 16.04.3 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.168.136.108) I'm using OpenLDAP with LDAP-backend as proxy for ActiveDirectory It's working well so far, only LDAP-queries which should exclude deactivated users don't work. It seems slapd does not accept queries like (attribute:OID:=value) in particular (&(sAMAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) fails due to the part ":1.2.840.113556.1.4.803:". The query itself works fine for ActiveDirectory itself. to make blind test: (userAccountControl:1.2.840.113556.1.4.803:=2) will not get any object back (but should) I'm quite new to OpenLDAP, but it seems an issue. performing upper query gets: Oct 1 00:45:33 nxld01 slapd[3002]: str2filter "(&(sAMAccountType= 805306368)(?=error))" Oct 1 00:45:33 nxld01 kernel: [49436.933735] slapd[3005]: segfault at 18 ip 00007ff4f783d512 sp 00007ff4f1afc810 error 4 in libc-2.23.so[7ff4f77b9000+1c0000] performing the following query (&(objectClass=*)(userAccountControl:1.2.840.113556.1.4.803:=2)) will get following log wntry: Oct 1 00:49:07 nxld01 slapd[3033]: str2filter "(&(objectClass=*)(!(objectClass=*)))" seems a little bit strange BR Steffen

1 0

Re: (ITS#8745) Need to join Windows server 2012 R2 to open lapd as a client
by ryan＠openldap.org 30 Sep '17

30 Sep '17

On Thu, Sep 28, 2017 at 07:11:35AM +0000, ramkumar(a)mgtechsoft.com wrote: >Request you to inform whether can we join windows 2012 server to Open Ldap as >client? > >and if it is possible please share the procedure with us. The ITS system is for reporting software bugs, not for support questions. If you have a question about OpenLDAP, please contact the openldap-technical(a)openldap.org mailing list. In your specific case, it sounds like your question is actually about Samba, not about OpenLDAP. As well, "opeldap.sdef.com" sounds like it might be a typo, so please check your spelling carefully. This ITS will be closed.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs