- openldap-bugs - openldap.org

Re: (ITS#8461) Unable to import LDIF from back-hdb DB to back-mdb db
by quanah＠symas.com 08 Nov '17

08 Nov '17

--On Friday, July 08, 2016 5:33 PM +0000 quanah(a)openldap.org wrote: > In moving off of back-hdb, encountered a scenario where importing the = LDIF > exported via slapcat failed when loading into back-mdb via slapadd. > There is nothing technically wrong with the entry. Will provide the > problematic entry elsewhere, as it contains PII. To note, the problematic entry has an RDN value > 512 characters.=20 Anonymizing the problem DN, we have: dn=3D"zimbraSignatureName=3Dxxxxx xxxxxxxxxxxxx xxxxxx xx xxxx x xxxx! = ..xxxxxx=20 xx xxxxxxxx xxx'x xxxx xxxxx xxxxx xxxxxx=E2=80=A6 & xxxx xx x xxxxx xx xx = xxxx=20 xxxx xxxxx!?! =E2=80=A6x xxxx xxxxx xx xxxxxxxxxx xxxxxxxxx xxxxxxxxx = xxxxxxx:=20 xxxxxx & xxxxxxxx & xxxxxx xxxxx x xxxxxx xx xxx xxxxxx=20 xxxxxxx.,uid=3Dxxxxxxxxxxxx,ou=3Dpeople,dc=3Dxxxx,dc=3Dxx" = (line=3D89392876):=20 txn_aborted! MDB_BAD_VALSIZE: Too big key/data, key is empty, or wrong=20 DUPFIXED size (-30781) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8753) Public key pinning support in libldap
by ondra＠mistotebe.net 07 Nov '17

07 Nov '17

On Tue, Oct 10, 2017 at 10:43:42AM +0000, ondra(a)openldap.org wrote: > URL: https://github.com/mistotebe/openldap/tree/its8753 > > A new libldap option LDAP_OPT_X_TLS_PEERKEY_HASH that accepts a string > 'hashname/base64_hash_of_public_key'. If a TLS session is already present on the > main connection, it is also checked immediately. > > It introduces a dependency on liblutil by depending on the symbol > lutil_b64_pton. Somehow, this breaks the build for the ldap* tools, not sure why > or how to fix that yet. A new version is now at the same place (see above), it moves the ldif.c in-place base64 decoding into a separate function and reuses that. Other changes: - pin hash algorithm separator changes to ':' - pin can now be set from the environment - can now better deal with connection freeing and/or changes to the global ldap options -- 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: (ITS#8770) dsaschema seg faults
by michael＠stroeder.com 06 Nov '17

06 Nov '17

Canned config available: https://stroeder.com/temp/openldap-testbed-its8770.tar.gz Seg faults with 2.4.45 and current RE24 branch: $ cd openldap-testbed-its8770 $ ./start-slapd.sh [..] 5a009864 slapd.conf: line 19 (moduleload back_mdb) 5a009864 loaded module back_mdb 5a009864 mdb_back_initialize: initialize MDB backend 5a009864 mdb_back_initialize: LMDB 0.9.21: (June 1, 2017) 5a009864 module back_mdb: null module registered 5a009864 slapd.conf: line 22 (moduleload dsaschema.so schema/oath-ldap-dsa.schema) 5a009864 loaded module dsaschema.so ./start-slapd.sh: line 11: 29304 Segmentation fault (core dumped) ${OPENLDAP_PREFIX}/lib64/slapd -d config,stats,stats2,acl,args,trace,sync -h "ldap://0.0.0.0:2071 ldapi://slapd1-socket" -n slapd-its8770 -f slapd.conf

1 0

(ITS#8770) dsaschema seg faults
by michael＠stroeder.com 06 Nov '17

06 Nov '17

Full_Name: Version: RE24 OS: URL: Submission from: (NULL) (213.240.182.108) This leads to a seg fault: moduleload dsaschema.so /home/michael/Proj/oath-ldap/oath-ldap-dsa.schema More information to come...

1 0

(ITS#8769) Docs: Fix oid search extension syntax
by lukas.juhrich＠agdsn.de 03 Nov '17

03 Nov '17

Full_Name: Lukas Juhrich Version: 2.4.45 OS: Arch Linux, Debian Stretch URL: http://agdsn.me/~lukasjuhrich/openldap/ Submission from: (NULL) (141.76.119.134) This is a small syntax fix to adapt the documentation to how the code actually parses `-E <oid>` options. Quicklink to the code responsible for parsing: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=clients/to… I was not sure whether patches should also follow the naming convention, so I provided the same patch using two different names, the original one and the one adhering to the naming convention.

1 0

Re: (ITS#8768) Syncprov shouldn't send a new cookie at the end of delete phase
by ondra＠mistotebe.net 02 Nov '17

02 Nov '17

On Thu, Nov 02, 2017 at 03:55:02PM +0000, ondra(a)mistotebe.net wrote: > On Tue, Oct 31, 2017 at 05:34:05PM +0000, ondra(a)openldap.org wrote: > > If sessionlog data is available and found useful, syncprov will send a cookie at > > the end of delete phase, itself followed by the entries modified since time > > recorded in the client's original cookie. > > > > Some of those entries might have been last modified before the new cookie's > > recorded time and if the connection is severed before this is communicated, they > > would not be re-sent under the new cookie. > > There are other problems with this. I have always assumed that CSN of > each write is globally unique in a well-configured system and that this > is preserved across replication, since MMR needs that to function > properly. This assumption is clearly invalid if UUIDs are sent in a > delete SyncInfo message (consumer that needs to determine CSNs that > apply can only pick a single CSN for all of the deletes). > > So this is a problem in MMR situations where the cookie carries semantic > information between MMR nodes. > > An MMR member receiving such a message has to pick a CSN to apply here: > - either the cookie (if present at all) - leads to problems described > above > - or some other CSN - the deletes could be lost or propagate to other > masters as a fresh mod, either smells of replication problems down the > line Even assuming we never send a batch delete, sessionlog is a problem in the MMR case: - to end up in the sessionlog, we need a CSN for the delete to be transmitted - if we send all deletes first, then modified entries, we can't use the cookie to send the information that's needed to create a sessionlog entry - we can't reasonably send all entries in CSN order with the deletes interspersed at the relevant place in the stream, that would require holding onto the (UUID, CSN) list for a very long time, not to mention that we'd need the backend to guarantee search entry ordering in the first place Maybe if we track more information in the cookie MMR nodes might have what they needed to populate sessionlog and standards compliant syncrepl clients would keep working as well? Maybe storing progress of the delete phase (optional) and general replication progress (CSN as usual) in the cookie might do it. Question is whether that is enough, doesn't introduce new problems and doesn't make the code even more complex and harder to maintain? That, even if workable wouldn't get it into 2.4, so an upgrade would have to be a lock-step affair for at least the masters/nodes with syncprov running. > This shouldn't affect deltaMMR environments, though, AFAIK they never use > sessionlog in any way, so batched deletes don't get sent over the wire > at all. Quanah mentions that deltaMMR can hit this issue if we have to fall-back to plain syncrepl in the case of a conflict (and we don't want a full present phase to happen at that point). -- 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: (ITS#8768) Syncprov shouldn't send a new cookie at the end of delete phase
by ondra＠mistotebe.net 02 Nov '17

02 Nov '17

On Tue, Oct 31, 2017 at 05:34:05PM +0000, ondra(a)openldap.org wrote: > If sessionlog data is available and found useful, syncprov will send a cookie at > the end of delete phase, itself followed by the entries modified since time > recorded in the client's original cookie. > > Some of those entries might have been last modified before the new cookie's > recorded time and if the connection is severed before this is communicated, they > would not be re-sent under the new cookie. There are other problems with this. I have always assumed that CSN of each write is globally unique in a well-configured system and that this is preserved across replication, since MMR needs that to function properly. This assumption is clearly invalid if UUIDs are sent in a delete SyncInfo message (consumer that needs to determine CSNs that apply can only pick a single CSN for all of the deletes). So this is a problem in MMR situations where the cookie carries semantic information between MMR nodes. An MMR member receiving such a message has to pick a CSN to apply here: - either the cookie (if present at all) - leads to problems described above - or some other CSN - the deletes could be lost or propagate to other masters as a fresh mod, either smells of replication problems down the line This shouldn't affect deltaMMR environments, though, AFAIK they never use sessionlog in any way, so batched deletes don't get sent over the wire at all. -- 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: (ITS#8767) Binddn issue with a comma in the DN
by clement.oudot＠savoirfairelinux.com 01 Nov '17

01 Nov '17

Le 31/10/2017 =C3=A0 17:39, michael(a)stroeder.com a =C3=A9crit : > > The ITS is only for reporting bugs. > This is not a bug. It's a usage question. > > You should post such questions to openldap-technical mailing list after > subscribing to it: > > https://www.openldap.org/lists/mm/listinfo/openldap-technical > > A short hint about escaping, e.g. a comma in DN string representation: > > https://tools.ietf.org/html/rfc4514#section-2.4 > > Note that depending on your client config system more escaping might be > needed because of the config syntax. Hello Michael, it seems to be a bug, as if I escape the comma in slapd.conf, I still=20 have the error. =3D=3D slapd.conf =3D=3D idassert-bind bindmethod=3D"simple" binddn=3D"cn=3DLastname\,=20 Firstname,ou=3Dusers,dc=3Dexample,dc=3Dcom" credentials=3D"secret" mode=3D= "legacy"=20 flags=3D"non-prescriptive" =3D=3D slaptest -f slapd.conf =3D=3D 59faba5e invalid bind config value binddn=3Dcn=3DLastname,=20 Firstname,ou=3Dusers,dc=3Dexample,dc=3Dcom 59faba5e slapd.conf: line 31: "idassert-bind <args>": unable to parse=20 field "binddn=3Dcn=3DLastname, Firstname,ou=3Dusers,dc=3Dexample,dc=3Dcom= ". slaptest: bad configuration file! Seems the escaping is not taken into account. Cl=C3=A9ment.

1 0

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

01 Nov '17

On Fri, Oct 06, 2017 at 06:45:41PM -0700, Paul B. Henson wrote: > 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. Sadness :(, not one but two of my boxes crashed today, both running the patch, with what appears to be the same issue: Core was generated by `/usr/lib64/openldap/slapd -u ldap -g ldap -h ldaps:// ldap://'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000000483eb9 in modify_add_values (e=e@entry=0x7f75994f9440, mod=mod@entry=0x7f758c0016c8, permissive=0, text=text@entry=0x7f75994f99a0, textbuf=textbuf@entry=0x7f75994f94c0 "modify/delete: eduPersonAffiliation: no such attribute", textlen=textlen@entry=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/mods.c:61 61 if ( !BER_BVISNULL( &mod->sm_values[mod->sm_numvals] )) { [Current thread is 1 (Thread 0x7f75994fb700 (LWP 44707))] (gdb) bt full #0 0x0000000000483eb9 in modify_add_values (e=e@entry=0x7f75994f9440, mod=mod@entry=0x7f758c0016c8, permissive=0, text=text@entry=0x7f75994f99a0, textbuf=textbuf@entry=0x7f75994f94c0 "modify/delete: eduPersonAffiliation: no such attribute", textlen=textlen@entry=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/mods.c:61 rc = <optimized out> op = 0x4c1265 "add" a = <optimized out> pmod = {sm_desc = <optimized out>, sm_values = 0x0, sm_nvalues = 0x0, sm_numvals = <optimized out>, sm_op = <optimized out>, sm_flags = <optimized out>, sm_type = {bv_len = <optimized out>, bv_val = <optimized out>}} __PRETTY_FUNCTION__ = "modify_add_values" #1 0x00007f779dbd9bc3 in mdb_modify_internal (op=op@entry=0x7f75994fa600, tid=tid@entry=0x16bbae0, modlist=0x7f758c001688, e=e@entry=0x7f75994f9440, text=text@entry=0x7f75994f99a0, textbuf=textbuf@entry=0x7f75994f94c0 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/back-mdb/modify.c:137 rc = <optimized out> err = <optimized out> mod = 0x7f758c0016c8 ml = 0x7f758c0016c8 save_attrs = 0x7f758c002708 ap = 0x7f77a2997010 glue_attr_delete = <optimized out> got_delete = 0 __PRETTY_FUNCTION__ = "mdb_modify_internal" #2 0x00007f779dbdaf55 in mdb_modify (op=0x7f75994fa600, rs=0x7f75994f9980) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/back-mdb/modify.c:624 mdb = 0x7f77a2997010 e = 0x7f758c0026b8 manageDSAit = <optimized out> ---Type <return> to continue, or q <return> to quit--- textbuf = "modify/delete: eduPersonAffiliation: no such attribute\000\000\276B2\214u\177\000\000\000\000\001\000\000\000\000\000\301B2\214u\177\000\000\276B2\214u\177\000\000\267B2\214u\177\000\000\220\031\000\214u\177\000\000\000\320\070\355\212˄\256\000\200", '\000' <repeats 15 times>, "\246O\231u\177\000\000pV0\001\000\000\000\000\220\031\000\214u\177\000\000PX0\001\000\000\000\000\000\200\000\000\000\000\000\000\236\313J\000\000\000\000\000\370[0\001\000\000\000\000\270\031\000\214u\177\000\000\000\246O\231u\177\000\000\260"... txn = 0x16bbae0 opinfo = {moi_oe = {oe_next = {sle_next = 0x7f75994f9930}, oe_key = 0x7f77a2997010}, moi_txn = 0x16bbae0, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f75994f9420 dummy = {e_id = 84455, e_name = {bv_len = 34, bv_val = 0x7f758c002688 "uid=jredmond,ou=user,dc=cpp,dc=edu"}, e_nname = {bv_len = 34, bv_val = 0x7f758c0031f0 "uid=jredmond,ou=user,dc=cpp,dc=edu"}, e_attrs = 0x7f75c42d5ed8, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x7f758c0026b8} preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x2, 0xffffffffffffffff, 0x0, 0x0, 0x7f75994f9400} num_ctrls = 0 numads = 61 #3 0x000000000049a6c2 in overlay_op_walk (op=op@entry=0x7f75994fa600, rs=0x7f75994f9980, which=op_modify, oi=0x1305490, on=<optimized out>) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/backover.c:677 func = <optimized out> rc = <optimized out> #4 0x000000000049a81a in over_op_func (op=0x7f75994fa600, rs=<optimized out>, which=<optimized out>) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/backover.c:730 oi = <optimized out> on = <optimized out> be = 0x12f6f70 db = {bd_info = 0x7f779ddf3c60 <bi>, bd_self = 0x12f6f70, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, ---Type <return> to continue, or q <return> to quit--- sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 64}, be_suffix = 0x12f6000, be_nsuffix = 0x12f6680, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 25, bv_val = 0x12f68a0 "cn=ldaproot,dc=cpp,dc=edu"}, be_rootndn = {bv_len = 25, bv_val = 0x12f68f0 "cn=ldaproot,dc=cpp,dc=edu"}, be_rootpw = { bv_len = 14, bv_val = 0x12c72b0 ""}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x12f5f30, be_acl = 0x12f82c0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x15b8d90, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x13060d0, be_pb = 0x0, be_cf_ocs = 0x7f779ddf3820 <mdbocs>, be_private = 0x7f77a2997010, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7f75994f9950, sc_response = 0x499a10 <over_back_response>, sc_cleanup = 0x0, sc_private = 0x1305490, sc_writewait = 0x0} sc = <optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #5 0x000000000048bbdf in syncrepl_message_to_op (si=si@entry=0x1306800, op=op@entry=0x7f75994fa600, msg=0x7f758c112430) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/syncrepl.c:2423 oes = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x48b010 <syncrepl_message_to_op>}, oe_si = 0x1306800} ber = 0x7f758c1162e0 modlist = 0x7f758c129dc0 ls = 0x72e2a0 <accesslog_sc> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x7f75994f94c0 "modify/delete: eduPersonAffiliation: no such attribute", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} ---Type <return> to continue, or q <return> to quit--- cb = {sc_next = 0x7f758c001960, sc_response = 0x48ab80 <null_callback>, sc_cleanup = 0x0, sc_private = 0x0, sc_writewait = 0x0} text = 0x29 <error: Cannot access memory at address 0x29> txtbuf = "@\237O\231u\177\000\000\261\215J\242w\177\000\000@\237O\231u\177\000\000\020\234O\231u\177\000\000\020'M\000\000\000\000\000\026\220J\242w\177\000\000@\237O\231u\177\000\000\020'M\000\000\000\000\000\220\232O\231u\177\000\000`\374J\242w\177\000\000\020'M\000\000\000\000\000@\235J\242w\177\000\000\020\000\000\000\000\000\000\000\377\377\377\377\377\377\377\377\200\232O\017\000\000\000\000\f\\1\214u\177\000\000 \234O\231u\177\000\000\b\\1\214u\177\000\000\001\000\000\000\000\000\000\000\017\\1\214u\177\000\000\340\234O\231u\177\000\000@\231(\001\000\000\000\000\000h0\001\000\000\000\000\213\307I\000\000\000\000\000\020", '\000' <repeats 23 times>... bdn = {bv_len = 34, bv_val = 0x7f758c10fc4c "uid=jredmond,ou=user,dc=cpp,dc=edu"} dn = {bv_len = 34, bv_val = 0x7f758c001968 ""} ndn = {bv_len = 34, bv_val = 0x7f758c0019e8 "\""} bv = {bv_len = 0, bv_val = 0x0} bv2 = {bv_len = 0, bv_val = 0x0} bvals = 0x7f758c1144a0 rdn = {bv_len = 0, bv_val = 0x0} sup = {bv_len = 0, bv_val = 0x0} prdn = {bv_len = 0, bv_val = 0x0} nrdn = {bv_len = 0, bv_val = 0x0} psup = {bv_len = 0, bv_val = 0x0} nsup = {bv_len = 0, bv_val = 0x0} rc = 0 deleteOldRdn = 0 freeReqDn = 1 do_graduate = 1 #6 0x000000000048f8bf in do_syncrep2 (op=op@entry=0x7f75994fa600, si=si@entry=0x1306800) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/syncrepl.c:1014 match = <optimized out> syncUUID = {{bv_len = 16, bv_val = 0x7f758c11b257 "\006_\367\067\304\032H\273\273F \355\022\271\b\f"}, { bv_len = 140143060033504, ---Type <return> to continue, or q <return> to quit--- bv_val = 0x7f7500000001 <error: Cannot access memory at address 0x7f7500000001>}} cookie = {bv_len = 15, bv_val = 0x7f758c11b269 "rid=002,sid=001"} rctrls = 0x7f758c10fb80 rctrlp = <optimized out> bdn = {bv_len = 44, bv_val = 0x7f758c10fbfa "reqStart=20171101104541.000063Z,cn=accesslog"} si_tag = <optimized out> entry = <optimized out> punlock = -1 syncstate = 1 retdata = 0x0 retoid = 0x0 syncUUIDs = 0x7f758c11f0f0 len = 15 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "P\262\021\214u\177\000\000x\262\021\214u\177\000\000x\262\021\214u\177", '\000' <repeats 26 times>, "\244q\021\234u\177\000\000m\252\365\240w\177\000\000\340\237O\231u\177\000\000b\232\356\240w\177\000\000\001\000\000\000\000\000\000\000ԏ\357\240w\177\000\000\364:\n\277\325\362^\203\250\336\vʶy\"\277=w3\340\204(\302\375P\262\021\214u\177\000\000\060\000\000\000\000\000\000\000\200\373\020\214u\177\000\000\060\000\000\000\000\000\000\000ТO\231u\177\000\000\000\242O\231u\177\000\000СO\231"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <error: Cannot access memory at address 0x10002>} ber = 0x7f75994f9f40 msg = 0x7f758c112430 syncCookie = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 2, octet_str = {bv_len = 15, bv_val = 0x7f758c315c00 "rid=002,sid=001"}, sid = 1, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 2, octet_str = {bv_len = 15, bv_val = 0x7f758c105fc0 "rid=002,sid=001"}, sid = 1, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 11 tout_p = 0x7f75994f9c00 tout = {tv_sec = 0, tv_usec = 0} ---Type <return> to continue, or q <return> to quit--- refreshDeletes = 0 empty = "empty" #7 0x0000000000493ad3 in do_syncrepl (ctx=ctx@entry=0x7f75994fab90, arg=arg@entry=0x1306c20) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/syncrepl.c:1565 rtask = 0x1306c20 si = 0x1306800 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4c7052 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4c7052 ""}, c_listener = 0x4c9ee0 <dummy_list>, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = { bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = { bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_udp = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ---Type <return> to continue, or q <return> to quit--- ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0x0, c_clientarg = 0x0, c_send_ldap_result = 0x440a60 <slap_send_ldap_result>, c_send_search_entry = 0x4414c0 <slap_send_search_entry>, c_send_search_reference = 0x442a00 <slap_send_search_reference>, c_send_ldap_extended = 0x441190 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x441330 <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f75994fa770, o_tag = 102, o_time = 1509533141, o_tincr = 61, o_bd = 0x7f75994f9690, o_req_dn = {bv_len = 34, bv_val = 0x7f758c11f0f0 "uid=jredmond,ou=user,dc=cpp,dc=edu"}, o_req_ndn = {bv_len = 34, bv_val = 0x7f758c11d4c0 "uid=jredmond,ou=user,dc=cpp,dc=edu"}, o_request = {oq_add = { rs_modlist = 0x7f758c001688, rs_e = 0x1}, oq_bind = {rb_method = -1946151288, rb_cred = { bv_len = 1, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = { bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x7f758c001688}, oq_modify = { rs_mods = {rs_modlist = 0x7f758c001688, rs_no_opattrs = 1 '\001'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x7f758c001688, rs_no_opattrs = 1 '\001'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = -1946151288, rs_deref = 32629, rs_slimit = 1, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = -1946151288}, oq_cancel = {rs_msgid = -1946151288}, oq_extended = {rs_reqoid = { bv_len = 140142836717192, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 140142836717192, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\002", '\000' <repeats 16 times>, o_controls = 0x7f75994fa8c0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 25, bv_val = 0x12f68a0 "cn=ldaproot,dc=cpp,dc=edu"}, sai_ndn = { ---Type <return> to continue, or q <return> to quit--- bv_len = 25, bv_val = 0x12f68f0 "cn=ldaproot,dc=cpp,dc=edu"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7f758c001990, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7f758c3242a0 "20171101104541.389271Z#000000#004#000000"}, o_private = 0x0, o_extra = {slh_first = 0x7f75994f9420}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 2, oh_conn = 0x7f75994fa340, oh_msgid = 0, oh_protocol = 0, oh_tid = 140143060039424, oh_threadctx = 0x7f75994fab90, oh_tmpmemctx = 0x7f758c001150, oh_tmpmfuncs = 0x72e140 <slap_sl_mfuncs>, oh_counters = 0x731640 <slap_counters>, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>, oh_extensions = 0x0}, ob_controls = { 0x0 <repeats 17 times>, 0x7f75994f9ce0, 0x0 <repeats 14 times>}} op = 0x7f75994fa600 rc = 0 dostop = 0 s = 60 i = <optimized out> defer = 1 fail = 0 freeinfo = 0 be = 0x12f6f70 #8 0x0000000000430bdf in connection_read_thread (ctx=0x7f75994fab90, argv=0x3c) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/connection.c:1296 rc = <optimized out> cri = {op = 0x0, func = 0x4937f0 <do_syncrepl>, arg = 0x1306c20, ctx = 0x7f75994fab90, nullop = <optimized out>} s = 60 #9 0x00007f77a26c67f2 in ldap_int_thread_pool_wrapper (xpool=0x1293710) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/libraries/libldap_r/tpool.c:696 pool = 0x1293710 task = 0x7f75d8000b80 work_list = <optimized out> ctx = {ltu_id = 140143060039424, ltu_key = {{ltk_key = 0x42e370 <conn_counter_init>, ---Type <return> to continue, or q <return> to quit--- ltk_data = 0x7f758c001040, ltk_free = 0x42e450 <conn_counter_destroy>}, { ltk_key = 0x484d20 <slap_sl_mem_init>, ltk_data = 0x7f758c001150, ltk_free = 0x484bf0 <slap_sl_mem_destroy>}, {ltk_key = 0x15b8e00, ltk_data = 0x7f758c1011a0, ltk_free = 0x7f779dbe7730 <mdb_reader_free>}, {ltk_key = 0x7f779dbdd5f0 <search_stack>, ltk_data = 0x7f7586fff010, ltk_free = 0x7f779dbdd700 <search_stack_free>}, { ltk_key = 0x7f779dbdd550 <scope_chunk_get>, ltk_data = 0x7f75989fa010, ltk_free = 0x7f779dbdd6d0 <scope_chunk_free>}, {ltk_key = 0x443960 <slap_op_free>, ltk_data = 0x7f75cc315ce0, ltk_free = 0x443930 <slap_op_q_destroy>}, {ltk_key = 0x13b2430, ltk_data = 0x7f758c119050, ltk_free = 0x7f779dbe7730 <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x7f75c8130aa0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 24 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #10 0x00007f77a1a443e4 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #11 0x00007f77a17863ed in clone () from /lib64/libc.so.6 No symbol table info available. Core was generated by `/usr/lib64/openldap/slapd -u ldap -g ldap -h ldaps:// ldap://'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000000483eb9 in modify_add_values (e=e@entry=0x7f306e4f6440, mod=mod@entry=0x7f3060000ad0, permissive=0, text=text@entry=0x7f306e4f69a0, textbuf=textbuf@entry=0x7f306e4f64c0 "modify/delete: eduPersonAffiliation: no such attribute", textlen=textlen@entry=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/mods.c:61 61 if ( !BER_BVISNULL( &mod->sm_values[mod->sm_numvals] )) { [Current thread is 1 (Thread 0x7f306e4f8700 (LWP 85701))] (gdb) bt full #0 0x0000000000483eb9 in modify_add_values (e=e@entry=0x7f306e4f6440, mod=mod@entry=0x7f3060000ad0, permissive=0, text=text@entry=0x7f306e4f69a0, textbuf=textbuf@entry=0x7f306e4f64c0 "modify/delete: eduPersonAffiliation: no such attribute", textlen=textlen@entry=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/mods.c:61 rc = <optimized out> op = 0x4c1265 "add" a = <optimized out> pmod = {sm_desc = <optimized out>, sm_values = 0x0, sm_nvalues = 0x0, sm_numvals = <optimized out>, sm_op = <optimized out>, sm_flags = <optimized out>, sm_type = {bv_len = <optimized out>, bv_val = <optimized out>}} __PRETTY_FUNCTION__ = "modify_add_values" #1 0x00007f3251ec4bc3 in mdb_modify_internal (op=op@entry=0x7f306e4f7600, tid=tid@entry=0xffc950, modlist=0x7f3060000a90, e=e@entry=0x7f306e4f6440, text=text@entry=0x7f306e4f69a0, textbuf=textbuf@entry=0x7f306e4f64c0 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/back-mdb/modify.c:137 rc = <optimized out> err = <optimized out> mod = 0x7f3060000ad0 ml = 0x7f3060000ad0 save_attrs = 0x7f3060001b50 ap = 0x7f3256c82010 glue_attr_delete = <optimized out> got_delete = 0 __PRETTY_FUNCTION__ = "mdb_modify_internal" #2 0x00007f3251ec5f55 in mdb_modify (op=0x7f306e4f7600, rs=0x7f306e4f6980) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/back-mdb/modify.c:624 mdb = 0x7f3256c82010 e = 0x7f3060001b00 manageDSAit = <optimized out> ---Type <return> to continue, or q <return> to quit--- textbuf = "modify/delete: eduPersonAffiliation: no such attribute\000\000\276\247\020`0\177\000\000\000\000\001\000\000\000\000\000\301\247\020`0\177\000\000\276\247\020`0\177\000\000\267\247\020`0\177\000\000\230\r\000`0\177\000\000\000_\246mQo\262.\000\200", '\000' <repeats 15 times>, "vOn0\177\000\000Pf\304\000\000\000\000\000\230\r\000`0\177\000\000\060h\304\000\000\000\000\000\000\200\000\000\000\000\000\000\236\313J\000\000\000\000\000\330k\304\000\000\000\000\000\300\r\000`0\177\000\000\000vOn0\177\000\000"... txn = 0xffc950 opinfo = {moi_oe = {oe_next = {sle_next = 0x7f306e4f6930}, oe_key = 0x7f3256c82010}, moi_txn = 0xffc950, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f306e4f6420 dummy = {e_id = 94173, e_name = {bv_len = 31, bv_val = 0x7f3060001ad8 "uid=jplau,ou=user,dc=cpp,dc=edu"}, e_nname = {bv_len = 31, bv_val = 0x7f30600026a0 "uid=jplau,ou=user,dc=cpp,dc=edu"}, e_attrs = 0x7f3078126340, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x7f3060001b00} preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x2, 0xffffffffffffffff, 0x0, 0x0, 0x7f306e4f6400} num_ctrls = 0 numads = 61 #3 0x000000000049a6c2 in overlay_op_walk (op=op@entry=0x7f306e4f7600, rs=0x7f306e4f6980, which=op_modify, oi=0xc46470, on=<optimized out>) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/backover.c:677 func = <optimized out> rc = <optimized out> #4 0x000000000049a81a in over_op_func (op=0x7f306e4f7600, rs=<optimized out>, which=<optimized out>) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/backover.c:730 oi = <optimized out> on = <optimized out> be = 0xc37f50 db = {bd_info = 0x7f32520dec60 <bi>, bd_self = 0xc37f50, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, ---Type <return> to continue, or q <return> to quit--- sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 64}, be_suffix = 0xc36fe0, be_nsuffix = 0xc37660, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 25, bv_val = 0xc37880 "cn=ldaproot,dc=cpp,dc=edu"}, be_rootndn = {bv_len = 25, bv_val = 0xc378d0 "cn=ldaproot,dc=cpp,dc=edu"}, be_rootpw = { bv_len = 14, bv_val = 0xc08290 ""}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0xc36f10, be_acl = 0xc392a0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xdf8120, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0xc470b0, be_pb = 0x0, be_cf_ocs = 0x7f32520de820 <mdbocs>, be_private = 0x7f3256c82010, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7f306e4f6950, sc_response = 0x499a10 <over_back_response>, sc_cleanup = 0x0, sc_private = 0xc46470, sc_writewait = 0x0} sc = <optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #5 0x000000000048bbdf in syncrepl_message_to_op (si=si@entry=0xc477e0, op=op@entry=0x7f306e4f7600, msg=0x7f3060111950) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/syncrepl.c:2423 oes = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x48b010 <syncrepl_message_to_op>}, oe_si = 0xc477e0} ber = 0x7f3060115190 modlist = 0x7f3060108c00 ls = 0x72e2a0 <accesslog_sc> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x7f306e4f64c0 "modify/delete: eduPersonAffiliation: no such attribute", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} ---Type <return> to continue, or q <return> to quit--- cb = {sc_next = 0x7f3060000d68, sc_response = 0x48ab80 <null_callback>, sc_cleanup = 0x0, sc_private = 0x0, sc_writewait = 0x0} text = 0x29 <error: Cannot access memory at address 0x29> txtbuf = "@oOn0\177\000\000\261=yV2\177\000\000@oOn0\177\000\000\020lOn0\177\000\000\020'M\000\000\000\000\000\026@yV2\177\000\000@oOn0\177\000\000\020'M\000\000\000\000\000\220jOn0\177\000\000`\254yV2\177\000\000\020'M\000\000\000\000\000@MyV2\177\000\000\020\000\000\000\000\000\000\000\377\377\377\377\377\377\377\377\200jO\017\000\000\000\000\314\370\020`0\177\000\000 lOn0\177\000\000\310\370\020`0\177\000\000\001\000\000\000\000\000\000\000\317\370\020`0\177\000\000\340lOn0\177\000\000\060\251\274\000\000\000\000\000\340w\304\000\000\000\000\000\213\307I\000\000\000\000\000\020", '\000' <repeats 23 times>... bdn = {bv_len = 31, bv_val = 0x7f30601157bc "uid=jplau,ou=user,dc=cpp,dc=edu"} dn = {bv_len = 31, bv_val = 0x7f3060000d68 ""} ndn = {bv_len = 31, bv_val = 0x7f3060000de8 "h\032"} bv = {bv_len = 0, bv_val = 0x0} bv2 = {bv_len = 0, bv_val = 0x0} bvals = 0x7f3060103740 rdn = {bv_len = 0, bv_val = 0x0} sup = {bv_len = 0, bv_val = 0x0} prdn = {bv_len = 0, bv_val = 0x0} nrdn = {bv_len = 0, bv_val = 0x0} psup = {bv_len = 0, bv_val = 0x0} nsup = {bv_len = 0, bv_val = 0x0} rc = 0 deleteOldRdn = 0 freeReqDn = 1 do_graduate = 1 #6 0x000000000048f8bf in do_syncrep2 (op=op@entry=0x7f306e4f7600, si=si@entry=0xc477e0) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/syncrepl.c:1014 match = <optimized out> syncUUID = {{bv_len = 16, bv_val = 0x7f306010e577 ")\263\217MC\265F~\211\377\vB\020", <incomplete sequence \350\240>}, { bv_len = 139845985857504, bv_val = 0x7f3000000001 <error: Cannot access memory at address 0x7f3000000001>}} ---Type <return> to continue, or q <return> to quit--- cookie = {bv_len = 15, bv_val = 0x7f306010e589 "rid=002,sid=001"} rctrls = 0x7f306010ae50 rctrlp = <optimized out> bdn = {bv_len = 44, bv_val = 0x7f306011576a "reqStart=20171101104541.000020Z,cn=accesslog"} si_tag = <optimized out> entry = <optimized out> punlock = -1 syncstate = 1 retdata = 0x0 retoid = 0x0 syncUUIDs = 0x7f30601184b0 len = 15 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "p\345\020`0\177\000\000\230\345\020`0\177\000\000\230\345\020`0\177", '\000' <repeats 26 times>, "$\243\021t0\177\000\000mZ$U2\177\000\000\340oOn0\177\000\000bJ\035U2\177\000\000\001\000\000\000\000\000\000\000\324?\036U2\177\000\000\215\005\217\022\023\366\017\311\035,D\303~M0\\\311\326\350\341e\204Xa0q\020`0\177\000\000\060\000\000\000\000\000\000\000 \246\020`0\177\000\000\060\000\000\000\000\000\000\000\320rOn0\177\000\000\000rOn0\177\000\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <error: Cannot access memory at address 0x10002>} ber = 0x7f306e4f6f40 msg = 0x7f3060111950 syncCookie = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 2, octet_str = {bv_len = 15, bv_val = 0x7f306010f8c0 "rid=002,sid=001"}, sid = 1, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 2, octet_str = {bv_len = 15, bv_val = 0x7f30601044f0 "rid=002,sid=001"}, sid = 1, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 0 tout_p = 0x7f306e4f6c00 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 ---Type <return> to continue, or q <return> to quit--- empty = "empty" #7 0x0000000000493ad3 in do_syncrepl (ctx=ctx@entry=0x7f306e4f7b90, arg=arg@entry=0xc47c00) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/syncrepl.c:1565 rtask = 0xc47c00 si = 0xc477e0 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4c7052 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4c7052 ""}, c_listener = 0x4c9ee0 <dummy_list>, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = { bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = { bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_udp = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, ---Type <return> to continue, or q <return> to quit--- c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0x0, c_clientarg = 0x0, c_send_ldap_result = 0x440a60 <slap_send_ldap_result>, c_send_search_entry = 0x4414c0 <slap_send_search_entry>, c_send_search_reference = 0x442a00 <slap_send_search_reference>, c_send_ldap_extended = 0x441190 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x441330 <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f306e4f7770, o_tag = 102, o_time = 1509533141, o_tincr = 30, o_bd = 0x7f306e4f6690, o_req_dn = {bv_len = 31, bv_val = 0x7f3060109190 "uid=jplau,ou=user,dc=cpp,dc=edu"}, o_req_ndn = {bv_len = 31, bv_val = 0x7f306010d940 "uid=jplau,ou=user,dc=cpp,dc=edu"}, o_request = {oq_add = { rs_modlist = 0x7f3060000a90, rs_e = 0x1}, oq_bind = {rb_method = 1610615440, rb_cred = { bv_len = 1, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = { bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x7f3060000a90}, oq_modify = { rs_mods = {rs_modlist = 0x7f3060000a90, rs_no_opattrs = 1 '\001'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x7f3060000a90, rs_no_opattrs = 1 '\001'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 1610615440, rs_deref = 32560, rs_slimit = 1, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = 1610615440}, oq_cancel = {rs_msgid = 1610615440}, oq_extended = {rs_reqoid = { bv_len = 139845745773200, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 139845745773200, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\002", '\000' <repeats 16 times>, o_controls = 0x7f306e4f78c0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 25, bv_val = 0xc37880 "cn=ldaproot,dc=cpp,dc=edu"}, sai_ndn = {bv_len = 25, bv_val = 0xc378d0 "cn=ldaproot,dc=cpp,dc=edu"}, sai_ssf = 0, sai_transport_ssf = 0, ---Type <return> to continue, or q <return> to quit--- sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7f3060000d98, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7f306010a7a0 "20171101104537.144920Z#000000#004#000000"}, o_private = 0x0, o_extra = {slh_first = 0x7f306e4f6420}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 2, oh_conn = 0x7f306e4f7340, oh_msgid = 0, oh_protocol = 0, oh_tid = 139845985863424, oh_threadctx = 0x7f306e4f7b90, oh_tmpmemctx = 0x7f30600008c0, oh_tmpmfuncs = 0x72e140 <slap_sl_mfuncs>, oh_counters = 0x731640 <slap_counters>, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>, oh_extensions = 0x0}, ob_controls = { 0x0 <repeats 17 times>, 0x7f306e4f6ce0, 0x0 <repeats 14 times>}} op = 0x7f306e4f7600 rc = 0 dostop = 0 s = 19 i = <optimized out> defer = 1 fail = 0 freeinfo = 0 be = 0xc37f50 #8 0x0000000000430bdf in connection_read_thread (ctx=0x7f306e4f7b90, argv=0x13) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/servers/slapd/connection.c:1296 rc = <optimized out> cri = {op = 0x0, func = 0x4937f0 <do_syncrepl>, arg = 0xc47c00, ctx = 0x7f306e4f7b90, nullop = <optimized out>} s = 19 #9 0x00007f32569b17f2 in ldap_int_thread_pool_wrapper (xpool=0xbd4700) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.45-r2/work/openldap-2.4.45/libraries/libldap_r/tpool.c:696 pool = 0xbd4700 task = 0x7f308c000ce0 work_list = <optimized out> ctx = {ltu_id = 139845985863424, ltu_key = {{ltk_key = 0x484d20 <slap_sl_mem_init>, ltk_data = 0x7f30600008c0, ltk_free = 0x484bf0 <slap_sl_mem_destroy>}, {ltk_key = 0xef9ca0, ---Type <return> to continue, or q <return> to quit--- ltk_data = 0x7f30601018f0, ltk_free = 0x7f3251ed2730 <mdb_reader_free>}, { ltk_key = 0x7f3251ec85f0 <search_stack>, ltk_data = 0x7f306c9f6010, ltk_free = 0x7f3251ec8700 <search_stack_free>}, {ltk_key = 0x7f3251ec8550 <scope_chunk_get>, ltk_data = 0x7f306d9f7010, ltk_free = 0x7f3251ec86d0 <scope_chunk_free>}, { ltk_key = 0x42e370 <conn_counter_init>, ltk_data = 0x7f30601091f0, ltk_free = 0x42e450 <conn_counter_destroy>}, {ltk_key = 0x443960 <slap_op_free>, ltk_data = 0x7f30681b0200, ltk_free = 0x443930 <slap_op_q_destroy>}, {ltk_key = 0xcf3410, ltk_data = 0x7f306010bef0, ltk_free = 0x7f3251ed2730 <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x7f308424c830, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 24 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #10 0x00007f3255d2f3e4 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #11 0x00007f3255a713ed in clone () from /lib64/libc.so.6 No symbol table info available.

1 0

(ITS#8768) Syncprov shouldn't send a new cookie at the end of delete phase
by ondra＠openldap.org 31 Oct '17

31 Oct '17

Full_Name: Ondrej Kuznik Version: master/re24 OS: URL: Submission from: (NULL) (82.10.24.68) If sessionlog data is available and found useful, syncprov will send a cookie at the end of delete phase, itself followed by the entries modified since time recorded in the client's original cookie. Some of those entries might have been last modified before the new cookie's recorded time and if the connection is severed before this is communicated, they would not be re-sent under the new cookie. To replicate this issue, in test043, configure sessionlog and after it has finished, run ldapsearch with a cookie set to entryCSN from the mod that adds dc=testdomain2,dc=example,dc=com and record the cookie returned at the end of delete phase (it is the operation that deletes cn=Rosco P. Coltrane,ou=Retired,ou=People,dc=example,dc=com). Then try to run a syncrepl search with the recorded cookie instead. Taking only the information from this search and delete phase from the previous search, the client will not see modifications to these objects: - cn=ITD Staff,ou=Groups,dc=example,dc=com - cn=Gern Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com - ou=Retired,ou=People,dc=example,dc=com

1 0

Re: (ITS#8116) [PATCH] ldapsearch: print 'SyncInfo Received' as a comment.
by ondra＠mistotebe.net 31 Oct '17

31 Oct '17

On Wed, Apr 29, 2015 at 05:04:27PM +0000, hyc(a)symas.com wrote: > linuxgeek(a)gmail.com wrote: >> When the -Esync command line option is used and a Sync Info >> Message (RFC4533) is received, ldapsearch simply prints >> 'SyncInfo Received' to STDOUT. This causes LDIF parsers and >> other tools which consume ldapsearch output to break on invalid >> input. >> >> Change this informational message to be conveyed as a comment. >> Additionally, hide the message when comments are disabled (-LL or >> -LLL). > > If we're going to the trouble of patching this bit of code, I wonder if > it would be worthwhile to actually print the contents of the syncinfo as > well. Maybe a hex dump. It has just been useful to be able to observe and experiment with syncrepl from ldapsearch so I went ahead and implemented this. The patch is available at branch ITS8116 here: https://github.com/mistotebe/openldap/tree/ITS8116 -- 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: (ITS#8767) Binddn issue with a comma in the DN
by michael＠stroeder.com 31 Oct '17

31 Oct '17

This is a cryptographically signed message in MIME format. --------------ms060700000500090903040904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable christian.palacios(a)cgg.com wrote: > We have an OpenLDAP server configured as a proxy so that it can be used= to > authenticate against three Active Directory domains. We are able to ge= t it > configured with two of the domains, but it fails with the third one. T= he > problem that I have been told is that the binddn definition cannot have= a comma > in the DN. Unfortunately we don't have control over this third domain = and all > of the accounts, including service accounts, have a format that include= s a comma > in their DN. For example: binddn=3D"CN=3Dgisadmin, CNE (SVC),OU=3DCNE-= Calgary > FDSCI,OU=3DNASA,OU=3DService Accounts,DC=3Dint,DC=3Dcgg,DC=3Dcom" crede= ntials=3D"" > mode=3D"legacy" flags=3D"non-prescriptive". The ITS is only for reporting bugs. This is not a bug. It's a usage question. You should post such questions to openldap-technical mailing list after subscribing to it: https://www.openldap.org/lists/mm/listinfo/openldap-technical A short hint about escaping, e.g. a comma in DN string representation: https://tools.ietf.org/html/rfc4514#section-2.4 Note that depending on your client config system more escaping might be needed because of the config syntax. Ciao, Michael. --------------ms060700000500090903040904 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMDMxMTYzOTM0WjAvBgkq hkiG9w0BCQQxIgQge7+Z+6sM+RRTXVvx9x3W5I6PSKNKGt7n9Sho8ugXDgQwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEASkkADRugnyWq1+dVYV8mSaz8+G07v0p065+5ydk22wu9iwWPCjvvDcG2c0iA3erGi0PF zKFTBygRjEfKUPbC3u2zVIH4C0k/3r8GO0eiKHYUzi1fVtWRvk+ARfT1rOQEVDwQsZtL4J0l 4ufIXNJiR9AdvQhPrs6yywVhj7TV6Upt8QsjdZtwW/6pZHPKv5U2uu2DPfGANEqfqAvef0tF o/abwZO3PSew42yYLTdP8vRK0EYfFePvIZhZ6NmQjt70Rdsl8xEtgLPyTN/qCEJ5M/DcHWzw 8AgeOI3BhCUjlpO0THnAMGacx/5eo6O5+yjvpPh0zUed3LVdP+bFcSMcVQAAAAAAAA== --------------ms060700000500090903040904--

1 0

(ITS#8767) Binddn issue with a comma in the DN
by christian.palacios＠cgg.com 31 Oct '17

31 Oct '17

Full_Name: Christian Palacios Version: LTB package version 2.4.45 OS: Debian "Stretch" URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (104.129.192.55) We have an OpenLDAP server configured as a proxy so that it can be used to authenticate against three Active Directory domains. We are able to get it configured with two of the domains, but it fails with the third one. The problem that I have been told is that the binddn definition cannot have a comma in the DN. Unfortunately we don't have control over this third domain and all of the accounts, including service accounts, have a format that includes a comma in their DN. For example: binddn="CN=gisadmin, CNE (SVC),OU=CNE-Calgary FDSCI,OU=NASA,OU=Service Accounts,DC=int,DC=cgg,DC=com" credentials="" mode="legacy" flags="non-prescriptive". As you can see, the DN has a comma next to the gisadmin value. We have been told that this is a problem so we want to see if anyone has a fix for this so that the defined binddn can have a comma in it. It's going to be hard to get another user account created in a different format that will work, so we're hoping there is a quick fix for OpenLDAP. >From the OpenLDAP Log file: Oct 16 10:11:17 CNE-LDA01 slapd[5501]: @(#) $OpenLDAP: slapd 2.4.45 (Jun 10 2017 17:54:31) $#012#011root@stretch:/opt/openldap-deb/debian/paquet-openldap-debian/openldap-ltb-2.4.45/servers/slapd Oct 16 10:11:17 CNE-LDA01 slapd[5501]: invalid bind config value binddn=CN=gisadmin, CNE (SVC),OU=CNE-Calgary FDSCI,OU=NASA,OU=Service Accounts,DC=int,DC=cgg,DC=com Oct 16 10:11:17 CNE-LDA01 slapd[5501]: /usr/local/openldap/etc/openldap/slapd.conf: line 65: "idassert-bind <args>": unable to parse field "binddn=CN=gisadmin, CNE (SVC),OU=CNE-Calgary FDSCI,OU=NASA,OU=Serv$ Oct 16 10:11:17 CNE-LDA01 slapd[5501]: slapd stopped.

1 0

Re: (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by emmanuel.fuste＠thalesgroup.com 31 Oct '17

31 Oct '17

SGVsbG8sDQoNCkkgc3VwcG9ydCBNaWhhaSB2aWV3IG9mIHRoZSBzcGVjLg0KRXZlbiBpZiBpdCBw bGVhc2UgSm9uIHVzZSBjYXNlLCBjdXJyZW50IGJlaGF2aW9yIGNvdWxkIGJlIHZpZXcgYXMgDQpp bmNvbnNpc3RlbnQgd2l0aCB0aGUgc3BlYywgYW5kIG1vcmUgZ2VuZXJhbGx5IGlzIGluY29uc2lz dGVudCB3aXRoIA0KY29tbW9ubHkgbWVldCBwYXNzd29yZCBwb2xpY3kgc3lzdGVtcy4NCg0KIEZy b20gYSBzZWN1cml0eSBwb2ludCBvZiB2aWV3IG9uZSBhdHRlbXB0IG9yIHRyZWUgKG9yIGZpdmUg b3IgLi4uKSANCmFmdGVyIHRoZSAidW5sb2NrIiBpcyB0aGUgIHNhbWUsIGJydXRlIGZvcmNlIGF0 dGVtcHRzIGFyZSBkZWZlYXRlZC4NCg0KIEZyb20gYSBzdXBwb3J0L3NlcnZpY2UgZGVzayBwb2lu dCBvZiB2aWV3LCAgdGhpcyBpcyBub3QgdGhlIHNhbWUgZ2FtZS4NCkEgY29tbW9ubHkgc2FuZSAi cHdNYXhGYWlsdXJlIiBvZiAzIGlzIGdvb2QgZm9yIGRhaWx5IGZpbmdsaW5nIGVycm9ycy4NCkJ1 dCBmb3IgaG9saWRheSByZXR1cm5zLCBvbmUgdW5sb2NrIGZvciB0cmVlIG1vcmUgYXR0ZW1wdHMg aXMgb2Z0ZW4gDQpuZWNlc3NhcnkgYW5kIHN1ZmZpY2llbnQgYmVmb3JlIHRoZSAiaGVhdnkiIHBh c3N3b3JkIGNoYW5nZSBwcm9jZXNzLg0KDQpJbiBjYXNlIG9mIG1hbGljaW91cyBhdHRlbXB0cywg d2Ugb25seSBvbmUgImJ5IGRlc2lnbiIgYXR0ZW1wdCBhZnRlciANCnVubG9jaywgeW91IGp1c3Qg Z2V0IERvUyBhbXBsaWZpY2F0aW9uIGFuZCBmb3JjZSBhIGVuZGxlc3MgcGFzc3dvcmQgDQpjaGFu Z2UgcHJvY2VzcyBmb3IgdGhlIHVzZXIgYmVmb3JlIHRoZSBhZG1pbnMgZml4IHRoZSBzb3VyY2Ug b2YgdGhlIA0KbG9ja2luZyAocmVhbCBtYWxpY2lvdXMgc291cmNlIG9mIGF0dGVtcHRzIG9yIG5v dCkuDQoNCklmIHRoZSBwcm9qZWN0IGFncmVlIHdpdGggSm9obiB2aWV3IG9mIHRoZSBpbnRlcnBy ZXRhdGlvbiBvZiB0aGUgYWN0dWFsIA0KaW1wbGVtZW50ZWQgc3BlYyAod2hpY2ggaXMgbm90IHRo ZSBsYXRlc3QgcHVibGlzaGVkIG9uZSksIGl0IGNvdWxkIGJlIA0KZG9jdW1lbnRlZCB3aXRoIG9u ZSBsaW5lciBpbiB0aGUgcHBvbGljeSBvdmVybGF5IGRvYy4NCg0KRW1tYW51ZWwuDQoNClBTOiBl dmVuIGlzIHRoZSBlbWFpbCBhZGRyZXNzIHNheSBvdGhlcndpc2UsIEknbSBub3QgaW4gdGhlIHNh bWUgDQooc3ViKWVudGl0eSBhcyBNaWhhaSBhbmQgZGlkIG5vdCBrbm93IE1paGFpIGJlZm9yZSB0 aGlzIElUUy4=

1 0

RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by jckidder＠aep.com 31 Oct '17

31 Oct '17

I can't speak on behalf of the project but my position has not changed. If= we pursue your interpretation of the standard to a logical conclusion then= once the account is locked the user can never authenticate again. That is= not the intent. The goal of any lockout mechanism is to make brute force password guessing = impractical. They keyword here is guessing. How many attempts should your= users have to legitimately guess their password? If your users don't know= their password then they need to change it anyway. If your users can't re= member the password they just changed then you have problems you can't addr= ess in code. If you want to give your users more than 3 attempts to guess = their password then set pwdMaxFailure to that value. Don't set it to a low= er value and then manually unlock their accounts multiple times. Unlocking= a user's account so that they can continue to guess their password adds no= value. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: MUNTEANU Mihai-Adrian [mailto:mihai.munteanu@thalesgroup.com]=20 Sent: Tuesday, October 31, 2017 3:57 AM To: Jon C Kidder; openldap-its(a)OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdF= ailureTime Hello Jon, Have you reconsidered your resolution after my last comment related to the= password policy described in https://urldefense.proofpoint.com/v2/url?u=3D= https-3A__tools.ietf.org_html_draft-2Dbehera-2Dldap-2Dpassword-2Dpolicy-2D1= 0&d=3DDwIFAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&m=3DUita= RrJCJvbTRkNKnAG1MUsggW9F3FGUn7Nufv__g0U&s=3DxO5WwTWeNQanNDEj4KkwiizlVWEJDjY= kkfXMVAglLZM&e=3D ? Thanks, Kind regards, Mihai -----Original Message----- From: Jon C Kidder [mailto:jckidder@aep.com] Sent: Friday, October 27, 2017 2:46 PM To: MUNTEANU Mihai-Adrian; openldap-its(a)OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdF= ailureTime This is not a bug. pwdFailureTime is only cleared after the first successful bind. If you're = manually unlocking the user's account it can be assumed that you've gone th= rough the exercise of ensuring the user is using the proper password. Perh= aps by setting a new temporary password? If you haven't gone through that = exercise 1 attempt vs multiple attempts is not going to matter. The user i= s going to lock their account again anyway. We've just recently deployed a password self-service tool and have accounte= d for this current behavior in our help desk procedures. Our cyber securit= y team loves this behavior. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4= 970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: openldap-bugs [mailto:openldap-bugs-bounces@openldap.org] On Behalf O= f mihai.munteanu(a)thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its(a)OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailu= reTime This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attac= hments. If suspicious please forward to incidents(a)aep.com for review. ********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.openldap.org_= incoming_&d=3DDwIBAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&= m=3D3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=3DfE28OfhKUqMQkynWWNTkl9-= sUN8henbPip3IgOunodI&e=3D Submission from: (NULL) (86.12.190.162) Scenario:=20 0. we have configured that after 3 login failed attempts, the account to be= locked. 1. user test1 fails to login 3 times -> account is locked 2. admin unlocks = test1's account and notify test1 user 3. user test1 tries 1 time to login u= sing a wrong password and gets his account locked again. Expectation here: account should not be locked after first attempt of a wro= ng password, but after third attempt, as it was the case on step 1.=20 It turns out that it is locked again after first attempt due to the fact th= at on step 2, only pwdAccountLockedTime field is removed from LDAP, but not= also pwdFailureTime fields. It seems pwdFailureTime is internally cleared only: - when test1 successfully authenticate (having his account unlocked) - admin changes test1's password See below my details: $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=3Dadmin,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f unloc= k.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=3Djamessmith,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f = unlock.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... Result: pwdAccountLockedTime is removed but pwdFailureTime is not automatic= ally removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to = be automatically removed via removal of pwdAccountLockedTime.

1 0

RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu＠thalesgroup.com 31 Oct '17

31 Oct '17

Hello Jon, Have you reconsidered your resolution after my last comment related to the= password policy described in https://tools.ietf.org/html/draft-behera-ldap= -password-policy-10 ? Thanks, Kind regards, Mihai -----Original Message----- From: Jon C Kidder [mailto:jckidder@aep.com]=20 Sent: Friday, October 27, 2017 2:46 PM To: MUNTEANU Mihai-Adrian; openldap-its(a)OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdF= ailureTime This is not a bug. pwdFailureTime is only cleared after the first successful bind. If you're = manually unlocking the user's account it can be assumed that you've gone th= rough the exercise of ensuring the user is using the proper password. Perh= aps by setting a new temporary password? If you haven't gone through that = exercise 1 attempt vs multiple attempts is not going to matter. The user i= s going to lock their account again anyway. We've just recently deployed a password self-service tool and have accounte= d for this current behavior in our help desk procedures. Our cyber securit= y team loves this behavior. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4= 970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: openldap-bugs [mailto:openldap-bugs-bounces@openldap.org] On Behalf O= f mihai.munteanu(a)thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its(a)OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailu= reTime This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attac= hments. If suspicious please forward to incidents(a)aep.com for review. ********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.openldap.org_= incoming_&d=3DDwIBAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&= m=3D3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=3DfE28OfhKUqMQkynWWNTkl9-= sUN8henbPip3IgOunodI&e=3D Submission from: (NULL) (86.12.190.162) Scenario:=20 0. we have configured that after 3 login failed attempts, the account to be locked. 1. user test1 fails to login 3 times -> account is locked 2. admin unlocks test1's account and notify test1 user 3. user test1 tries 1 time to login using a wrong password and gets his acc= ount locked again. Expectation here: account should not be locked after first attempt of a wro= ng password, but after third attempt, as it was the case on step 1.=20 It turns out that it is locked again after first attempt due to the fact th= at on step 2, only pwdAccountLockedTime field is removed from LDAP, but not also pwdFailureTime fields. It seems pwdFailureTime is internally cleared only: - when test1 successfully authenticate (having his account unlocked) - admin changes test1's password See below my details: $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=3Dadmin,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f unloc= k.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=3Djamessmith,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f = unlock.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... Result: pwdAccountLockedTime is removed but pwdFailureTime is not automatic= ally removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to = be automatically removed via removal of pwdAccountLockedTime.

1 0

Re: (ITS#8734) Fixes for multiple back-asyncmeta issues
by nivanova＠symas.com 30 Oct '17

30 Oct '17

Hi, A new version of the patch has been uploaded as ftp://ftp.openldap.org/incoming/nadezhda-ivanova-171030.patch It contains fixes to a couple of problems found after the initial submission: 1. A problem where asyncmeta could not proxy a request containing a \0 in the filter 2. An unnecessary and misleading log message, that logged the operation as timed out when it wasn't. ----- Original Message ----- From: "openldap-its" <openldap-its(a)OpenLDAP.org> To: nivanova(a)symas.com Sent: Wednesday, September 13, 2017 4:22:51 PM Subject: Re: (ITS#8734) Fixes for multiple back-asyncmeta issues *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#8734. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#8734) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#8734) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=8734 Please remember to retain your issue tracking number (ITS#8734) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#8764) A small typo in README
by believelinan＠aliyun.com 29 Oct '17

29 Oct '17

Full_Name: Nan Li Version: 2.4.45 OS: URL: Submission from: (NULL) (137.69.117.201) I download source code of version 2.4.45, found a small typo in README at line 32: 32 detailed instructions can be found in the OpenLDAP Admnistrator's where "Admnistrator" should be "Administrator".

1 0

Re: (ITS#8763) ACL scope warning
by Claude.Dube＠MUHC.MCGILL.CA 29 Oct '17

29 Oct '17

--0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-type: multipart/alternative; Boundary="1__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4" --1__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=US-ASCII Ryan, Thank for the information Claude = Ryan Tandy = <ryan(a)nardis.ca> = = To 10/28/2017 07:58 claude.dube(a)muhc.mcgill.ca = PM = cc openldap-its(a)OpenLDAP.org = Subj= ect Re: (ITS#8763) ACL scope warning= = = = = = = Hi Claude, Please use the openldap-technical(a)openldap.org mailing list for usage o= r configuration questions. If you post your slapd.conf to the list I'm sure someone will be able to point out the reason for the warning. This ITS will be closed. = --1__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=US-ASCII Content-Disposition: inline <html><body> Ryan, Thank for the information<b= r> Claude <img width=3D"16" height=3D"16" src=3D"cid:1__=3D0ABB0B5BDFE312E48f9e8a= 93d(a)isn.rtss.qc.ca" border=3D"0" alt=3D"Inactive hide details for Ryan = Tandy ---10/28/2017 07:58:38 PM---Ryan Tandy <ryan(a)nardis.ca>"><f= ont size=3D"2" color=3D"#424282" face=3D"sans-serif">Ryan Tandy ---10/2= 8/2017 07:58:38 PM---Ryan Tandy <ryan(a)nardis.ca> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td style=3D"background-image:url(cid:2__=3D0ABB0B5B= DFE312E48f9e8a93d(a)isn.rtss.qc.ca); background-repeat: no-repeat; " widt= h=3D"40%"> <ul style=3D"padding-left: 72pt"><= b>Ryan Tandy <ryan(a)nardis.ca>  10/28/2017 07:58 PM</ul>= </td><td width=3D"60%"> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D= "cid:3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D= ""> <div align=3D"right">To</di= v></td><td width=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D= 0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca" border=3D"0" alt=3D""> <ul style=3D"padding-left: 7pt">cl= aude.dube(a)muhc.mcgill.ca</ul> </td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D= "cid:3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D= ""> <div align=3D"right">cc</di= v></td><td width=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D= 0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca" border=3D"0" alt=3D""> <ul style=3D"padding-left: 7pt">op= enldap-its(a)OpenLDAP.org</ul> </td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D= "cid:3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D= ""> <div align=3D"right">Subject</font= ></div></td><td width=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid= :3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D"">= <ul style=3D"padding-left: 7pt">Re= : (ITS#8763) ACL scope warning</ul> </td></tr> </table> <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"58"><img width=3D"1" height=3D"1" src=3D= "cid:3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D= ""></td><td width=3D"336"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D= 0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca" border=3D"0" alt=3D""></td></= tr> </table> </td></tr> </table> <tt>Hi Claude, Please use the openldap-technical(a)openldap.org mailing list for usage o= r configuration questions. If you post your slapd.conf to the list I'm <b= r> sure someone will be able to point out the reason for the warning. This ITS will be closed. </tt> </body></html>= --1__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4-- --0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-type: image/gif; name="pic11478.gif" Content-Disposition: inline; filename="pic11478.gif" Content-ID: <2__=0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4--

1 0

Re: (ITS#8763) ACL scope warning
by ryan＠nardis.ca 28 Oct '17

28 Oct '17

Hi Claude, Please use the openldap-technical(a)openldap.org mailing list for usage or configuration questions. If you post your slapd.conf to the list I'm sure someone will be able to point out the reason for the warning. This ITS will be closed.

1 0

(ITS#8763) ACL scope warning
by claude.dube＠muhc.mcgill.ca 28 Oct '17

28 Oct '17

Full_Name: Claude Version: 2.4.45 OS: entOS Linux release 7.3.1611 (Core) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.168.152.20) the slapd.conf openldap configuration file see below. slapd daemon is issuing ACL scope warning for unknown reason that ACL is in the slapd.conf warning messages : config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context How that warning can be addressed? Thanks how to recreate warning messages based on slapd.conf below. I'd like to get of rid of that ACL scope warning Thanks, Claude ### - slapd is launched by this running command ### /usr/sbin/slapd -d acl # # output of slapd daemon # 59f51611 @(#) $OpenLDAP: slapd 2.4.45 (Sep 10 2017 16:37:12) $ root@templateldap:/a/admin/ldap/openldap-2.4.45/servers/slapd 59f51611 => access_allowed: search access to "cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) 59f51611 => access_allowed: search access to "cn=schema,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) 59f51611 => access_allowed: search access to "cn={0}core,cn=schema,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) 59f51611 => access_allowed: search access to "cn={1}cosine,cn=schema,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) 59f51611 => access_allowed: search access to "cn={2}inetorgperson,cn=schema,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) 59f51611 => access_allowed: search access to "olcDatabase={-1}frontend,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) Backend ACL: access to dn.base="dc=example,dc=com" by * read 59f51611 => access_allowed: search access to "olcDatabase={0}config,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) Backend ACL: access to dn.base="cn=admin,cn=config" by * none 59f51611 => access_allowed: search access to "olcDatabase={1}mdb,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) Backend ACL: access to dn.children="dc=example,dc=com" by * search Backend ACL: access to dn.base="dc=example,dc=com" by * read Backend ACL: access to * by * none 59f51611 config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context 59f51611 slapd starting #### - slapd.conf - ##### # # NOTES: inetorgperson picks up attributes and objectclasses # from all three schemas # # NB: RH Linux schemas in /etc/openldap # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema # NO REFERRALS # DON'T bother with ARGS file pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args loglevel ACL disallow bind_anon # ##################################### # frontend database ##################################### # access to dn.base="dc=example,dc=com" by * read ####################################################################### # bdb database definitions # # replace example and com below with a suitable domain # # If you don't have a domain you can leave it since example.com # is reserved for experimentation or change them to My and inc ####################################################################### database mdb #access to dn.base="dc=example,dc=com" by * read access to dn.children="dc=example,dc=com" by * search access to dn.base="dc=example,dc=com" by * read suffix "dc=example, dc=com" # # superuser rootdn "cn=jimbob, dc=example, dc=com" rootpw dirtysecret # The database directory MUST exist prior to running slapd AND # change path as ncessary directory /var/lib/ldap # Indices to maintain for this directory # required if searches will use # unique id so equality match only index uid eq # allows general searching on commonname, givenname and email index cn,gn,mail eq,sub # allows multiple variants on surname searching index sn eq,sub # sub above includes subintial,subany,subfinal # optimise department searches index ou eq # if searches will include objectClass uncomment following # index objectClass eq # shows use of default index parameter index default eq,sub # indices missing - uses default eq,sub index telephonenumber # ##################################### # config database ##################################### # database config access to dn.base="cn=admin,cn=config" by * none rootdn "cn=admin,cn=config" rootpw {SSHA}rZGfPJkJYWy036tqoQb9jZ4Tz36c7ddG

1 0

RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu＠thalesgroup.com 27 Oct '17

27 Oct '17

According to https://tools.ietf.org/html/draft-behera-ldap-password-policy-= 10 , chapter 5.2.13. pwdMaxFailure This field is described as: "This attribute specifies the number of consecutive failed bind attempts af= ter which the password may not be used to authenticate." In first case, when user is just created, for example, he can fail to login= 3 times and accounts get locked, which means the "password may not be used= to authenticate", as stated above. However, after admin unlocks the account, the user is still registered with= 3 failed bind attempts (the pwdFailureTime is not deleted) but now the use= r can use the password to authenticate. This scenario contradicts the defin= ition of pwdFailureTime. Moreover, the pwdLockout attribute description says, on chapter 5.2.11 that= " This attribute indicates, when its value is "TRUE", that the password ma= y not be used to authenticate after a specified number of consecutive faile= d bind attempts. The maximum number of consecutive failed bind attempts is= specified in pwdMaxFailure." In our password policy, pwdLockout is set to TRUE but after admin unlocks t= est1 account, because pwdFailureTime is not cleared, it is considered that = there are already 3 consecutive failed bind attempts, am I right? However, in this case, the user is allowed to use the password for new auth= entication which contradicts the definition of pwdLockout field. Kind regards, Mihai (+40213032732)=20 -----Original Message----- From: Jon C Kidder [mailto:jckidder@aep.com]=20 Sent: Friday, October 27, 2017 2:46 PM To: MUNTEANU Mihai-Adrian; openldap-its(a)OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdF= ailureTime This is not a bug. pwdFailureTime is only cleared after the first successful bind. If you're = manually unlocking the user's account it can be assumed that you've gone th= rough the exercise of ensuring the user is using the proper password. Perh= aps by setting a new temporary password? If you haven't gone through that = exercise 1 attempt vs multiple attempts is not going to matter. The user i= s going to lock their account again anyway. We've just recently deployed a password self-service tool and have accounte= d for this current behavior in our help desk procedures. Our cyber securit= y team loves this behavior. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4= 970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: openldap-bugs [mailto:openldap-bugs-bounces@openldap.org] On Behalf O= f mihai.munteanu(a)thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its(a)OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailu= reTime This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attac= hments. If suspicious please forward to incidents(a)aep.com for review. ********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.openldap.org_= incoming_&d=3DDwIBAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&= m=3D3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=3DfE28OfhKUqMQkynWWNTkl9-= sUN8henbPip3IgOunodI&e=3D Submission from: (NULL) (86.12.190.162) Scenario:=20 0. we have configured that after 3 login failed attempts, the account to be locked. 1. user test1 fails to login 3 times -> account is locked 2. admin unlocks test1's account and notify test1 user 3. user test1 tries 1 time to login using a wrong password and gets his acc= ount locked again. Expectation here: account should not be locked after first attempt of a wro= ng password, but after third attempt, as it was the case on step 1.=20 It turns out that it is locked again after first attempt due to the fact th= at on step 2, only pwdAccountLockedTime field is removed from LDAP, but not also pwdFailureTime fields. It seems pwdFailureTime is internally cleared only: - when test1 successfully authenticate (having his account unlocked) - admin changes test1's password See below my details: $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=3Dadmin,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f unloc= k.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=3Djamessmith,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f = unlock.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... Result: pwdAccountLockedTime is removed but pwdFailureTime is not automatic= ally removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to = be automatically removed via removal of pwdAccountLockedTime.

1 0

Re: (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu＠thalesgroup.com 27 Oct '17

27 Oct '17

--_000_73687a3a63cc4dd6950d893d7e7e73e9THSONEA01HUB06Ponegrp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. See below the contents of our password policy: # Search scope: sub # Search filter: (objectClass=3D*) # Total entries: 1 # # Generated by LDAP Account Manager (http://www.ldap-account-manager.org) on October 27, 2017 10:48 am # Versio= n: 5.5 version: 1 # Entry 1: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc=3Dcom dn: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc=3Dcom cn: passwordDefault createtimestamp: 20171004124029Z creatorsname: dc=3DManager,dc=3Dthales,dc=3Dcom entrycsn: 20171004124029.795969Z#000000#000#000000 entrydn: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc=3Dcom entryuuid: f3031268-3d4c-1037-9198-453c4b052276 hassubordinates: FALSE modifiersname: dc=3DManager,dc=3Dthales,dc=3Dcom modifytimestamp: 20171004124029Z objectclass: top objectclass: device objectclass: pwdPolicy objectclass: pwdPolicyChecker pwdallowuserchange: TRUE pwdattribute: userPassword pwdcheckmodule: check_password.so pwdcheckquality: 2 pwdexpirewarning: 0 pwdfailurecountinterval: 0 pwdgraceauthnlimit: 0 pwdinhistory: 4 pwdlockout: TRUE pwdlockoutduration: 0 pwdmaxage: 7776000 pwdmaxfailure: 3 pwdminage: 0 pwdminlength: 8 pwdmustchange: FALSE pwdsafemodify: FALSE structuralobjectclass: device subschemasubentry: cn=3DSubschema ----------------- 2. we are using the lamcms from www.ldap-account-manager.org<http://www.lda= p-account-manager.org>. In the web interface there is a "Unlock account" bu= tton which we use. I suppose they are using the php ldap_modify() method in= order to remove the 'pwdAccountLockedTime' field. Of course, temporary mod= ifying their sources and trying to remove also the pwdFailureTime generates= the following error: "Was unable to remove attributes from DN: cn=3Dtest1,ou=3Dusers,dc=3Dthales= ,dc=3Dcom. LDAP error, server says: Constraint violation - pwdFailureTime: no user mod= ification allowed" We've contact also guys from ldap-account-manager.org but they said they ca= n't do anything on their side and suggested to contact you. Kind regards, Mihai --_000_73687a3a63cc4dd6950d893d7e7e73e9THSONEA01HUB06Ponegrp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style></style></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1>1. See below = the contents of our password policy:<o:p></o:p>= # Search scope: sub<o:p></o:p># Search filter: = (objectClass=3D*)<o:p></o:p># Total entries: 1<= o:p></o:p>#<o:p></o:p># Generated by LDAP Account Manager<o:p></o:p>(<a href=3D"http://www.ldap-account-manager.org">http://www.ldap-account-= manager.org</a>) on October 27, 2017 10:48 am # Version: 5.5<o:p></o:p>= <o:p> </o:p>versio= n: 1<o:p></o:p><o:p> </o:p># Entry 1: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc= =3Dcom<o:p></o:p>dn: cn=3DpasswordDefault,ou=3D= policies,dc=3Dthales,dc=3Dcom<o:p></o:p>cn: pas= swordDefault<o:p></o:p>createtimestamp: 2017100= 4124029Z<o:p></o:p>creatorsname: dc=3DManager,d= c=3Dthales,dc=3Dcom<o:p></o:p>entrycsn: 2017100= 4124029.795969Z#000000#000#000000<o:p></o:p>ent= rydn: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc=3Dcom<o:p></o:p></p= >entryuuid: f3031268-3d4c-1037-9198-453c4b052276<o:= p></o:p>hassubordinates: FALSE<o:p></o:p><p= class=3DMsoPlainText>modifiersname: dc=3DManager,dc=3Dthales,dc=3Dcom<o:p>= </o:p>modifytimestamp: 20171004124029Z<o:p></o:= p>objectclass: top<o:p></o:p>objectclass: device<o:p></o:p>objectc= lass: pwdPolicy<o:p></o:p>objectclass: pwdPolic= yChecker<o:p></o:p>pwdallowuserchange: TRUE<o:p= ></o:p>pwdattribute: userPassword<o:p></o:p></p= >pwdcheckmodule: check_password.so<o:p></o:p><p= class=3DMsoPlainText>pwdcheckquality: 2<o:p></o:p>pwdexpirewarning: 0<o:p></o:p>pwdfailurecou= ntinterval: 0<o:p></o:p>pwdgraceauthnlimit: 0<o= :p></o:p>pwdinhistory: 4<o:p></o:p>pwdlockout: TRUE<o:p></o:p>pwdl= ockoutduration: 0<o:p></o:p>pwdmaxage: 7776000<= o:p></o:p>pwdmaxfailure: 3<o:p></o:p>pwdminage: 0<o:p></o:p>pwdmin= length: 8<o:p></o:p>pwdmustchange: FALSE<o:p></= o:p>pwdsafemodify: FALSE<o:p></o:p>structuralobjectclass: device<o:p></o:p>subschemasubentry: cn=3DSubschema<o:p></o:p><o:p> </o:p>-----------------<o:p></= o:p>2. we are using the lamcms from <a href=3D"= http://www.ldap-account-manager.org">www.ldap-account-manager.org</a>. In t= he web interface there is a "Unlock account" button which we use.= I suppose they are using the php ldap_modify() method in order to remove t= he 'pwdAccountLockedTime' field. Of course, temporary modifying their sourc= es and trying to remove also the pwdFailureTime generates the following err= or: <o:p></o:p>"Was unable to remove attri= butes from DN: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom.<o:p></o:p><p= class=3DMsoPlainText>LDAP error, server says: Constraint violation - pwdFa= ilureTime: no user modification allowed"<o:p></o:p>We've contact also guys from ldap-account-manager.org but they sai= d they can't do anything on their side and suggested to contact you.<o:p></= o:p><o:p> </o:p><o:p> </o:p>= Kind regards,<o:p></o:p>Mihai<o:p></o:p><o:p> </o:p></div></body></html>= --_000_73687a3a63cc4dd6950d893d7e7e73e9THSONEA01HUB06Ponegrp_--

1 0

RE: (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu＠thalesgroup.com 27 Oct '17

27 Oct '17

--_002_D204E7513BE6154188ADA82EFFA18AC69B58B3FFFFTHSONEA01CMS0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCjEuIFNlZSBhdHRhY2hlZCBhbmQgYmVsb3cgdGhlIGNvbnRlbnRzIG9mIG91ciBwYXNzd29y ZCBwb2xpY3k6DQojIFNlYXJjaCBzY29wZTogc3ViDQojIFNlYXJjaCBmaWx0ZXI6IChvYmplY3RD bGFzcz0qKQ0KIyBUb3RhbCBlbnRyaWVzOiAxDQojDQojIEdlbmVyYXRlZCBieSBMREFQIEFjY291 bnQgTWFuYWdlcg0KKGh0dHA6Ly93d3cubGRhcC1hY2NvdW50LW1hbmFnZXIub3JnKSBvbiBPY3Rv YmVyIDI3LCAyMDE3IDEwOjQ4IGFtICMgVmVyc2lvbjogNS41DQoNCnZlcnNpb246IDENCg0KIyBF bnRyeSAxOiBjbj1wYXNzd29yZERlZmF1bHQsb3U9cG9saWNpZXMsZGM9dGhhbGVzLGRjPWNvbQ0K ZG46IGNuPXBhc3N3b3JkRGVmYXVsdCxvdT1wb2xpY2llcyxkYz10aGFsZXMsZGM9Y29tDQpjbjog cGFzc3dvcmREZWZhdWx0DQpjcmVhdGV0aW1lc3RhbXA6IDIwMTcxMDA0MTI0MDI5Wg0KY3JlYXRv cnNuYW1lOiBkYz1NYW5hZ2VyLGRjPXRoYWxlcyxkYz1jb20NCmVudHJ5Y3NuOiAyMDE3MTAwNDEy NDAyOS43OTU5NjlaIzAwMDAwMCMwMDAjMDAwMDAwDQplbnRyeWRuOiBjbj1wYXNzd29yZERlZmF1 bHQsb3U9cG9saWNpZXMsZGM9dGhhbGVzLGRjPWNvbQ0KZW50cnl1dWlkOiBmMzAzMTI2OC0zZDRj LTEwMzctOTE5OC00NTNjNGIwNTIyNzYNCmhhc3N1Ym9yZGluYXRlczogRkFMU0UNCm1vZGlmaWVy c25hbWU6IGRjPU1hbmFnZXIsZGM9dGhhbGVzLGRjPWNvbQ0KbW9kaWZ5dGltZXN0YW1wOiAyMDE3 MTAwNDEyNDAyOVoNCm9iamVjdGNsYXNzOiB0b3ANCm9iamVjdGNsYXNzOiBkZXZpY2UNCm9iamVj dGNsYXNzOiBwd2RQb2xpY3kNCm9iamVjdGNsYXNzOiBwd2RQb2xpY3lDaGVja2VyDQpwd2RhbGxv d3VzZXJjaGFuZ2U6IFRSVUUNCnB3ZGF0dHJpYnV0ZTogdXNlclBhc3N3b3JkDQpwd2RjaGVja21v ZHVsZTogY2hlY2tfcGFzc3dvcmQuc28NCnB3ZGNoZWNrcXVhbGl0eTogMg0KcHdkZXhwaXJld2Fy bmluZzogMA0KcHdkZmFpbHVyZWNvdW50aW50ZXJ2YWw6IDANCnB3ZGdyYWNlYXV0aG5saW1pdDog MA0KcHdkaW5oaXN0b3J5OiA0DQpwd2Rsb2Nrb3V0OiBUUlVFDQpwd2Rsb2Nrb3V0ZHVyYXRpb246 IDANCnB3ZG1heGFnZTogNzc3NjAwMA0KcHdkbWF4ZmFpbHVyZTogMw0KcHdkbWluYWdlOiAwDQpw d2RtaW5sZW5ndGg6IDgNCnB3ZG11c3RjaGFuZ2U6IEZBTFNFDQpwd2RzYWZlbW9kaWZ5OiBGQUxT RQ0Kc3RydWN0dXJhbG9iamVjdGNsYXNzOiBkZXZpY2UNCnN1YnNjaGVtYXN1YmVudHJ5OiBjbj1T dWJzY2hlbWENCg0KLS0tLS0tLS0tLS0tLS0tLS0NCjIuIHdlIGFyZSB1c2luZyB0aGUgbGFtY21z IGZyb20gd3d3LmxkYXAtYWNjb3VudC1tYW5hZ2VyLm9yZy4gSW4gdGhlIHdlYiBpbnRlcmZhY2Ug dGhlcmUgaXMgYSAiVW5sb2NrIGFjY291bnQiIGJ1dHRvbiB3aGljaCB3ZSB1c2UuIEkgc3VwcG9z ZSB0aGV5IGFyZSB1c2luZyB0aGUgcGhwIGxkYXBfbW9kaWZ5KCkgbWV0aG9kIGluIG9yZGVyIHRv IHJlbW92ZSB0aGUgJ3B3ZEFjY291bnRMb2NrZWRUaW1lJyBmaWVsZC4gT2YgY291cnNlLCB0ZW1w b3JhcnkgbW9kaWZ5aW5nIHRoZWlyIHNvdXJjZXMgYW5kIHRyeWluZyB0byByZW1vdmUgYWxzbyB0 aGUgcHdkRmFpbHVyZVRpbWUgZ2VuZXJhdGVzIHRoZSBmb2xsb3dpbmcgZXJyb3I6IA0KIldhcyB1 bmFibGUgdG8gcmVtb3ZlIGF0dHJpYnV0ZXMgZnJvbSBETjogY249dGVzdDEsb3U9dXNlcnMsZGM9 dGhhbGVzLGRjPWNvbS4NCkxEQVAgZXJyb3IsIHNlcnZlciBzYXlzOiBDb25zdHJhaW50IHZpb2xh dGlvbiAtIHB3ZEZhaWx1cmVUaW1lOiBubyB1c2VyIG1vZGlmaWNhdGlvbiBhbGxvd2VkIg0KV2Un dmUgY29udGFjdCBhbHNvIGd1eXMgZnJvbSBsZGFwLWFjY291bnQtbWFuYWdlci5vcmcgYnV0IHRo ZXkgc2FpZCB0aGV5IGNhbid0IGRvIGFueXRoaW5nIG9uIHRoZWlyIHNpZGUgYW5kIHN1Z2dlc3Rl ZCB0byBjb250YWN0IHlvdS4NCg0KDQpLaW5kIHJlZ2FyZHMsDQpNaWhhaSAoKzQwMjEzMDMyNzMy KSANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWljaGFlbCBTdHLDtmRl ciBbbWFpbHRvOm1pY2hhZWxAc3Ryb2VkZXIuY29tXSANClNlbnQ6IEZyaWRheSwgT2N0b2JlciAy NywgMjAxNyAxMTo1MyBBTQ0KVG86IE1VTlRFQU5VIE1paGFpLUFkcmlhbjsgb3BlbmxkYXAtaXRz QE9wZW5MREFQLm9yZw0KU3ViamVjdDogUmU6IChJVFMjODc2MikgVW5sb2NraW5nIGFuIGFjY291 bnQgZG9lc24ndCByZW1vdmUgcHdkRmFpbHVyZVRpbWUNCg0KbWloYWkubXVudGVhbnVAdGhhbGVz Z3JvdXAuY29tIHdyb3RlOg0KPiBTY2VuYXJpbzogDQo+IDAuIHdlIGhhdmUgY29uZmlndXJlZCB0 aGF0IGFmdGVyIDMgbG9naW4gZmFpbGVkIGF0dGVtcHRzLCB0aGUgYWNjb3VudCANCj4gdG8gYmUg bG9ja2VkLg0KPiAxLiB1c2VyIHRlc3QxIGZhaWxzIHRvIGxvZ2luIDMgdGltZXMgLT4gYWNjb3Vu dCBpcyBsb2NrZWQNCg0KUGxlYXNlIHByb3ZpZGUgdGhlIHBhc3N3b3JkIHBvbGljeSBhcyBMRElG Lg0KDQo+IDIuIGFkbWluIHVubG9ja3MgdGVzdDEncyBhY2NvdW50IGFuZCBub3RpZnkgdGVzdDEg dXNlcg0KDQpXaGljaCBleGFjdCBMREFQIG9wZXJhdGlvbiBpcyBkb25lIHdoZW4gImFkbWluIHVu bG9ja3MgdGVzdDEncyBhY2NvdW50Ii4NCkFyZSB5b3UganVzdCByZW1vdmluZyAncHdkQWNjb3Vu dExvY2tlZFRpbWUnPw0KDQpJJ20gYXNraW5nIGJlY2F1c2UgdGhlcmUgbWlnaHQgYmUgYSBtaXN1 bmRlcnN0YW5kaW5nIGhvdyB0aGF0IGlzIHN1cHBvc2VkIHRvIHdvcmsuIEluIHRoaXMgY2FzZSBp dCdzIGFuIHVzYWdlIHF1ZXN0aW9uIGJldHRlciB0byBiZSBkaXNjdXNzZWQgb24gb3BlbmxkYXAt dGVjaG5pY2FsIG1haWxpbmcgbGlzdC4NCg0KQ2lhbywgTWljaGFlbC4NCg== --_002_D204E7513BE6154188ADA82EFFA18AC69B58B3FFFFTHSONEA01CMS0_ Content-Type: application/octet-stream; name="pwdPolicy.ldif" Content-Description: pwdPolicy.ldif Content-Disposition: attachment; filename="pwdPolicy.ldif"; size=1196; creation-date="Fri, 27 Oct 2017 12:49:45 GMT"; modification-date="Fri, 27 Oct 2017 12:50:00 GMT" Content-Transfer-Encoding: base64 IyBTZWFyY2ggc2NvcGU6IHN1Yg0KIyBTZWFyY2ggZmlsdGVyOiAob2JqZWN0Q2xhc3M9KikNCiMg VG90YWwgZW50cmllczogMQ0KIw0KIyBHZW5lcmF0ZWQgYnkgTERBUCBBY2NvdW50IE1hbmFnZXIN CihodHRwOi8vd3d3LmxkYXAtYWNjb3VudC1tYW5hZ2VyLm9yZykgb24gT2N0b2JlciAyNywgMjAx NyAxMDo0OCBhbSAjIFZlcnNpb246IDUuNQ0KDQp2ZXJzaW9uOiAxDQoNCiMgRW50cnkgMTogY249 cGFzc3dvcmREZWZhdWx0LG91PXBvbGljaWVzLGRjPXRoYWxlcyxkYz1jb20NCmRuOiBjbj1wYXNz d29yZERlZmF1bHQsb3U9cG9saWNpZXMsZGM9dGhhbGVzLGRjPWNvbQ0KY246IHBhc3N3b3JkRGVm YXVsdA0KY3JlYXRldGltZXN0YW1wOiAyMDE3MTAwNDEyNDAyOVoNCmNyZWF0b3JzbmFtZTogZGM9 TWFuYWdlcixkYz10aGFsZXMsZGM9Y29tDQplbnRyeWNzbjogMjAxNzEwMDQxMjQwMjkuNzk1OTY5 WiMwMDAwMDAjMDAwIzAwMDAwMA0KZW50cnlkbjogY249cGFzc3dvcmREZWZhdWx0LG91PXBvbGlj aWVzLGRjPXRoYWxlcyxkYz1jb20NCmVudHJ5dXVpZDogZjMwMzEyNjgtM2Q0Yy0xMDM3LTkxOTgt NDUzYzRiMDUyMjc2DQpoYXNzdWJvcmRpbmF0ZXM6IEZBTFNFDQptb2RpZmllcnNuYW1lOiBkYz1N YW5hZ2VyLGRjPXRoYWxlcyxkYz1jb20NCm1vZGlmeXRpbWVzdGFtcDogMjAxNzEwMDQxMjQwMjla DQpvYmplY3RjbGFzczogdG9wDQpvYmplY3RjbGFzczogZGV2aWNlDQpvYmplY3RjbGFzczogcHdk UG9saWN5DQpvYmplY3RjbGFzczogcHdkUG9saWN5Q2hlY2tlcg0KcHdkYWxsb3d1c2VyY2hhbmdl OiBUUlVFDQpwd2RhdHRyaWJ1dGU6IHVzZXJQYXNzd29yZA0KcHdkY2hlY2ttb2R1bGU6IGNoZWNr X3Bhc3N3b3JkLnNvDQpwd2RjaGVja3F1YWxpdHk6IDINCnB3ZGV4cGlyZXdhcm5pbmc6IDANCnB3 ZGZhaWx1cmVjb3VudGludGVydmFsOiAwDQpwd2RncmFjZWF1dGhubGltaXQ6IDANCnB3ZGluaGlz dG9yeTogNA0KcHdkbG9ja291dDogVFJVRQ0KcHdkbG9ja291dGR1cmF0aW9uOiAwDQpwd2RtYXhh Z2U6IDc3NzYwMDANCnB3ZG1heGZhaWx1cmU6IDMNCnB3ZG1pbmFnZTogMA0KcHdkbWlubGVuZ3Ro OiA4DQpwd2RtdXN0Y2hhbmdlOiBGQUxTRQ0KcHdkc2FmZW1vZGlmeTogRkFMU0UNCnN0cnVjdHVy YWxvYmplY3RjbGFzczogZGV2aWNlDQpzdWJzY2hlbWFzdWJlbnRyeTogY249U3Vic2NoZW1hDQo= --_002_D204E7513BE6154188ADA82EFFA18AC69B58B3FFFFTHSONEA01CMS0_--

1 0

RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by jckidder＠aep.com 27 Oct '17

27 Oct '17

This is not a bug. pwdFailureTime is only cleared after the first successful bind. If you're = manually unlocking the user's account it can be assumed that you've gone th= rough the exercise of ensuring the user is using the proper password. Perh= aps by setting a new temporary password? If you haven't gone through that = exercise 1 attempt vs multiple attempts is not going to matter. The user i= s going to lock their account again anyway. We've just recently deployed a password self-service tool and have accounte= d for this current behavior in our help desk procedures. Our cyber securit= y team loves this behavior. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: openldap-bugs [mailto:openldap-bugs-bounces@openldap.org] On Behalf O= f mihai.munteanu(a)thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its(a)OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailu= reTime This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attac= hments. If suspicious please forward to incidents(a)aep.com for review. ********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.openldap.org_= incoming_&d=3DDwIBAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&= m=3D3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=3DfE28OfhKUqMQkynWWNTkl9-= sUN8henbPip3IgOunodI&e=3D=20 Submission from: (NULL) (86.12.190.162) Scenario:=20 0. we have configured that after 3 login failed attempts, the account to be locked. 1. user test1 fails to login 3 times -> account is locked 2. admin unlocks test1's account and notify test1 user 3. user test1 tries 1 time to login using a wrong password and gets his acc= ount locked again. Expectation here: account should not be locked after first attempt of a wro= ng password, but after third attempt, as it was the case on step 1.=20 It turns out that it is locked again after first attempt due to the fact th= at on step 2, only pwdAccountLockedTime field is removed from LDAP, but not also pwdFailureTime fields. It seems pwdFailureTime is internally cleared only: - when test1 successfully authenticate (having his account unlocked) - admin changes test1's password See below my details: $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=3Dadmin,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f unloc= k.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=3Djamessmith,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f = unlock.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... Result: pwdAccountLockedTime is removed but pwdFailureTime is not automatic= ally removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to = be automatically removed via removal of pwdAccountLockedTime.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs