- openldap-bugs - openldap.org

(ITS#8576) Broken LDAP_TAILQ_ macros
by hyc＠openldap.org 01 Feb '17

01 Feb '17

Full_Name: Howard Chu Version: HEAD etc OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.200) Submitted by: hyc In commit 8ee824832844c16d4199f3aacd8b1d613933a7d5 we have "LDAP_TAILQ fix" but no explanation of what was broken. In particular though, the LDAP_TAILQ_PREV macro is now broken. It checks for foo == LDAP_TAILQ_FIRST(head) which becomes foo == (head)->tqh_first but the initializer actually used foo = &(head).tqh_first so this comparison will always be false. I don't see any clear reason why these were changed from the originals. I'm inclined to revert the change. Reverting will affect a few uses of LDAP_TAILQ_LAST in back-ldap and back-meta but the other affected macros appear to be unused in our source tree. Tripped over this while attempting to use LDAP_TAILQ_PREV in new code.

1 0

(ITS#8575) Argon2 Password hashing contrib module
by simon＠slevermann.de 26 Jan '17

26 Jan '17

Full_Name: Simon Levermann Version: OS: URL: ftp://ftp.openldap.org/incoming/simon-levermann-170126.patch Submission from: (NULL) (2001:638:708:f002:deab:9ae4:7f07:d350) This patch adds a password hashing module for the argon2 function to the contrib/slapd-modules/passwd/ modules. Argon2 is a relatively new hash function which has won the Password Hashing Competition (https://password-hashing.net) The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Simon Levermann simon(a)slevermann.de. I have not assigned rights and/or interest in this work to any party. I, Simon Levermann, 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

(ITS#8574) bconfig support for DNs that need escaping
by okuznik＠symas.com 25 Jan '17

25 Jan '17

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170125-Deal-with-rDN-correc… Submission from: (NULL) (151.228.185.198) When an rdn under cn=config needs escaping, incorrect value gets passed to the attribute and, if the attribute is single-value, the entry is rejected by entry_naming_check(). Patch against master is attached.

1 0

(ITS#8573) ldap* tools should be able to function w/o a conf file
by quanah＠openldap.org 24 Jan '17

24 Jan '17

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) Right now, it is impossible to configure the ldap* command line tools so that they function in major circumstances w/o also having a configuration file (I.e., ldap.conf, .ldaprc, etc). For example, the ability to use startTLS with LDAP requires such a file so that the CA file and/or cert path for the tool can be defined. The "-o" option should be expanded to cover additional configuration parameters from the conf file, as has already been done with the network timeout parameter.

1 0

Re: (ITS#8572) FOR INFO ONLY: SASL SCRAM-SHA-1 authz may fail incorrectly
by quanah＠symas.com 19 Jan '17

19 Jan '17

--On Thursday, January 19, 2017 8:55 AM +0000 william.b.clay(a)acm.org wrote: > Full_Name: Bill Clay > Version: 2.4.44 > OS: Debian/GNU Linux 7.8 (Wheezy) > URL: > Submission from: (NULL) (79.12.44.250) Hi Bill, I appreciate that you are attempting to be helpful. However, the ITS system is only for reporting bugs occuring in OpenLDAP as clearly noted on the ITS submission form. If you want to provide informational updates, they would probably best go to the openldap-technical mailing list. 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#8572) FOR INFO ONLY: SASL SCRAM-SHA-1 authz may fail incorrectly
by william.b.clay＠acm.org 19 Jan '17

19 Jan '17

Full_Name: Bill Clay Version: 2.4.44 OS: Debian/GNU Linux 7.8 (Wheezy) URL: Submission from: (NULL) (79.12.44.250) Cyrus SASL 2.1.26 plugins/scram.c decode_saslname() may return a corrupt authz name. SASL SCRAM-SHA-1 auth with a "dn:" style authzID can return an authzID string with trailing original (escaped) characters appended. slapd may then incorrectly deny the requested proxy authorization because the returned value may fail match criteria that a correctly-decoded SASL name would pass. (There may be other SASL SCRAM scenarios in which this flaw would produce incorrect results.) Cyrus SASL issue: https://github.com/cyrusimap/cyrus-sasl/issues/416

1 0

(ITS#8571) Added a test for pcache + ldap backen with proxyauthz
by elecharny＠symas.com 18 Jan '17

18 Jan '17

Full_Name: Emmanuel L.charny Version: 2.4.45 OS: N/A URL: ftp://ftp.openldap.org/incoming/elecharny-20170118.patch Submission from: (NULL) (86.246.56.212) This patch adds a unit test for a server configured with proxycache and ldap backend, redirecting all the requests to a remote master server, which does not accept anonymous bind). The proxycache server caches searches and binds. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Symas. Symas has not assigned rights and/or interest in this work to any party. I, Emmanuel Lecharny, am authorized by Symas, my employer, to release this work under the following terms. Symas 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#8565) Clarification of the slapo-ppolicy manpage
by quanah＠symas.com 18 Jan '17

18 Jan '17

--On Wednesday, January 11, 2017 4:44 PM +0000 matthieu.cerda(a)nbs-system.com wrote: > Full_Name: Matthieu Cerda > Version: 2.4.40 > OS: Debian jessie > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.213.124.6) > > > Hello ! > > As per > http://www.openldap.org/lists/openldap-technical/201701/msg00017.html I > would like to submit a small improvement to the slapo-ppolicy manpage to > clarify rootdn presence / absence implications in a ppolicy enabled setup. > > Here is the patch (I thing it's short enough not to justify a separate > upload): Thanks! We went with something slightly different, but the rootdn requirement should be absolutely clear now. Regards, 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#8544) manpage fixes
by quanah＠symas.com 18 Jan '17

18 Jan '17

--On Tuesday, December 13, 2016 9:10 PM +0000 sca+openldap(a)andreasschulze.de wrote: > Full_Name: Andreas Schulze > Version: git > OS: linux > URL: ftp://ftp.openldap.org/incoming/andreas-schulze-161213.patch > Submission from: (NULL) (2001:a60:f0b4:e502::152) > > > I uploaded a patch to polish some manpages. > All changes are suggested by debian lintian > - phrase "allows one to" instead of "allows to" > - some occurences of -foo have to be written as \-foo in a manpage Thanks for the report, this has been applied with one minor change. Regards, 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#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by william.b.clay＠acm.org 18 Jan '17

18 Jan '17

> So you're using TLS client cert and SASL/EXTERNAL to a hostname (also in ther > server cert) but where the IP address of the hostname is directly routed through > 127.0.0.1? The slapd log of my same-host tests confirms they in fact used the IPv4 loopback address, 127.0.0.1, even though the bind URI specified the FQDN. > Not sure but the difference is the client IP address. If the client can reach > slapd through 127.0.0.1 the client's IP address is also 127.0.0.1 which could > make a difference in the SASL client handling. Anyone said hostname > canonicalization? Does setting sasl-host <fqdn> make a difference? The ~/.ldaprc used by the client in these tests contained "TLS_REQCERT none", so a mismatch between the server's FQDN and the peer address actually used would not have been detected. Another difference would be "ping-pong" memory allocation between client and server. Even though different processes, they may allocate from the same pool. With the client running on a different host in other tests, slapd would not be competing with other processes in a predictable, repeatable fashion (slapd SEGFAULTs were 100% repeatable for specific sequences of EXTERNAL binds, but only with client and server on the same host).

1 0

Re: (ITS#6104) race condition with cancel operation
by michaelgarofalo404＠yahoo.com 18 Jan '17

18 Jan '17

1 0

Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
by michael＠stroeder.com 17 Jan '17

17 Jan '17

rick(a)openfortress.nl wrote: > This is in fact what I was looking for; whether OpenLDAP supports this > per-operation Proxy Authz Control. So you can try yourself. The rootdn can always do this. The help of ldapsearch tool says: -e [!]<ext>[=<extparam>] general extensions (! indicates criticality) [..] [!]authzid=<authzid> (RFC 4370; "dn:<dn>" or "u:<user>") Ciao, Michael.

1 0

Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
by rick＠openfortress.nl 17 Jan '17

17 Jan '17

Hi Quanah, > Thanks for the report. However, the EXTERNAL mechanism is in fact a > SASL mechanism, just implemented directly in OpenLDAP (vs other SASL > mechanisms that OpenLDAP supports via Cyrus-SASL). The location in > the admin guide is correct. Yes, thanks, Howard also pointed that out, and I learnt. > If you read RFC 4370, Section 1 clearly notes that it is a part of > SASL: > > "The Lightweight Directory Access > Protocol [LDAPV3] supports the use of the Simple Authentication and > Security Layer [SASL] for authentication and for supplying an > authorization identity distinct from the authentication identity, > where the authorization identity applies to the whole LDAP session." Ehm, it doesn't actually state that Proxied Authz is part of SASL. It just continues to state that it is on a per-operation basis, and to me it reads like an independent mechanism, at least as far as the protocol is concerned. Although it can be easily imagined that it were to share (lots of) code with SASL EXTERNAL of course, but that would be an implementation choice. Or am I still not reading it correctly? This is in fact what I was looking for; whether OpenLDAP supports this per-operation Proxy Authz Control. Aside from the above being properly located, I am still missing a remark about it in the Manual. Thanks, -Rick

1 0

Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
by quanah＠symas.com 17 Jan '17

17 Jan '17

--On Friday, January 06, 2017 7:17 PM +0000 rick(a)openfortress.nl wrote: > Full_Name: Rick van Rein > Version: 2.4 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:980:93a5:1:98ff:3cc8:e968:ded8) > > > Hello, > > I found a nit in the OpenLDAP administrator's guide at > http://www.openldap.org/doc/admin24/guide.html#SASL%20Proxy%20Authorizati > on > > It mentions Proxy Authorization as a facility of SASL, something I never > heard of. It is defined specifically for LDAP in RFC 4370. So the > chapter title, and perhaps its ordering underneath SASL, are not perfect. Hi Rick, Thanks for the report. However, the EXTERNAL mechanism is in fact a SASL mechanism, just implemented directly in OpenLDAP (vs other SASL mechanisms that OpenLDAP supports via Cyrus-SASL). The location in the admin guide is correct. If you read RFC 4370, Section 1 clearly notes that it is a part of SASL: "The Lightweight Directory Access Protocol [LDAPV3] supports the use of the Simple Authentication and Security Layer [SASL] for authentication and for supplying an authorization identity distinct from the authentication identity, where the authorization identity applies to the whole LDAP session." Regards, 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#8563) Documentation inconsistency for syncrepl for mdb
by quanah＠symas.com 17 Jan '17

17 Jan '17

--On Saturday, January 07, 2017 8:13 PM +0000 dpa-openldap(a)aegee.org wrote: > Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; > &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1 > 086;&#1074; Version: 2.4.44 > OS: any > URL: > Submission from: (NULL) (141.2.134.77) > > > The manual states in section 5.2.5.8 olcSyncrepl, second last paragraph: > "The syncrepl replication mechanism is supported by the bdb and hdb > backends". > > This text above is repeated in section 6.2.3.7 syncrepl. > > But in section 18.1.1.2. Syncrepl Details, fourth paragraph, is written > 'The syncrepl engine, which is a consumer-side replication engine, can > work with any backends. The LDAP Sync provider can be configured as an > overlay on any backend, but works best with the back-bdb back-hdb, or > back-mdb backends.' > > Can syncrepl work with any backend and does it work with bdb equally good > as with mdb? Fixed to mention back-mdb/mdb where appropriate. At the time the documentation was written, back-mdb didn't exist. Regards, 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#8562) Typos in the documentation
by quanah＠symas.com 17 Jan '17

17 Jan '17

--On Saturday, January 07, 2017 7:24 PM +0000 dpa-openldap(a)aegee.org wrote: > Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; > &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1 > 086;&#1074; Version: 2.4.44 > OS: any > URL: > Submission from: (NULL) (141.2.134.77) > > > In the manual, > - section 8.2.5 Access Control Examples, 2nd paragraph replace "allows > anonymous to authentication against these entries" with "authenticate"; > - section 13.2.4 Attibute Type Specification, 4th code snippet, replace > "DESC 'common name(s) assciated with the object" with "associated"; > - section8.8.1.1 LDAP Sync Replication, last paragraph, replace "is > defined by a general search criteria consisting of base and scope': > remove the 'a' in front of criteria. > - section 20 Monitoring, 3rd paragraph "This information can be access > with ldapsearch", substitute with "accessed". Fixed, thanks, outside of the "a general search criteria consisting of base and scope". That seems correct to me. Regards, 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#8570) Typo in LDAP_STAILQ_ENTRY_INIT
by quanah＠symas.com 17 Jan '17

17 Jan '17

--On Tuesday, January 17, 2017 11:49 AM +0000 okuznik(a)symas.com wrote: > Full_Name: Ondrej Kuznik > Version: master > OS: > URL: > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170117-ldap_queue-STAILQ. > patch Submission from: (NULL) (151.228.185.198) > > > There is a typo in include/ldap_queue.h:227, where the macro arguments do > not match with the content. Patch attached. Thanks for the report! This will be a part of the 2.4.45 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#8570) Typo in LDAP_STAILQ_ENTRY_INIT
by okuznik＠symas.com 17 Jan '17

17 Jan '17

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170117-ldap_queue-STAILQ.pa… Submission from: (NULL) (151.228.185.198) There is a typo in include/ldap_queue.h:227, where the macro arguments do not match with the content. Patch attached.

1 0

Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by michael＠stroeder.com 17 Jan '17

17 Jan '17

william.b.clay(a)acm.org wrote: > By localhost, I simply meant running the LDAP client I am developing on > the same host as slapd. To test the same code on different client > hosts, the coded test URIs always specified the server's FQDN. So you're using TLS client cert and SASL/EXTERNAL to a hostname (also in ther server cert) but where the IP address of the hostname is directly routed through 127.0.0.1? > The same tests over the same client code running on a different host > than slapd never got SEGFAULTs -- which I find curious given the nature > of that little bug. There must be some difference in OS memory > allocation logic applied in the two cases. Not sure but the difference is the client IP address. If the client can reach slapd through 127.0.0.1 the client's IP address is also 127.0.0.1 which could make a difference in the SASL client handling. Anyone said hostname canonicalization? Does setting sasl-host <fqdn> make a difference? > I recognize EXTERNAL may not be heavily used, although it's quite useful > in the environment I'm supporting. Actually I'm heavily using SASL/EXTERNAL in almost all my customer setups and in Æ-DIR using either LDAPI:// with Unix Peer Credential passing or TLS with client certs (e.g. for replication). Therefore I appreciate every fix going into this. :-) Ciao, Michael.

1 0

Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by william.b.clay＠acm.org 17 Jan '17

17 Jan '17

By localhost, I simply meant running the LDAP client I am developing on the same host as slapd. To test the same code on different client hosts, the coded test URIs always specified the server's FQDN. The same tests over the same client code running on a different host than slapd never got SEGFAULTs -- which I find curious given the nature of that little bug. There must be some difference in OS memory allocation logic applied in the two cases. I recognize EXTERNAL may not be heavily used, although it's quite useful in the environment I'm supporting. I was simply doing exhaustive testing of my client code under all combinations of transport and authentication. With this bug plugged and using Cyrus SASL 2.1.26 at both ends (2.1.25 has a memory leak for my client), EXTERNAL runs fine in all cases: client local or remote; URI ldapi:// (auth on gid/uid), ldaps:// (auth on cert subject user DN), or ldap:// w/ startTLS (idem).

1 0

Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by michael＠stroeder.com 17 Jan '17

17 Jan '17

william.b.clay(a)acm.org wrote: > In certain circumstances (e.g., two successive localhost EXTERNAL binds Just to be sure: What do you mean with "localhost" in this context? Really ldap://localhost or ldapi://? SASL EXTERNAL most times only makes sense in the latter case (unless you've configured a TLS certificate with name "localhost"). Ciao, Michael.

1 0

Re: (ITS#8569) manpage for autogroup
by ebackes＠symas.com 16 Jan '17

16 Jan '17

This is a multi-part message in MIME format. --Multipart=_Mon__16_Jan_2017_13_04_30_-0800_xqWAijQoRs30vwBy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Patch attached -- Emily Backes Symas Corporation ebackes(a)symas.com desk +1 650 963 7603 mobile +1 818 620 9879 --Multipart=_Mon__16_Jan_2017_13_04_30_-0800_xqWAijQoRs30vwBy Content-Type: text/x-diff; name="0001-Add-a-manpage-for-slapo-autogroup.patch" Content-Disposition: attachment; filename="0001-Add-a-manpage-for-slapo-autogroup.patch" Content-Transfer-Encoding: quoted-printable >From b5599bce0189aaae4631b196720b69e9d8b54639 Mon Sep 17 00:00:00 2001 From: Emily Backes <ebackes(a)symas.com> Date: Mon, 16 Jan 2017 12:59:52 -0800 Subject: [PATCH] Add a manpage for slapo-autogroup --- contrib/slapd-modules/autogroup/slapo-autogroup.5 | 102 ++++++++++++++++++= ++++ 1 file changed, 102 insertions(+) create mode 100644 contrib/slapd-modules/autogroup/slapo-autogroup.5 diff --git a/contrib/slapd-modules/autogroup/slapo-autogroup.5 b/contrib/sl= apd-modules/autogroup/slapo-autogroup.5 new file mode 100644 index 0000000000..1d68a55d8a --- /dev/null +++ b/contrib/slapd-modules/autogroup/slapo-autogroup.5 @@ -0,0 +1,102 @@ +.TH SLAPO-AUTOGROUP 5 "RELEASEDATE" "OpenLDAP LDVERSION" +.\" Copyright 1998-2017 \[u00A9] The OpenLDAP Foundation, All Rights Reser= ved. +.\" Portions Copyright \[u00A9] 2007 Micha=C5=82 Szulczy=C5=84ski. +.\" Copying restrictions apply. See the COPYRIGHT file. +.\" $OpenLDAP$ +.SH NAME +\FCslapo-autogroup\FT \- automatic updates of group memberships which meet= the +requirements of any filter contained in the group definition. +.SH SYNOPSIS +In \FCslapd.conf\FT: + ... + \FCinclude ETCDIR/schema/dyngroup.schema\FT + ... + \FCmoduleload autogroup.so\FT + ... + \FCdatabase\FT ... + ... + \FCoverlay autogroup\FT + \FCautogroup-attrset groupOfURLs memberURL member\FT +.SH DESCRIPTION +The +.B autogroup +overlay to +.BR slapd (8) +allows automated updates of group memberships which meet the requirements +of any filter contained in the group definition. The filters are built from +LDAP URI-valued attributes. Any time an object is added/deleted/updated, i= t is +tested for compliance with the filters, and its membership is accordingly +updated. For searches and compares, it behaves like a static group. +If the attribute part of the URI is filled, the group entry is populated by +the values of this attribute in the entries resulting from the search. +.SH CONFIGURATION +Either +.BR \FCslapd.conf\FT (5) +or the \FCcn=3Dconfig\FT methodology of +.BR \FCslapd-config\FT (5) +may be used for configuring autogroup. Both syntaxes are provided +here for convenience: +.TP +.B \FCautogroup-attrset\FT <group-oc> <URL-ad> <member-ad> +.TP +.B \FColcAGattrSet:\FT <group-oc> <URL-ad> <member-ad> +This defines the objectclass-attribute-URI mappings defining the +automatically managed groups, and may appear multiple times. + +The value <group-oc> is the name of the objectClass that represents +the group. + +The value <URL-ad> is the name of the attributeDescription that +contains the URI that is converted to the filters. If no URI is +present, there will be no members in that group. It must be a subtype +of labeledURI. + +The value <member-ad> is the name of the attributeDescription that +specifies the member attribute. User modification of this attribute is +disabled for consistency. +.TP +.B \FCautogroup-memberof-ad\FT <memberof-ad> +.TP +.B \FColcAGmemberOfAd\FT <memberof-ad> +This defines the attribute that is used by the memberOf overlay to +store the names of groups that an entry is member of; it must be +DN-valued. It should be set to the same value as +memberof-memberof-ad. It defaults to 'memberOf'. +.SH EXAMPLES +As above in SYNOPSIS, or with memberof: + + ... + \FCinclude ETCDIR/schema/dyngroup.schema\FT + \FCinclude ETCDIR/schema/memberof.schema\FT + ... + \FCmoduleload autogroup.so\FT + \FCmoduleload memberof.so\FT + ... + \FCdatabase\FT ... + ... + \FCoverlay memberof\FT + \FCmemberof-memberof-ad\FT foo + ... + \FCoverlay autogroup\FT + \FCautogroup-attrset groupOfURLs memberURL member\FT + \FCautogroup-memberof-ad\FT foo +.SH CAVEATS +As with static groups, update operations on groups with a large number +of members may be slow. If the attribute part of the URI is specified, +modify and delete operations are more difficult to handle. In these +cases the overlay will try to detect if groups have been modified and +then simply refresh them. This can cause performance hits if the +search specified by the URI deals with a significant number of +entries. +.SH ACKNOWLEDGEMENTS +This module was originally written in 2007 by Micha=C5=82 +Szulczy=C5=84ski. Further enhancements were contributed by Howard +Chu, Raphael Ouazana, Norbert Pueschel, and Christian Manal. Manpage +updates provided by Emily Backes. +.SH SEE ALSO +.BR slapd.conf (5), +.BR slapd (8). +.SH Copyrights +Copyright \[u00A9] 1998-2017 The OpenLDAP Foundation. +Portions Copyright \[u00A9] 2007 Micha=C5=82 Szulczy=C5=84ski. +All rights reserved. --=20 2.11.0 --Multipart=_Mon__16_Jan_2017_13_04_30_-0800_xqWAijQoRs30vwBy--

1 0

(ITS#8569) manpage for autogroup
by ebackes＠symas.com 16 Jan '17

16 Jan '17

Full_Name: Emily K Backes Version: anything in the last decade OS: URL: Submission from: (NULL) (50.113.67.84) Quanah squawked at me to add the manpage for autogroup, so here it is. This is largely based on the contents of the existing README, cleaned up for ROFF as appropriate, with slapd.d style names added. I expect we'll need to add more details on delta-syncrepl compatibility after further testing is done with that. Note that default ROFF configs may not be unicode clean, but the original author's name appears to require it. For text review I recommend something like groff -mandocDutftf8 -Tutf8 slapo-autogroup.5 | less As the attached patch is directly derived from the existing README and standard OpenLDAP structures, it has the same copyright and distribution terms. Symas Corporation and myself (Emily Backes) make no further claims beyond the existing OpenLDAP Public License.

1 0

Re: (ITS#8567) Adding our Support services at your site
by quanah＠symas.com 16 Jan '17

16 Jan '17

--On Saturday, January 14, 2017 2:07 PM +0000 nickreiner(a)thishosting.rocks wrote: > Full_Name: Nick Reiner > Version: Latest > OS: Linux-based distros. > URL: http://www.openldap.org/support/ > Submission from: (NULL) (92.53.50.107) Entry added, it will show up on the website the next time it is updated. Regards, 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#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by quanah＠symas.com 16 Jan '17

16 Jan '17

--On Sunday, January 15, 2017 9:15 PM +0000 william.b.clay(a)acm.org wrote: > The following patch seems to correct this issue. I have tested it only on > a Debian Linux amd64 system, OpenLDAP 2.4.44 build from source, running > with Cyrus SASL 2.1.25 as distributed in Debian Wheezy. > > bill@fuji:/usr/local/src/openldap-2.4.44/servers/slapd$ diff sasl.c.orig > sasl.c 1501c1501 > < sasl_ssf_t ssf = 0; > --- >> sasl_ssf_t *ssf = NULL; > 1514c1514 > < sasl_setprop( ctx, SASL_SSF_EXTERNAL, &ssf ); > --- >> sasl_setprop( ctx, SASL_SSF_EXTERNAL, ssf ); > bill@fuji:/usr/local/src/openldap-2.4.44/servers/slapd$ Hi Bill, Thanks very much for the report! It looks like this was introduced in OpenLDAP 2.2. It's definitely not a common case. In the future, please follow the contribution guidelines documented at <http://www.openldap.org/devel/contributing.html> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs