- openldap-bugs - openldap.org

(ITS#6717) patch for syncprov unnecessary presentation issue
by cmikk＠qwest.net 15 Dec '10

15 Dec '10

The following patch against servers/slapd/overlays/syncprov.c version 1.320 appears to fix the issue detailed in ITS#6717, and does not appear to break any of the basic sync functionality. --- syncprov.c.1.320 2010-12-15 19:55:32.000000000 +0000 +++ syncprov.c 2010-12-15 22:13:48.000000000 +0000 @@ -2409,7 +2409,7 @@ sync_control *srs; BerVarray ctxcsn; int i, *sids, numcsns; - struct berval mincsn; + struct berval mincsn, maxcsn; int dirty = 0; if ( !(op->o_sync_mode & SLAP_SYNC_REFRESH) ) return SLAP_CB_CONTINUE; @@ -2524,12 +2524,25 @@ i++; } - /* Find the smallest CSN */ - mincsn = srs->sr_state.ctxcsn[0]; - for ( i=1; i<srs->sr_state.numcsns; i++ ) { - if ( ber_bvcmp( &mincsn, &srs->sr_state.ctxcsn[i] ) > 0 ) - mincsn = srs->sr_state.ctxcsn[i]; + /* Find the smallest CSN which differs between cookie + * and contextCSN. + */ + mincsn.bv_len = 0; + maxcsn.bv_len = 0; + for ( i=0; i<srs->sr_state.numcsns; i++) { + for (j=0; j<numcsns; j++) { + if ( srs->sr_state.sids[i] != sids[j] ) continue; + if (BER_BVISNULL(&maxcsn) || ber_bvcmp( &maxcsn, &srs->sr_state.ctxcsn[i] ) < 0 ) { + maxcsn = srs->sr_state.ctxcsn[i]; + } + if (ber_bvcmp( &srs->sr_state.ctxcsn[i], &ctxcsn[j] ) < 0) { + if (BER_BVISNULL(&mincsn) || ber_bvcmp( &mincsn, &srs->sr_state.ctxcsn[i] ) > 0 ) { + mincsn = srs->sr_state.ctxcsn[i]; + } + } + } } + if (BER_BVISNULL(&mincsn)) mincsn = maxcsn; /* If nothing has changed, shortcut it */ if ( srs->sr_state.numcsns == numcsns ) {

1 0

(ITS#6749) Shut up "configure monitor database to enable"
by h.b.furuseth＠usit.uio.no 15 Dec '10

15 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Please don't give the "configure monitor database to enable" message by default. Either just remove it, or better, stop cn=config from adding a default olcMonitoring: TRUE attribute to olcDatabase objects. (The flag value can still default to True if the attribute is absent.) Then you can give the message if the _admin_ has explicitly asked for monitoring, instead of if slapd has asked for it.

1 0

Re: (ITS#6747) LDAP_CONNECTIONLESS nitpicks
by Kurt＠OpenLDAP.org 14 Dec '10

14 Dec '10

My nitpick regarding this feature is that it still exists. :-) -- Kurt On Dec 14, 2010, at 6:04 AM, h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Bug: > slapd/daemon.c outputs a berval instead of berval.bv_val. > > Compiler warnings: > slapd/connection.c needs lber-int.h for ber_int_sb_read(). > libldap/<abandon.c, search.c> pass a struct sockaddr* to a char*. > > Fixing.

1 0

Re: (ITS#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by ralf＠OpenLDAP.org 14 Dec '10

14 Dec '10

Hi, Am Dienstag 14 Dezember 2010, 12:15:04 schrieb De Bonis Hamelin, Marie Antoinette (Marian - CMS): > Hi, > > Could you please confirm/share us, modifications like moving from > strcpy() to memcpy() were done also for the bdb back-end? If yes, > could you also give us in which release fixes were committed? As mentioned in a previous comment in this ITS the fix is in r1.169 of back-bdb/dn2id.c. Back-bdb didn't need a separate fix as this issue was back-hdb specific. Otherwise it would most probably not need an extra fix as well as back-bdb and back-hdb share most of their code. -- regards, Ralf

1 0

(ITS#6748) slapo-memberof can log scrambled error text
by h.b.furuseth＠usit.uio.no 14 Dec '10

14 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard memberof_value_modify() calls op->o_bd->be_modify( &op2, &rs2 ); and then uses rs2.sr_text, which can be a value on be_modify's stack. Fixing by deleting 'text=...' from the error message.

1 0

(ITS#6747) LDAP_CONNECTIONLESS nitpicks
by h.b.furuseth＠usit.uio.no 14 Dec '10

14 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Bug: slapd/daemon.c outputs a berval instead of berval.bv_val. Compiler warnings: slapd/connection.c needs lber-int.h for ber_int_sb_read(). libldap/<abandon.c, search.c> pass a struct sockaddr* to a char*. Fixing.

1 0

Re: (ITS#6746) broken slapo-translucent failure handling
by h.b.furuseth＠usit.uio.no 14 Dec '10

14 Dec '10

I've fixed it in HEAD, unless early errors in translucent_search() should be ignored or filter errors should NOT be ignored. -- Hallvard

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 13 Dec '10

13 Dec '10

Could we have this overlay in contrib/ shipped with 2.4.24? That would be really nice. I've tested it with 2.4.23 and it still seems to work.

1 0

Re: (ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by rmeggins＠redhat.com 13 Dec '10

13 Dec '10

On 12/10/2010 09:03 PM, Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> I "rebased" the patch on top of a recent change: >> revision 1.24 >> date: 2010/12/06 10:31:59; author: hallvard; state: Exp; lines: +5 >> -17 >> ITS#6625 Remove some LDAP_R_COMPILEs > > I didn't quite understand the point of the discussion of SSLv2 clients > in the comments on this patch, but committed it anyway. Thanks. I usually defer to Bob Relyea - he insists this is secure, and will not use SSLv2 if it is explicitly disabled (which it is in the OpenLDAP implementation). > > I would hope that nobody is still using SSLv2 these days. Also if a > StartTLS request fails, then the rest of the code in tlsm.c should > never even be reached; the TLS sockbuf layer wouldn't be installed. In my testing, openldap server was calling the tls session_accept function after the client failed to start tls. Because the failure was on the client side (e.g. a bogus CA cert), the server left the connection flagged with c_needs_tls_accept, and called ldap_pvt_tls_accept() on the next read. I've confirmed this using both openldap 2.4 with openssl and with moznss. openssl also checks for sslv2 incoming connections, but handles error cases better (e.g. it looks for http connections), including the case where the header bytes don't match a known sslv2, v3, or tls handshake. See ssl23_get_client_hello() for more information. > >> The new patch is here: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… >> >> >> This patch file is derived from OpenLDAP Software. All of the >> modifications to OpenLDAP Software represented in the following >> patch(es) were developed by Red Hat. Red Hat has not assigned rights >> and/or interest in this work to any party. I, Rich Megginson am >> authorized by Red Hat, my employer, to release this work under the >> following terms. >> >> Red Hat hereby place the following modifications to OpenLDAP Software >> (and only these modifications) into the public domain. Hence, these >> modifications may be freely used and/or redistributed for any purpose >> with or without attribution and/or other notice. >> >> >> >> > >

1 0

Re: (ITS#6746) broken slapo-translucent failure handling
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

I wrote: > translucent_search() can return LDAP_COMPARE_FALSE from test_filter(). ...and other error codes too. Should it ignore all other result codes from test_filter() than LDAP_COMPARE_TRUE? -- Hallvard

1 0

(ITS#6746) broken slapo-translucent failure handling
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard translucent_search() can return LDAP_COMPARE_FALSE from test_filter(). Should presumably be LDAP_SUCCESS. It should probably either ignore rc from overlay_op_walk() or not. Currently it ignores rc only if there are entries in tc.list. It doesn't seem to free the remaining entries in tc.list after send_search_entry() failure.

1 0

(ITS#6745) HEAD emfile race condition -> slapd stopping listening?
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard In HEAD slapd/daemon.c, thanks to HEAD's multiple listener support: slap_listener() protects emfile with slap_daemon[0 ].sd_mutex, but slapd_remove() protects it with slap_daemon[id].sd_mutex. Maybe to compensate, slapd_remove() has code which checks if emfile is too big, but nothing checks if it is too small - which looks like slapd might never start listening again. Simplest fix: add this to slapd_remove(): if (id) ldap_pvt_thread_mutex_<lock,unlock>( &slap_daemon[0].sd_mutex ); slap_daemon[0].sd_mutex looks quite contended that way, though. Maybe a separate emfile_mutex is better.

1 0

Re: (ITS#6476) Failure to delete entry with multi-master replication
by piotr.tarnowski＠us.edu.pl 13 Dec '10

13 Dec '10

Hi! We have observed similiar symptoms with OpenLDAP 2.4.23: 2010-12-10T14:56:45+01:00 ldapst2/192.168.10.48 slapd[29363]: [ID 502419 local4.debug] Entry uid=Replicator,dc=us,dc=edu,dc=pl CSN 2 0101208130342.415481Z#000000#008#000000 older or equal to ctx 20101208130342.415481Z#000000#008#000000 2010-12-10T14:56:45+01:00 ldapst2/192.168.10.48 slapd[29363]: [ID 653192 local4.debug] syncprov_search_response: cookie=rid=008,sid= 008,csn=20101202144622.962136Z#000000#007#000000;20101001125631.576652Z#000000#003#000000;20101210135344.096897Z#000000#008#000000 do you have any fixes? Regards -- [ Piotr Tarnowski piotr.tarnowski(a)us.edu.pl ] [ Unix Administrator, University of Silesia, Katowice, Poland ]

1 0

Re: (ITS#6731) Scrambled error strings from back-ldif
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

Howard Chu writes: > It is not an error in ldif_back_add() since rs->sr_text is only used by > send_ldap_result(). Its value upon return from ldif_back_add is irrelevant. Should have been true but isn't - a number of modules reuse SlapReply variables without clearing them:-( -- Hallvard

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

I suppose it could be old misnamed ITS#5340. If so, try http://folk.uio.no/hbf/OpenLDAP/slapreply-draft3.diff Compile with CPPFLAGS="-DRS_USE_ASSERT=0". If that helps, the patch needs to work without the CPPFLAGS, but the asserts may be overeager. -- Hallvard

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by rein＠OpenLDAP.org 12 Dec '10

12 Dec '10

On 11/19/10 23:55 , cmikk(a)qwest.net wrote: > will evaluate to true in cases where it should not. A quick fix would be to > compare directly against the CSN of the sessionlog's head: An extended version of this fix, which also ensures that the sessionlog is kept in csn order, is now in head. Please test, syncprov.c revision 1.320. Rein

1 0

Re: (ITS#6744) memory leak when chasing referrals
by arthur＠arthurdejong.org 11 Dec '10

11 Dec '10

--=-dGqU1ahV0Ya5KsADLt/0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2010-12-10 at 19:52 -0800, Howard Chu wrote: > Thanks, reproduced using ldapsearch. Fixed in HEAD. Thanks for the quick response and fix! --=20 -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org -- --=-dGqU1ahV0Ya5KsADLt/0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJNA/gRAAoJECqLdGgQ4K/B3hQP+wbUpmAAws3D7aobKrff+lm1 fe6Bl2kSh/xr7YJptDHQsQf0u7ZfuWPBY7Jm/VYR6vjBqfn2do2J4yZL2yKbkKJS Js9ir23JBgg5hv/qi9c64uA85GTU0NPex7PcWP45y5Y95ZBtDsdGBzvuoePwGCvn Wkb3dNY1Cl6MDL77CZPyoy1qKRHWcWPfVONhbLkQ5LF2BuDPV1dXjFSV1mqRTbLr JXqn1QKYrdRhHhIkZsdXs8RmdtWZ+43lZyqpF2jGtLR3iP8e55kPluih35Mp/fWM 1L/dVYjQO8sV54b1UPGJKAIDHoqacXhRgCZgRTJxQZy3GJ8eKmuM7G4O71TpYuX5 AoxXDcuSOuBY7qDFfTUkICujNDWHXQ0C4/nzN6owyPc5TneXGeJYMgzmyctZb5et jhLwAuS2kwDGNL46XxyuGSF+cDSEeEFxpewo61cXFB/gp2+469MCWfoyWtyp/LHV MZwpTAz9B0FvDjPMOMqd91h4O1WZIxBBo61FnL2iPWD/pNHrmQXlTTQ/y/WMHIXg bWkjqbnT8Qi1PpFYgvo2u+6oe1U4tV6aNRwioQjVyVi8lK+tyC9EL+tJfAGq5f7H JqOZj37PJ5qd26DUU6q2vX7r7RO7wX8TraP0/Kafvg2FnVk+9G+1LSdmjwzviPBp 32EBHtl1GZlq7rP4Q+zm =74Se -----END PGP SIGNATURE----- --=-dGqU1ahV0Ya5KsADLt/0--

1 0

Re: (ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by hyc＠symas.com 10 Dec '10

10 Dec '10

rmeggins(a)redhat.com wrote: > I "rebased" the patch on top of a recent change: > revision 1.24 > date: 2010/12/06 10:31:59; author: hallvard; state: Exp; lines: +5 -17 > ITS#6625 Remove some LDAP_R_COMPILEs I didn't quite understand the point of the discussion of SSLv2 clients in the comments on this patch, but committed it anyway. I would hope that nobody is still using SSLv2 these days. Also if a StartTLS request fails, then the rest of the code in tlsm.c should never even be reached; the TLS sockbuf layer wouldn't be installed. > The new patch is here: > ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… > > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6744) memory leak when chasing referrals
by hyc＠symas.com 10 Dec '10

10 Dec '10

arthur(a)arthurdejong.org wrote: > Full_Name: Arthur de Jong > Version: 2.4.23 > OS: Debian > URL: > Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) > > > There seems to be a memory leak in the LDAP client library when casing > referrals. When the code below is run through valgrind it reports: > > ==30395== 4,184 (80 direct, 4,104 indirect) bytes in 1 blocks are definitely > lost in loss record 3 of 3 > ==30395== at 0x402328F: calloc (vg_replace_malloc.c:467) > ==30395== by 0x41D2CDF: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.6) > ==30395== by 0x40650A0: ldap_send_server_request (in > /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x4065EB1: ldap_chase_v3referrals (in > /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x40510A3: ldap_result (in /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x8048871: main (test.c:28) > > The code below is not very pretty (does not include error handling) but should > free all returned buffers. I can also reproduce the above leak with the > ldapsearch command-line tool. Thanks, reproduced using ldapsearch. Fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 5:16 PM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' >> DESC 'last successful authentication using any method/mech' >> EQUALITY generalizedTimeMatch >> ORDERING generalizedTimeOrderingMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 >> SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) >>=20 >> And we use this attribute in our configuration object to = enable/disable =3D >> (default disabled). >>=20 >> ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' >> DESC 'enable recording of last successful authentication using =3D= >> any method/mech' >> EQUALITY booleanMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 >> SINGLE-VALUE USAGE dsaOperation ) >=20 > Hmm, isn't NAME of the second a little bit confusing since it sounds = like just > the plural of the first? Names should only be for the wire, the wire doesn't get confused. -- Kurt=

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 10 Dec '10

10 Dec '10

Kurt(a)OpenLDAP.org wrote: > ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' > DESC 'last successful authentication using any method/mech' > EQUALITY generalizedTimeMatch > ORDERING generalizedTimeOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 > SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) > > And we use this attribute in our configuration object to enable/disable = > (default disabled). > > ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' > DESC 'enable recording of last successful authentication using = > any method/mech' > EQUALITY booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 > SINGLE-VALUE USAGE dsaOperation ) Hmm, isn't NAME of the second a little bit confusing since it sounds like just the plural of the first? Ciao, Michael.

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 12:02 PM, Howard Chu wrote: > Good point. In that case it's probably fine as a separate overlay, the = way it is now. Can we use the schema definition that Isode is using? Not only yes, but hell yes. Reuse and convergence is a good thing. ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' DESC 'last successful authentication using any method/mech' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) And we use this attribute in our configuration object to enable/disable = (default disabled). ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' DESC 'enable recording of last successful authentication using = any method/mech' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE dsaOperation )

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by hyc＠symas.com 10 Dec '10

10 Dec '10

Kurt(a)OpenLDAP.org wrote: > On Dec 10, 2010, at 10:37 AM, jonathan(a)phillipoux.net wrote: > >> On 10/12/10 17:14, Howard Chu wrote: >>> jonathan(a)phillipoux.net wrote: >>>> On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >>>>> Full_Name: Jonathan Clarke >>>>> Version: RE24 >>>>> OS: >>>>> URL: >>>>> = > ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >>>>> Submission from: (NULL) (82.67.204.30) >>>>> =20 >>>>> =20 >>>>> Hi, >>>>> =20 >>>>> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, = > that >>>>> intercepts successful binds and records the current timestamp in an >>>>> attribute >>>>> named "bindTimestamp" in the bound-to entry. It's original use-case >>>>> is to detect >>>>> unused accounts. >>>>> =20 >>>>> A configuration parameter (olcLastBindPrecision) allows to set a = > minimum >>>>> precision for the timestamp (ie, don't update the timestamp unless >>>>> it's older >>>>> than<n> seconds). This avoids a performance hit from many >>>>> unnecessary writes in >>>>> case there are many binds per minute/hour/day/week/etc. >>>>> =20 >>>>> Of course, the behaviour this overlay implements is not described = > in >>>>> any RFC, or >>>>> other. However, it closely resembles some of the functionality from >>>>> the password >>>>> policy overlay, and similar functionality already exists in other >>>>> LDAP servers. >>> =20 >>> There is an equivalent attribute defined in the latest ppolicy draft. >>> Perhaps you could use that. > > That attribute is last successful password authentication, not last = > authentication by any means. > > For the latter, I suggest a separate attribute. At Isode, we use an = > authTimestamp dsaOperational attribute for this. > > It's wise to have the updating of this attribute off by default. Good point. In that case it's probably fine as a separate overlay, the way it is now. Can we use the schema definition that Isode is using? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 10:37 AM, jonathan(a)phillipoux.net wrote: > On 10/12/10 17:14, Howard Chu wrote: >> jonathan(a)phillipoux.net wrote: >>> On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >>>> Full_Name: Jonathan Clarke >>>> Version: RE24 >>>> OS: >>>> URL: >>>> = ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >>>> Submission from: (NULL) (82.67.204.30) >>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, = that >>>> intercepts successful binds and records the current timestamp in an >>>> attribute >>>> named "bindTimestamp" in the bound-to entry. It's original use-case >>>> is to detect >>>> unused accounts. >>>>=20 >>>> A configuration parameter (olcLastBindPrecision) allows to set a = minimum >>>> precision for the timestamp (ie, don't update the timestamp unless >>>> it's older >>>> than<n> seconds). This avoids a performance hit from many >>>> unnecessary writes in >>>> case there are many binds per minute/hour/day/week/etc. >>>>=20 >>>> Of course, the behaviour this overlay implements is not described = in >>>> any RFC, or >>>> other. However, it closely resembles some of the functionality from >>>> the password >>>> policy overlay, and similar functionality already exists in other >>>> LDAP servers. >>=20 >> There is an equivalent attribute defined in the latest ppolicy draft. >> Perhaps you could use that. That attribute is last successful password authentication, not last = authentication by any means. For the latter, I suggest a separate attribute. At Isode, we use an = authTimestamp dsaOperational attribute for this. It's wise to have the updating of this attribute off by default. >> Or just submit a patch to incorporate this >> feature into the current ppoloicy overlay. >=20 > Indeed. At the time I wrote this overlay, I think the ppolicy draft = was > not yet finished or at least I wasn't aware of it. My client at the = time > found it useful to just add this simple overlay, without worrying = about > configuring ppolicy. >=20 > Since then, I actually haven't had any time to work on this overlay, = but > today Michael expressed an interest in it, asking for a public IPR > notice, thus the "thread revival". >=20 > I hope to pick it up in the future, and at that point possibly submit = a > patch for ppolicy also, as you suggest. >=20 > Regards, > Jonathan >=20 >=20

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 10 Dec '10

10 Dec '10

On 10/12/10 17:14, Howard Chu wrote: > jonathan(a)phillipoux.net wrote: >> On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >>> Full_Name: Jonathan Clarke >>> Version: RE24 >>> OS: >>> URL: >>> ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >>> Submission from: (NULL) (82.67.204.30) >>> >>> >>> Hi, >>> >>> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that >>> intercepts successful binds and records the current timestamp in an >>> attribute >>> named "bindTimestamp" in the bound-to entry. It's original use-case >>> is to detect >>> unused accounts. >>> >>> A configuration parameter (olcLastBindPrecision) allows to set a minimum >>> precision for the timestamp (ie, don't update the timestamp unless >>> it's older >>> than<n> seconds). This avoids a performance hit from many >>> unnecessary writes in >>> case there are many binds per minute/hour/day/week/etc. >>> >>> Of course, the behaviour this overlay implements is not described in >>> any RFC, or >>> other. However, it closely resembles some of the functionality from >>> the password >>> policy overlay, and similar functionality already exists in other >>> LDAP servers. > > There is an equivalent attribute defined in the latest ppolicy draft. > Perhaps you could use that. Or just submit a patch to incorporate this > feature into the current ppoloicy overlay. Indeed. At the time I wrote this overlay, I think the ppolicy draft was not yet finished or at least I wasn't aware of it. My client at the time found it useful to just add this simple overlay, without worrying about configuring ppolicy. Since then, I actually haven't had any time to work on this overlay, but today Michael expressed an interest in it, asking for a public IPR notice, thus the "thread revival". I hope to pick it up in the future, and at that point possibly submit a patch for ppolicy also, as you suggest. Regards, Jonathan

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs