- openldap-bugs - openldap.org

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Mon, Jun 16, 2008 at 02:29:21PM +0000, Andrew Findlay wrote: > Thus I think my original report was wrong. This is a documentation > issue, not a bug. I have uploaded a suggested set of patches to make the behaviour clearer: ftp://ftp.openldap.com/incoming/andrew.findlay-20080616.patch The patch is against 2.4.10 It might be better still to factor out the concept of proxy authorisation and its control from the SASL authz mechanism, as it applies also to the LDAP Proxied Authorization Control. I have not done this as I was unsure where best to put it. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5561) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

------------------- slapd.conf --------------------------- include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/misc.schema password-hash {md5} pidfile /var/run/slapd.pid argsfile /var/run/slapd.args TLSCertificateFile /etc/openldap/certs/cert.pem TLSCertificateKeyFile /etc/openldap/certs/key.pem TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 loglevel -1 database bdb suffix "dc=meirion-dwyfor,dc=ac,dc=uk" rootdn "cn=Manager,dc=meirion-dwyfor,dc=ac,dc=uk" directory /var/lib/openldap/openldap-data index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUID eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub ------------------- ldap.conf ------------------------ BASE dc=meirion-dwyfor,dc=ac,dc=uk URI ldap://localhost TLS_CACERT /etc/openldap/certs/cacert.pem -------------------------------------------------------

1 0

(ITS#5564) Use largest contextCSN to determine staleness?
by rein＠OpenLDAP.org 16 Jun '08

16 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein Scenario: A syncrepl consumer replicates a backend DB where it has at least one entry that is up to date when it starts, but there are newer entries on the producer. The oldest contextCSN presented by the consumer is older than all entryCSN values in the replicated backend on the producer.. When syncprov_findcsn() is called with the FIND_CSN tag it will not find any entries whose entryCSN is <= the oldest csn presented by the consumer, and the cookie set will be determined as stale. Which again means that no present UUIDs will be sent to the consumer. The producer will, during the search that follows, skip sending entries whose entryCSN values are older or equal to a contextCSN with the same sid presented by the client. I.e the consumer will neither get these entries in a present UUID set nor as updated entries, and will therefore incorrectly remove them from its database. A fix that seems to solve this is that syncprov_findbase(FIND_CSN) should search for entries whose entryCSN value is less than the largest contextCSN presented by the client. All the test scripts succeed if I try this, but I'm not convinced that this is the correct fix. Would it not be more correct to ignore the entire CSN set presented by the consumer when it has been determined as stale? Hm, if the oldest contextCSN is from a server that is seldom updated this alternate fix could mean that a full reload would be performed every time the client starts with an outdated contextCSN set. Would the best fix be to do both, i.e search for entryCSN <= the largest csn presented by the client, and also ignore the csn set when it has been determined as stale? Rein Tollevik Basefarm AS

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Mon, Jun 16, 2008 at 02:45:43PM +0200, Hallvard B Furuseth wrote: > If non-anonymous access is needed, the slapd.access(5) manpage needs an > update too. (Or instead, to avoid duplicating text.) Currently it just > says: > > Auth (=x) privileges are also required on the authzTo attribute > of the authorizing identity and/or on the authzFrom attribute of > the authorized identity. > > but it doesn't mention to who needs that auth access. It is the authenticated ID that needs access in both cases. On further thought I think it is correct that the access is checked without reference to whether that ID has access to entry and parent entries, as (particularly in the case of authzFrom) the authenticated ID may not have any direct access to the entry whose ID it is about to assume. Thus, if principal A has authenticated and wishes to perform an operation using principal B's authorisation, the access required is: A needs auth access to authzTo in its own entry if that attribute is involved in giving A permission to act for B. A needs auth access to authzFrom in B's entry if that attribute is involved in giving A permission to act for B. The rules are the same whether using a SASL authorization identity or using a ProxyAuth control on an LDAP operation. Thus I think my original report was wrong. This is a documentation issue, not a bug. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5561) SEGV using TLS/SASL
by h.b.furuseth＠usit.uio.no 16 Jun '08

16 Jun '08

Please post your ldap.conf and slapd.conf, minus any passwords. > The pastebin URL contains the post SSL negotiation debug > lines from "slapd -d -1". No need to pastebin data as short as that. -- Hallvard

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by h.b.furuseth＠usit.uio.no 16 Jun '08

16 Jun '08

andrew.findlay(a)skills-1st.co.uk writes: > You are right: if I just grant 'auth' access to 'authzTo' the proxy > authorisation succeeds. The philisophy makes sense so I will try to > come up with a suitable patch to the Admin Guide describing how to use > it. At the moment the only note about this is in the ACL Examples > (7.2.5 at present) which says that authentication/authorization > is always done anonymously - obviously not entirely true. If non-anonymous access is needed, the slapd.access(5) manpage needs an update too. (Or instead, to avoid duplicating text.) Currently it just says: Auth (=x) privileges are also required on the authzTo attribute of the authorizing identity and/or on the authzFrom attribute of the authorized identity. but it doesn't mention to who needs that auth access. -- Hallvard

1 0

(ITS#5563) Seg. fault if URL used in ServerID without any listener
by rein＠OpenLDAP.org 16 Jun '08

16 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein Slapd will seg. fault if the URL form of ServerID is used without any active listeners. I stumbled upon this by adding "-d ?" to my regular command line. I.e not exactly a critical bug.. I'll commit a trivial fix shortly. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Sat, Jun 14, 2008 at 03:59:37PM +0200, Pierangelo Masarati wrote: > AFAIK, access to that attribute is checked using AUTH rather than read. > The idea is that ACLs should allow to fine-grain control who is > allowed to exploit the authorization feature while giving up as little > as possible (e.g. AUTH instead of READ). You are right: if I just grant 'auth' access to 'authzTo' the proxy authorisation succeeds. The philisophy makes sense so I will try to come up with a suitable patch to the Admin Guide describing how to use it. At the moment the only note about this is in the ACL Examples (7.2.5 at present) which says that authentication/authorization is always done anonymously - obviously not entirely true. I am still a bit worried about the logic of the access test, as in my enviroment I just had to grant the principal auth access to their own authzTo attribute to make proxy authorization work: the principal does not even have 'disclose' access to their own entry or the parent entry. Normally I would expect to need some level of access to everything in the DN before I could make use of an attribute in an entry. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5554) slapd.conf man page missing TLSCipherSuite
by ghenry＠suretecsystems.com 16 Jun '08

16 Jun '08

hyc(a)symas.com wrote: > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… >> missing TLSCipherSuite >> >> >> > No. The Admin Guide is missing the note about GnuTLS under the TLSCipherSuite > description. The note is present in slapd.conf(5). > Where would you like this to be mentioned in the Admin Guide, the only reference to TLSCipherSuite in the guide is in the TLS section, not in the config section. For now I've added: To obtain the list of ciphers in GNUtls use: > gnutls-cli -l in tls.sdf under the openssl cli part. -- Kind Regards, Gavin Henry. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.

1 0

Re: (ITS#5562) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

Duplicate. Please close. ----- Original Message ----- From: openldap-its(a)OpenLDAP.org To: "lea anthony" <lea.anthony(a)meirion-dwyfor.ac.uk> Sent: Monday, June 16, 2008 10:00:49 AM (GMT) Europe/London Subject: Re: (ITS#5562) SEGV using TLS/SASL *** 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#5562. 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#5562) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#5562) 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=5562 Please remember to retain your issue tracking number (ITS#5562) 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#5562) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

Full_Name: Lea Anthony Version: 2.3.40 OS: Arch Linux URL: http://pastebin.com/f6b680f22 Submission from: (NULL) (194.82.229.100) I have TLS setup as follows: TLSCertificateFile /etc/openldap/certs/cert.pem TLSCertificateKeyFile /etc/openldap/certs/key.pem TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 The server starts fine and doing "ldapsearch -x -ZZ" will do an anonymous bind fine. However, doing "ldapsearch -ZZ" will cause a segfault on the server. The pastebin URL contains the post SSL negotiation debug lines from "slapd -d -1".

1 0

(ITS#5561) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

Full_Name: Lea Anthony Version: 2.3.40 OS: Arch Linux URL: http://pastebin.com/f6b680f22 Submission from: (NULL) (194.82.229.100) I have TLS setup as follows: TLSCertificateFile /etc/openldap/certs/cert.pem TLSCertificateKeyFile /etc/openldap/certs/key.pem TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 The server starts fine and doing "ldapsearch -x -ZZ" will do an anonymous bind fine. However, doing "ldapsearch -ZZ" will cause a segfault on the server. The pastebin URL contains the post SSL negotiation debug lines from "slapd -d -1".

1 0

Re: (ITS#5556) ldapadd/slapadd create objects without RDN
by h.b.furuseth＠usit.uio.no 14 Jun '08

14 Jun '08

Well, pre-2.4.9 versions would reject the Add operation... Is it 2.4.10 built from the OpenLDAP source, or some prepackaged binary? Maybe an overlay or something interferes with auto-adding the naming attrs? Please post your slapd.conf too, after removing passwords etc. -- Hallvard

1 0

(ITS#5560) API for assertion control
by michael＠stroeder.com 14 Jun '08

14 Jun '08

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.75.195) I would be handy to have an API for generating an assertion control (see RFC 4528). The function should take a string representation of a LDAP search filter as input.

1 0

Re: (ITS#5556) ldapadd/slapadd create objects without RDN
by ando＠sys-net.it 14 Jun '08

14 Jun '08

joshua(a)itsecureadmin.com wrote: > When adding an object with slapadd or ldapadd, it is possible to create an > object which does not have an RDN, and therefore not searchable by RDN. Can't reproduce. Works as expected here (adding entry without naming attributes/distinguished values results in automatically generating that data, both by slapadd and ldapadd). Can you confirm software versions? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by ando＠sys-net.it 14 Jun '08

14 Jun '08

andrew.findlay(a)skills-1st.co.uk wrote: > When using "authz-policy to" I find that the entity that is trying to do an > operation on behalf of another entity needs read access to its own authzTo > attribute. > This seems wrong: authzTo is defining what the user may do: I do not really want > them to be able to see it. When doing a proxy authz I think ACLs for this > attribute should not be checked at all as the access is effectively being done > by the rootdn. AFAIK, access to that attribute is checked using AUTH rather than read. The idea is that ACLs should allow to fine-grain control who is allowed to exploit the authorization feature while giving up as little as possible (e.g. AUTH instead of READ). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5559) slapo-pcache sizelimit caching not documented
by ando＠sys-net.it 14 Jun '08

14 Jun '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando The sizelimit caching feature, and related setting, are not documented in slapo-pcache(5) man page.

1 0

Re: (ITS#5549) slapd SEGV faults in entry_partsize when monitoring
by ando＠sys-net.it 14 Jun '08

14 Jun '08

andreas.mueller(a)othello.ch wrote: > Full_Name: Andreas Mueller > Version: 2.4.9 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.134.170.35) > > > We have four slapd servers in a mirrormode configuration. > This generally works well. We monitor these servers using > ldapsearches to cn=Monitor every minute, and collect > performance data to construct load/performance graphs > with rrdtool. Unfortunately, it sometimes happens that > slapd crashes during the monitoring query. Using gdb, we > were able to get a stack backtrace: > > Core was generated by `/usr/local/libexec/slapd'. > Program terminated with signal 11, Segmentation fault. > #0 0x0005fd48 in entry_partsize () > (gdb) bt > #0 0x0005fd48 in entry_partsize () > #1 0x000603b4 in entry_flatsize () > #2 0x0006a5c8 in slap_send_search_entry () > #3 0x00134330 in monitor_send_children () > #4 0x001348e0 in monitor_back_search () > #5 0x000523ac in fe_op_search () > #6 0x00051b64 in do_search () > #7 0x0004dd8c in connection_operation () > #8 0x0004e4c4 in connection_read_thread () > #9 0x001a22a8 in ldap_int_thread_pool_wrapper () > #10 0xfe3c5800 in __tbl_10_huge_digits () from /lib/libc.so.1 > > All cores obtained so far show that the segmentation fault > occured at the same location inside entry_partsize. > > Unfortunately we cannot systematically reproduce this behaviour, > and we also cannot get the line number (binaries are stripped). > > We have not tried other versions or other platforms. For production, > we use the versions available in package form from www.sunfreeware.com, > but the error also happens on servers we have compiled ourselves from > the sources. You should run a non-stripped binary, in order to allow more useful information to be extracted from those core files. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5558) Buffer Overflow in back_sock and back_shell
by hyc＠symas.com 13 Jun '08

13 Jun '08

stef(a)memberwebs.com wrote: > Full_Name: Stef Walter > Version: openldap 2.4.10 > OS: FreeBSD 6.3-RELEASE-p2 > URL: http://memberwebs.com/stef/scraps/openldap24-buffer-overflow.patch > Submission from: (NULL) (189.162.38.105) > > > The back_sock and back_shell backends have a buffer overflow (off by one) > problem in their result parsing code in read_and_send_results() lines 82-89 in > result.c. The buffer is reallocated when an additional string would be too long > for the buffer, but the string's null terminator is not taken into account. > > This can cause a crash in certain situations. These situations are obviously > data and OS dependent. But with specific data, the crash is reproducible. > > Patch which fixes the problem: Thanks, now fixed in CVS 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

(ITS#5558) Buffer Overflow in back_sock and back_shell
by stef＠memberwebs.com 13 Jun '08

13 Jun '08

Full_Name: Stef Walter Version: openldap 2.4.10 OS: FreeBSD 6.3-RELEASE-p2 URL: http://memberwebs.com/stef/scraps/openldap24-buffer-overflow.patch Submission from: (NULL) (189.162.38.105) The back_sock and back_shell backends have a buffer overflow (off by one) problem in their result parsing code in read_and_send_results() lines 82-89 in result.c. The buffer is reallocated when an additional string would be too long for the buffer, but the string's null terminator is not taken into account. This can cause a crash in certain situations. These situations are obviously data and OS dependent. But with specific data, the crash is reproducible. Patch which fixes the problem: --- ../openldap-2.4.10/servers/slapd/back-sock/result.c 2008-02-08 18:46:09.000000000 -0000 +++ servers/slapd/back-sock/result.c 2008-06-13 15:56:46.000000000 -0000 @@ -77,7 +77,7 @@ } len = strlen( line ); - while ( bp + len - buf > bsize ) { + while ( bp + (len + 1) - buf > bsize ) { size_t offset = bp - buf; bsize += BUFSIZ; buf = (char *) ch_realloc( buf, bsize ); --- ../openldap-2.4.10/servers/slapd/back-shell/result.c 2008-02-11 17:26:47.000000000 -0000 +++ servers/slapd/back-shell/result.c 2008-06-13 15:57:02.000000000 -0000 @@ -80,7 +80,7 @@ } len = strlen( line ); - while ( bp + len - buf > bsize ) { + while ( bp + (len + 1) - buf > bsize ) { size_t offset = bp - buf; bsize += BUFSIZ; buf = (char *) ch_realloc( buf, bsize );

1 0

(ITS#5557) memory leak in ACL sets
by hyc＠OpenLDAP.org 13 Jun '08

13 Jun '08

Full_Name: Howard Chu Version: 2.3.39/2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc slap_set_join() with an '|' operator will leak values if it detects a duplicate in the rset. A fix will be committed shortly.

1 0

(ITS#5556) ldapadd/slapadd create objects without RDN
by joshua＠itsecureadmin.com 13 Jun '08

13 Jun '08

Full_Name: Josh Miller Version: 2.4.10 OS: CentOS 5.1 URL: http://itsecureadmin.com/uid-test.txt Submission from: (NULL) (65.249.25.3) When adding an object with slapadd or ldapadd, it is possible to create an object which does not have an RDN, and therefore not searchable by RDN. Example data: dn: uid=nouiduser,ou=People,dc=openldap,dc=example,dc=com objectClass: mailAccount maildrop: nouiduser(a)nest.tld mailid: nouiduser(a)nest.tld maildir: nouiduser/ userPassword:: e2NyeXB0fSQxJERCQS5wdmZYJHU0eFp3TndSRDIwSDFkTDBrNmZMRi4= mailquota: 35969216S The above LDIF is added to the directory without any errors and is then missing the uid attribute. ldapsearch will not return any results when filtering on uid, ie: $ ldapsearch -xZZH ldap://server uid=nouiduser - Expected result - return the object. - Actual result - no object returned. - Workaround - use ldapmodify to add the uid attribute. Please see the attached URL for complete event details (add/search/modify).

1 0

(ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 13 Jun '08

13 Jun '08

Full_Name: Andrew Findlay Version: 2.4.10 OS: Linux: SuSE 10.2 URL: Submission from: (NULL) (88.97.25.132) When using "authz-policy to" I find that the entity that is trying to do an operation on behalf of another entity needs read access to its own authzTo attribute. This seems wrong: authzTo is defining what the user may do: I do not really want them to be able to see it. When doing a proxy authz I think ACLs for this attribute should not be checked at all as the access is effectively being done by the rootdn.

1 0

Re: (ITS#5554) slapd.conf man page missing TLSCipherSuite
by ghenry＠OpenLDAP.org 12 Jun '08

12 Jun '08

<quote who="Howard Chu"> > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… >> missing TLSCipherSuite >> >> > No. The Admin Guide is missing the note about GnuTLS under the > TLSCipherSuite > description. The note is present in slapd.conf(5). I don't knwo what I was thinking when I wrote that, but I did mean what you've just wrote. Weird.

1 0

Re: (ITS#5554) slapd.conf man page missing TLSCipherSuite
by hyc＠symas.com 12 Jun '08

12 Jun '08

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… > missing TLSCipherSuite > > > No. The Admin Guide is missing the note about GnuTLS under the TLSCipherSuite description. The note is present in slapd.conf(5). -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs