- openldap-bugs - openldap.org

Re: (ITS#9079 documentation: slapo-unique syntax explanation unclear
by quanah＠symas.com 13 Sep '19

13 Sep '19

--On Friday, September 13, 2019 6:07 PM +0000 gray(a)nxg.name wrote: > Full_Name: Norman Gray > Version: 2.4.48 > OS: FreeBSD 12.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.209.45.140) Note: this is now ITS#9079. --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#9078) Indices MDB
by quanah＠symas.com 13 Sep '19

13 Sep '19

--On Friday, September 13, 2019 5:54 PM +0000 dpa-openldap(a)aegee.org wrote: Hello, The ITS system is for bug reports, not usage questions. Please redirect your questions to the openldap-technical(a)openldap.org mailing list. This ITS will be closed. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> --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#9077) slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
by quanah＠symas.com 13 Sep '19

13 Sep '19

--On Friday, September 13, 2019 4:34 PM +0000 gray(a)nxg.name wrote: > Full_Name: Norman Gray > Version: 2.4.48 > OS: FreeBSD 12.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.209.45.140) Unrelated side note, ITS number fixed to be 9077. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9488) documentation: slapo-unique syntax explanation unclear
by gray＠nxg.name 13 Sep '19

13 Sep '19

Full_Name: Norman Gray Version: 2.4.48 OS: FreeBSD 12.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.209.45.140) Documentation bug The documentation for the `unique_uri` or `olcUniqueURI` attribute is very compact, with the result that it is not clear what counts as correct syntax, nor what are the semantics of the specification. I'm not suggesting that the text is necessarily _inaccurate_, but that it is too brief. That is, someone who already understand the syntax and semantics will probably not notice anything wrong with this paragraph; someone who doesn't already understand (eg, me) will struggle. slapo-unique(5) says that the syntax here is: unique_uri <[strict ][ignore ]URI[URI...]...> Configure the base, attributes, scope, and filter for uniqueness checking. Multiple URIs may be specified within a domain, allowing complex selections of objects. Multiple unique_uri statements or olcUniqueURI attributes will create independent domains, each with their own independent lists of URIs and ignore/strict settings. Keywords strict and ignore have to be enclosed in quotes (") together with the URI. The LDAP URI syntax is a subset of RFC-4516, and takes the form: ldap:///[base dn]?[attributes...]?scope[?filter] I understand from this text the following: * One can specify multiple URIs in the value of a olcUniqueURI attribute. I _guess_ these can be space-separated, even though that isn't shown in this syntax. * Each URI defines a set of object attributes * One can have multiple olcUniqueURI attributes, _each of which_ creates a 'domain' * This doesn't say what a 'domain' is, but I _guess_ that it means that all of the attributes which match the search are forced, by this overlay, to be unique, but that there are no mutual uniqueness requirements between separate olcUniqueURI/'domain' specifications * If multiple URIs are specified in a 'domain', or olcUniqueURI attribute, then (wild guess) the union of the attributes matched by each URI is unique; I doubt it means the intersection of the result sets (I guess that because that's the only thing that sounds sensible; the phrase 'complex selections of objects' doesn't clarify) * It's not clear where the quotes go, when combining with 'strict' or 'ignore' (I guess "strict ldap://..."). * Can 'strict' or 'ignore' be combined with the second or subsequent URIs? The syntax suggests not. I don't think the above understanding is correct, because when I specify a olcUniqueURI attribute with multiple URIs, I get an error (see ITS#9486 and thread <https://www.openldap.org/lists/openldap-technical/201909/msg00031.html>). At any rate, I have little confidence that I have interpreted the text correctly, and the above is the result of several careful readings and some guesswork. If the above, or something like it, is roughly correct, I could draft an alternative paragraph, if that would be useful. If the manpage included more than one example, that would be _extremely_ useful. I'll mention in passing that in servers/slapd/overlays/unique.c, the comment above `unique_new_domain` says instead * domain_specs look like * * [strict ][ignore ]uri[[ uri]...] * e.g. "ldap:///ou=foo,o=bar?uid?sub ldap:///ou=baz,o=bar?uid?sub" * "strict ldap:///ou=accounts,o=bar?uid,uidNumber?one" * etc

1 0

(ITS#9487) Indices MDB
by dpa-openldap＠aegee.org 13 Sep '19

13 Sep '19

Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.118.146.153) How can I write to a ticket here, after I submit it? https://www.openldap.org/software/man.cgi?query=slapd-mdb&apropos=0&sektion… (man slapd-mdb) is not clear about indices. Is olcDbIndex A eq olcDbIndex B eq the same as olcDbIndex A,B eq and is the latter the same as oldDbIndex B,A eq ? In the SQL word these are different things and while Postgresql is supposed to handle "index A,B" and "index B.A" as equivalent, it does not, so a query has to be tuned to make use of existing indices. The particular use-case is the LDAP backend of MIT Kerberos and the indices it needs for this query, as discussed at https://github.com/krb5/krb5/pull/974#issuecomment-531167854. The debug output of OpenLDAP is: Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SRCH base="cn=X.NET,cn=krbContainer" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=krbtgt/X.NET(a)X.NET))" Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewable age krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbPrincipalAuthInd krbExtraData krbObjectReferences krbAllowedToDelegateTo krbPwdHistory Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf <= mdb_equality_candidates: (objectClass) not indexed Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SEARCH RESULT tag=101 err=0 nentries=1 text= Does it need one index on objectClass, one index on krbPrincipal, or one index on "first objectClass, then krbPrincipal"? If no mdb_candidate output can be triggered, does it mean, that creating an index is pointless? Moreover, it is not clear when changing the oldDbIndex on a database regenerates the index, and when running slapindex is necessary.

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 13 Sep '19

13 Sep '19

On Mon, Sep 09, 2019 at 04:01:59PM +0200, Ond??ej Kuzn??k wrote: > I mean the ber_str2bv(,,1,) in both new functions. Not sure which code > you think would overwrite parts of the buffer? ber_str2bv(,,0,) never > touches it, manually initialising the berval certainly wouldn't either. > And then you have fewer memory regions to scrub. > > Since you already know the length, you can also pass it in so ber_str2bv > can skip its strlen() check (and since anything can be in a {PLAINTEXT} > password, you're now embedded NUL safe). Ah, OK, I didn't realize that would be NUL safe. I made an updated patch with that change[1]. > I think I mentioned this before as something worth changing: rather > than call time(0L), you can use op->o_time which is stable and the > closest you can get to the time the operation was received. Yes, sorry I did see that before just forgot to do it. It's also included in the latest update[1]. > BTW, scinet.supercomputing.org's HTTPS cert is signed by Let's Encrypt > Authority X3 as an intermediate, but isn't sending it during the > handshake, so wget/curl aren't happy trusting it (I think browsers cache > it or already have a copy). Thank you, this has been corrected. [1] https://scinet.supercomputing.org/~gv/slapd-totp-v5.txt -- Greg Veldman

1 0

(ITS#9486) slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
by gray＠nxg.name 13 Sep '19

13 Sep '19

Full_Name: Norman Gray Version: 2.4.48 OS: FreeBSD 12.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.209.45.140) A plausible-looking spec in olcUniqueURI causes slapadd to spin its wheels indefinitely. I want to specify something like: dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub If I do this, however, then slapadd spins its wheels when the `slapd.ldif` is loaded into an otherwise empty configuration (ie, this happens at configuration time, before any records/objects are loaded): $ rm -R /usr/local/etc/openldap/slapd.d/* $ su -m ldap -c "slapadd -d255 -n 0 -F /usr/local/etc/openldap/slapd.d -l /usr/local/etc/openldap/slapd.ldif" ... ... 5d77d377 >>> dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <<< dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config>, <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <= str2entry(olcOverlay=unique,olcDatabase={1}mdb,cn=config) -> 0x800d4eca8 5d77d377 oc_check_required entry (olcOverlay=unique,olcDatabase={1}mdb,cn=config), objectClass "olcUniqueConfig" 5d77d377 oc_check_allowed type "objectClass" 5d77d377 oc_check_allowed type "olcOverlay" 5d77d377 oc_check_allowed type "olcUniqueURI" 5d77d377 oc_check_allowed type "structuralObjectClass" 5d77d377 >>> dnNormalize: <olcOverlay={1}unique> 5d77d377 <<< dnNormalize: <olcOverlay={1}unique> 5d77d377 ==> unique_db_init 5d77d377 ==> unique_new_domain <ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub> 5d77d377 >>> dnPrettyNormal: <ou=dept-A,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-A,o=example>, <ou=dept-A,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> ... ^C and so on and on and on, apparently indefinitely. The idea is that the uidnumber attribute should be unique across the two OUs, ou=dept-A and ou=dept-B. Whether or not this is a valid spec is another issue; even if it's invalid, it shouldn't cause this behaviour; if the spec is invalid, it should produce a terminal error. Looking at the code in servers/slapd/overlays/unique.c, nothing leaps out as an obvious error (ie, I'm not claiming I have a fix for this). There was a brief thread about this on openldap-technical: <https://www.openldap.org/lists/openldap-technical/201909/msg00031.html> Configuration: # /usr/local/libexec/slapd -VVV @(#) $OpenLDAP: slapd 2.4.48 (Sep 10 2019 13:30:19) $ root@hermite.physics.gla.ac.uk:/var/ports/usr/ports/net/openldap24-server/work/openldap-2.4.48/servers/slapd Included static overlays: constraint syncprov unique Included static backends: config ldif relay # freebsd-version 12.0-RELEASE-p9 This is the most recent currently-packaged version of OpenLDAP on FreeBSD.

1 0

Re: (ITS#9023) crash using ppolicy chaining from slave to master
by ondra＠mistotebe.net 11 Sep '19

11 Sep '19

Hi Jean-Philippe, I have just seen and fixed a crash that might be similar to yours (ITS#9076), could you try and see if the crash goes away if you apply commit a14fb731ac6e39cd037512ca63bcb021f0196e5b? Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#9076) back-ldap tries to free the wrong controls
by ondra＠openldap.org 10 Sep '19

10 Sep '19

Full_Name: Ondrej Kuznik Version: re24/master OS: URL: Submission from: (NULL) (82.132.242.212) ldap_back_extended_one needs to play with op->o_ctrls since it doesn't just pass ctrls over like the other sites in back-ldap, but it never sets oldctrls as is should. If a control is ever added to the list, it will restore op->o_ctrls to the wrong value and crash. This happens e.g. in certain chaining scenarios with mode=legacy.

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by ondra＠mistotebe.net 09 Sep '19

09 Sep '19

On Thu, Sep 05, 2019 at 10:59:46AM -0400, Greg Veldman wrote: > On Thu, Sep 05, 2019 at 11:52:45AM +0200, Ond??ej Kuzn??k wrote: >> - could you split it in two patches, one to check the previous time step >> (+doc) and one to support the new schemes (+doc)? > > Working on it, will have updated patches up shortly... Thanks for the updated patches. >> - I don't think you need to allocate a copy of the passwd just come in, >> you can just frame it into separate bervals reusing the provided >> buffer so long as you keep in mind they are not NUL-terminated >> properly. > > Are you referring to the chk_totp_and_pw() function? If so, > since the expected format is <password><totp> with no seperator, > if I terminated the password part that would overwrite the first > char of totp, yes? That's the reason I make a copy and allocate > an extra byte for the NUL. I mean the ber_str2bv(,,1,) in both new functions. Not sure which code you think would overwrite parts of the buffer? ber_str2bv(,,0,) never touches it, manually initialising the berval certainly wouldn't either. And then you have fewer memory regions to scrub. Since you already know the length, you can also pass it in so ber_str2bv can skip its strlen() check (and since anything can be in a {PLAINTEXT} password, you're now embedded NUL safe). >> Just a style note, if there's an else coming, could you make sure both >> the if and the else blocks are in {}? > > Implemented, it will be included in the updated patches. I think I mentioned this before as something worth changing: rather than call time(0L), you can use op->o_time which is stable and the closest you can get to the time the operation was received. BTW, scinet.supercomputing.org's HTTPS cert is signed by Let's Encrypt Authority X3 as an intermediate, but isn't sending it during the handshake, so wget/curl aren't happy trusting it (I think browsers cache it or already have a copy). Thanks, -- 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#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 06 Sep '19

06 Sep '19

On Thu, Sep 05, 2019 at 10:59:46AM -0400, Greg Veldman wrote: > On Thu, Sep 05, 2019 at 11:52:45AM +0200, Ond??ej Kuzn??k wrote: > > - could you split it in two patches, one to check the previous time step > > (+doc) and one to support the new schemes (+doc)? > > Working on it, will have updated patches up shortly... Sorry that took a bit longer than I thought, got tied up with day job stuff yesterday afternoon. New patches are available that break out the two changes: https://scinet.supercomputing.org/~gv/slapd-totp-v4.txt https://scinet.supercomputing.org/~gv/slapd-totp-accept-previous-time-v1.txt -- Greg Veldman

1 0

Re: (ITS#9069) Stop setting custom GnuTLS mutex functions
by ryan＠nardis.ca 06 Sep '19

06 Sep '19

I know the locking gets exercised (both libldap and GnuTLS sides) during connection and TLS handshake, so I tested this by doing a bind/search/unbind loop on a bunch of parallel threads. I built master with this patch in all of the following environments: Debian 8 (jessie), GnuTLS 3.3.30 Debian 9 (stretch), GnuTLS 3.5.8 Debian 10 (buster), GnuTLS 3.6.7 Debian unstable (sid), GnuTLS 3.6.9 FreeBSD 12.0, GnuTLS 3.6.8 Solaris 11.4, GnuTLS 3.5.16, --with-threads=lwp Solaris 11.4, GnuTLS 3.5.16, --with-threads=posix Windows 10 (MinGW), GnuTLS 3.6.8, --with-threads=nt Windows 10 (MinGW), GnuTLS 3.6.8, --with-threads=posix and ran my test program successfully on all of them. On each of these I also stepped into the debugger and confirmed that the expected calls happened (gnutls_system_mutex_lock calling resp. pthread_mutex_lock or EnterCriticalSection, ldap_pvt_thread_mutex_lock calling the expected API, etc). Any further comments, or suggestions for additional tests I should run?

1 0

ITS#9075 published: SECURITY: Not able to view directory structure in 389 management Console
by openldap-its＠OpenLDAP.org 06 Sep '19

06 Sep '19

Private ITS#9075 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=9075

1 0

ITS#9074 published: SECURITY: Not able to view directory structure in 389 management Console
by openldap-its＠OpenLDAP.org 06 Sep '19

06 Sep '19

Private ITS#9074 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=9074

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 05 Sep '19

05 Sep '19

On Thu, Sep 05, 2019 at 11:52:45AM +0200, Ond??ej Kuzn??k wrote: > - could you split it in two patches, one to check the previous time step > (+doc) and one to support the new schemes (+doc)? Working on it, will have updated patches up shortly... > - I don't think you need to allocate a copy of the passwd just come in, > you can just frame it into separate bervals reusing the provided > buffer so long as you keep in mind they are not NUL-terminated > properly. Are you referring to the chk_totp_and_pw() function? If so, since the expected format is <password><totp> with no seperator, if I terminated the password part that would overwrite the first char of totp, yes? That's the reason I make a copy and allocate an extra byte for the NUL. > Just a style note, if there's an else coming, could you make sure both > the if and the else blocks are in {}? Implemented, it will be included in the updated patches. -- Greg Veldman

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by ondra＠mistotebe.net 05 Sep '19

05 Sep '19

On Wed, Jul 31, 2019 at 08:14:55PM +0000, gv(a)members.scinet.supercomputing.org wrote: > v3 of the patch is available, which includes hashing functions > and documents the expected input format when using those functions. > I don't have the updated module on any of my servers yet, but > running slappasswd from my build directory does seem to yield > the same results as the non-password versions: > > $ ../../../../servers/slapd/slappasswd -T passwd -o module-load=`pwd`/.libs/pw-totp.so -h "{TOTP1}" > New password: > Re-enter new password: > {TOTP1}GAYA==== > > $ ../../../../servers/slapd/slappasswd -T passwd -o module-load=`pwd`/.libs/pw-totp.so -h "{TOTP1ANDPW}" > New password: > Re-enter new password: > {TOTP1ANDPW}GAYA====|{SSHA}Qo6WiIWWsWohlwZSo9oQkImKvSNArGio > > This is using an OTP seed of 00 and a password of foo > > https://scinet.supercomputing.org/~gv/slapd-totp-v3.txt Hi Greg, looking at the code, I think I'd be ok with this functionality and nothing major comes up for me. I would like to see a few changes though: - could you split it in two patches, one to check the previous time step (+doc) and one to support the new schemes (+doc)? - I don't think you need to allocate a copy of the passwd just come in, you can just frame it into separate bervals reusing the provided buffer so long as you keep in mind they are not NUL-terminated properly. Just a style note, if there's an else coming, could you make sure both the if and the else blocks are in {}? Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

答复: (ITS#9072) openLdap client problem
by feng.wang＠iquantex.com 02 Sep '19

02 Sep '19

--_6DA7EF0F-7766-481F-9373-22F0846C9405_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Thank you for your reply! =C2=A0=C2=A0=C2=A0=C2=A0 This problem has been solved, not the openldap pro= blem, but the problem with the use of the sssd service. Of course, I will c= onsider your suggestion to upgrade to version 2.4.48. =E5=8F=91=E9=80=81=E8=87=AA Windows 10 =E7=89=88=E9=82=AE=E4=BB=B6=E5=BA=94= =E7=94=A8 =E5=8F=91=E4=BB=B6=E4=BA=BA: Quanah Gibson-Mount =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B48=E6=9C=8830=E6=97=A5 22= :07 =E6=94=B6=E4=BB=B6=E4=BA=BA: feng.wang(a)iquantex.com; openldap-its(a)OpenLDAP.= org =E4=B8=BB=E9=A2=98: Re: (ITS#9072) openLdap client problem --On Friday, August 30, 2019 7:14 AM +0000 feng.wang(a)iquantex.com wrote: > Thank you very much for getting support! > ???? In the production of openldap is the HA environment, other uses are > normal, only in the modification of the user to multiple groups (some > client new user information is updated, and some other host clients are > not updated). Please update to a current release of OpenLDAP, i.e, at least version=20 2.4.48 as numerous replication fixes have been made to the product since=20 that time. You were already told to upgrade in ITS#9053 as well. Please=20 stop filing ITSes until such a time as you have upgraded to a current=20 release. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --_6DA7EF0F-7766-481F-9373-22F0846C9405_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style></style></head><body lang=3DZH-CN link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1>Thank you for you= r reply!  &nbs= p;  This problem has been solved, not the openldap problem, but the pr= oblem with the use of the sssd service. Of course, I will consider your sug= gestion to upgrade to version 2.4.48.<o:p></o:p><o:p> </o:p>=E5=8F=91=E9=80=81=E8=87= =AA Windows 10 =E7=89=88<a hre= f=3D"https://go.microsoft.com/fwlink/?LinkId=3D550986"><= span lang=3DEN-US>=E9=82=AE=E4=BB=B6</a>=E5=BA=94=E7= =94=A8<o:p> </o:p><div style=3D'mso-element:= para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0c= m 0cm 0cm'>=E5=8F= =91=E4=BB=B6=E4=BA=BA: <a = href=3D"mailto:quanah@symas.com">Quanah Gibson-Mount</a> =E5= =8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B48=E6=9C=8830=E6=97=A5 22:07 =E6=94=B6= =E4=BB=B6=E4=BA=BA: <a hre= f=3D"mailto:feng.wang@iquantex.com">feng.wang(a)iquantex.com</a>; <a href=3D"= mailto:openldap-its@OpenLDAP.org">openldap-its(a)OpenLDAP.org</a> <= b>=E4=B8=BB=E9=A2=98: Re: = (ITS#9072) openLdap client problem</div><sp= an lang=3DEN-US style=3D'font-size:12.0pt;font-family:SimSun'><o:p> </= o:p><o:p> </o:p></s= pan><o:p> </o:p></p= >--On Friday, August 30, 2019 7:14 = AM +0000 feng.wang(a)iquantex.com wrote:<span= lang=3DEN-US><o:p> </o:p>> Thank you very much for getting support!> ???? In the production of openldap is = the HA environment, other uses are> normal, only in the modification of the user to multiple gro= ups (some> client new= user information is updated, and some other host clients are> not updated).<o:p> </o:p>Please update to a current release of OpenLDAP, i.= e, at least version 2.4.= 48 as numerous replication fixes have been made to the product since </span= >that time.=C2=A0 You were alre= ady told to upgrade in ITS#9053 as well.=C2=A0 Please stop filing ITSes until such a time as you = have upgraded to a current release.<o:p> </= o:p>Regards,<= p class=3DMsoNormal>Quanah<o:p> </o:p><span= lang=3DEN-US><o:p> </o:p>--<o:p> </= o:p>Quanah Gibson-Mount<= /span>Product Architect<= /p>Symas CorporationPackaged, certified, and supported LDAP= solutions powered by OpenLDAP:<http://www.symas.com><o:p> </o:p></div></body></html>= --_6DA7EF0F-7766-481F-9373-22F0846C9405_--

1 0

Re: (ITS#8383) msys build error "portable.h:1116:19: error: two or more data types in declaration specifiers"
by ryan＠nardis.ca 01 Sep '19

01 Sep '19

I've run into this myself while trying to test ITS#9069 on Windows. In my MinGW environment, <sys/socket.h> does not define socklen_t, so portable.h:1116 does '#define socklen_t int'. However, <ac/socket.h> includes <ws2tcpip.h> which does typedef socklen_t. base64.c includes "portable.h" first and then <ac/socket.h> later. This second include triggers the error as the original typedef essentially becomes "typedef int int". I think we can fix it by searching the Windows header as well, avoiding the #define appearing in "portable.h". https://github.com/openldap/openldap/compare/openldap:master...rtandy:its83…

1 0

Re: (ITS#9073) md_cmp() called with zero size key
by juerg.bircher＠gmail.com 31 Aug '19

31 Aug '19

After having investigated more time on this issue and having changed = some parts of my code which could cause data corruption everything seems = to work fine. So most likely this issue can be closed.=

1 0

(ITS#9073) md_cmp() called with zero size key
by juerg.bircher＠gmail.com 31 Aug '19

31 Aug '19

Full_Name: Juerg Bircher Version: LMDB master OS: macOS / linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.75.150.99) I had the situation that my custom compare function was called with a MDB_val with zero size. I assume this should never happen as a key with zero length should not be valid? Unfortunately I do not have a simple case to reproduce it as it happens in large transaction with a lot of mdb_cursor_put() interleaved with mdb_cursor_get() calls. However it is reproducible. In mdb_cursor_set() at line mdb.c:6943 nodekey.mv_size is zero. rc = mc->mc_dbx->md_cmp(key, &nodekey); So the custom compare function is called with a value of zero length. A possible fix could be to surrond the code from line 6943 to 7007 with a check if (nodekey.mv_size > 0) { rc = mc->mc_dbx->md_cmp(key, &nodekey); if (rc == 0) { line 6943 to 7007 } I thank you in advance to inform me: a. if this fix is correct b. my assumption is wrong c. it needs another fix somewhere else

1 0

Re: (ITS#9072) openLdap client problem
by quanah＠symas.com 30 Aug '19

30 Aug '19

--On Friday, August 30, 2019 7:14 AM +0000 feng.wang(a)iquantex.com wrote: > Thank you very much for getting support! > ???? In the production of openldap is the HA environment, other uses are > normal, only in the modification of the user to multiple groups (some > client new user information is updated, and some other host clients are > not updated). Please update to a current release of OpenLDAP, i.e, at least version 2.4.48 as numerous replication fixes have been made to the product since that time. You were already told to upgrade in ITS#9053 as well. Please stop filing ITSes until such a time as you have upgraded to a current release. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#87) openLdap client problem
by feng.wang＠iquantex.com 30 Aug '19

30 Aug '19

Full_Name: wangfeng Version: 2.4.44 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (1.180.156.107) Thank you very much for getting support! In the production of openldap is the HA environment, other uses are normal, only in the modification of the user to multiple groups (some client new user information is updated, and some other host clients are not updated).

1 0

Re: (ITS#9070) Failing to include openssl1.1.1c with openLDAP
by quanah＠symas.com 29 Aug '19

29 Aug '19

--On Thursday, August 29, 2019 3:13 PM +0000 vishal.bafna307(a)gmail.com wrote: > I am trying to build openLDAP using openssl1.1.1c. > It is failing to locate the SSL/TLS package. > I have given the openssl lib and include paths in LDFLAGS and CPPFLAGS > respectively in the Makefile of LDAP. The Make file also has > --with-tls=openssl \ mentioned as config option The ITS system is for bug reports, not help requests on how to build the software. If you need help with building the software, please use the openldap-technical(a)openldap.org email list. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9071) Invalid olcDbStartTLS values generated on back-ldap conversion
by quanah＠openldap.org 29 Aug '19

29 Aug '19

Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) When converting this basic slapd.conf for back-ldap: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/ppolicy.schema include /usr/local/etc/openldap/schema/misc.schema loglevel 256 pidfile /var/run/slapd.pid argsfile /var/run/slapd.args modulepath /usr/local/libexec/openldap moduleload rwm moduleload back_ldap database ldap readonly yes protocol-version 3 rebind-as-user yes uri "ldaps://universe.example.com" suffix "dc=universe,dc=example,dc=com" overlay rwm rwm-map attribute uid sAMAccountName rwm-map attribute mail proxyAddresses chase-referrals yes idassert-bind bindmethod=simple binddn="cn=ldap_phone,ou=LDAP Access,dc=example,dc=com" credentials='Password1234' tls_cacert=/usr/local/etc/openldap/example_com_Universe_Root_CA.cer The resulting back-ldap configuration has an invalid olcDbStartTLS attribute: olcDbStartTLS: none starttls=no Per the man page, "none" is not valid at all, and also per the man page, since the URI is using ldaps, the value should be: olcDbStartTLS: ldaps Config is based off of a real life configuration from an end user, where things worked with slapd.conf but were broken post-conversion to cn=config. Fixing the olcDbStartTLS value to be valid resolved the issue.

1 0

(ITS#9070) Failing to include openssl1.1.1c with openLDAP
by vishal.bafna307＠gmail.com 29 Aug '19

29 Aug '19

Full_Name: Vishal Bafna Version: 2.4.42 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.204.193.36) I am trying to build openLDAP using openssl1.1.1c. It is failing to locate the SSL/TLS package. I have given the openssl lib and include paths in LDFLAGS and CPPFLAGS respectively in the Makefile of LDAP. The Make file also has --with-tls=openssl \ mentioned as config option snapshot of config option in the ldap Makefile CONFIG_OPTS= --host=$(TARGET) --prefix=${LINUX_ROOT} --exec_prefix=${LINUX_ROOT} --disable-static --enable-shared --with-yielding_select=no --disable-slapd --enable-syslog --disable-bdb --disable-hdb --enable-debug --with-tls=openssl --target=$(TARGET) LDFLAGS="-L${LINUX_ROOT}/lib -L$(LINUX_ROOT)/ssl/lib" CPPFLAGS="-I${LINUX_ROOT}/include -I$(LINUX_ROOT)/ssl/include" \ checking for SSL_library_init in -lssl... no checking for ssl3_accept in -lssl... no configure: error: Could not locate TLS/SSL package Makefile:27: recipe for target 'configure_arm-none-linux-gnueabi-2.4.42' failed Could someone please help with the issue

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs