> Hi Kurt -
>
> The link on the website (http://www.openldap.org/doc/) for the 2.4 pdf
> manual is actually the 2.3 manual. I was somewhat confused by this
> until after I compiled the 2.4.7 sources, and then was finding differences
> and noticed that the title page was still 2.3. Anyway, I was able to
> locate, download and install sdf and htmldoc so that I could generate a
> copy of the pdf. It would be nice however if you could update the link
> on the website, re-generate the doc to have the actual 2.4 guide, or fix
> the Makefile to put the correct doc pdf in place on the website.
>
> Raymond - Attached is the 2.4 pdf, I generated yesterday in case you
> didn't actually get the 2.4 PDF manual.
>
Hmmm:
http://www.openldap.org/doc/admin24/OpenLDAP-Admin-Guide.pdf
Linked from http://www.openldap.org/doc/
Very nice, thank you! I downloaded the pdf from the site, so I
probably got the 2.3 version earlier.
On Dec 27, 2007, at 14:36 , Dan Schwartz wrote:
> Hi Kurt -
>
> The link on the website (http://www.openldap.org/doc/) for the 2.4 pdf
> manual is actually the 2.3 manual. I was somewhat confused by this
> until after I compiled the 2.4.7 sources, and then was finding
> differences
> and noticed that the title page was still 2.3. Anyway, I was able to
> locate, download and install sdf and htmldoc so that I could
> generate a
> copy of the pdf. It would be nice however if you could update the
> link
> on the website, re-generate the doc to have the actual 2.4 guide, or
> fix
> the Makefile to put the correct doc pdf in place on the website.
>
> Raymond - Attached is the 2.4 pdf, I generated yesterday in case you
> didn't actually get the 2.4 PDF manual.
>
> Sincerely,
> Dan Schwartz
> <OpenLDAP-Admin-Guide.pdf>
Rochette_Jean-Louis(a)emc.com wrote:
> Hi Howard,
> thank you for your answer, though I found it severe and not very
> constructive.
Our purpose is to deliver an LDAP implementation that complies strictly with
the existing specs; that's the only way to guarantee interoperability.
Altering the files we bundle to be non-compliant with the published specs is
always a bad idea. If you find that some schema is deficient, as is the case
with the RFC2307/NIS schema, the correct solution is to fix the spec first.
> I finally found the solution at:
> http://www.openldap.org/lists/openldap-software/200501/msg00309.html
> Since people have been having problems with this case for at least 2
> years now, I think it's worth to put the solution in this ITS entry:
> To allow searching for netgroups by triple, possibly using wildcards,
> you have to change the nis.schema which comes with openldap as follows:
> attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
> DESC 'Netgroup triple'
> EQUALITY caseIgnoreIA5Match
> SUBSTR caseIgnoreIA5SubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
> # EQUALITY and SUBSTR directives added, SYNTAX changed.
> Jean-Louis.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
This is a multi-part message in MIME format.
------_=_NextPart_001_01C84874.F71A55E7
Content-Type: multipart/alternative;
boundary="----_=_NextPart_002_01C84874.F71A55E7"
------_=_NextPart_002_01C84874.F71A55E7
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi Howard,
=20
thank you for your answer, though I found it severe and not very
constructive.
I finally found the solution at:
http://www.openldap.org/lists/openldap-software/200501/msg00309.html
=20
Since people have been having problems with this case for at least 2
years now, I think it's worth to put the solution in this ITS entry:
To allow searching for netgroups by triple, possibly using wildcards,
you have to change the nis.schema which comes with openldap as follows:
attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
DESC 'Netgroup triple'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
# EQUALITY and SUBSTR directives added, SYNTAX changed.
Jean-Louis.
=20
=20
------_=_NextPart_002_01C84874.F71A55E7
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D015592610-27122007>Hi=20
Howard,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D015592610-27122007></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D015592610-27122007>thank =
you for your=20
answer, though I found it severe and not very =
constructive.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D015592610-27122007>I =
finally found the=20
solution at:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D015592610-27122007><A=20
href=3D"http://www.openldap.org/lists/openldap-software/200501/msg00309.h=
tml">http://www.openldap.org/lists/openldap-software/200501/msg00309.html=
</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D015592610-27122007></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D015592610-27122007>Since =
people have=20
been having problems with this case for at least 2 years now, I think =
it's worth=20
to put the solution in this ITS entry:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D015592610-27122007>To =
allow searching=20
for netgroups by triple, possibly using wildcards, you have to change =
the=20
nis.schema which comes with openldap as follows:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial><SPAN class=3D015592610-27122007><FONT =
face=3DCourier=20
size=3D2>attributetype ( 1.3.6.1.1.1.1.14 NAME=20
'nisNetgroupTriple'<BR> =
DESC=20
'Netgroup triple'<BR> =
EQUALITY=20
caseIgnoreIA5Match<BR> =
SUBSTR=20
caseIgnoreIA5SubstringsMatch<BR>  =
; =20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 =
)<BR></FONT></SPAN></FONT><FONT><SPAN=20
class=3D015592610-27122007><FONT face=3DArial size=3D2># EQUALITY and =
SUBSTR=20
directives added, SYNTAX changed.<BR></FONT></SPAN></FONT></DIV>
<DIV><FONT><SPAN class=3D015592610-27122007><FONT face=3DArial=20
size=3D2>Jean-Louis.</DIV></FONT></SPAN></FONT>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D015592610-27122007></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D015592610-27122007></SPAN></FONT> </DIV></BODY></HTML>
------_=_NextPart_002_01C84874.F71A55E7--
------_=_NextPart_001_01C84874.F71A55E7
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: from corpussmtp3.corp.emc.com ([10.254.64.53]) by CORPUSMX40A.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Dec 2007 14:37:19 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_003_01C844D2.10754180"
Received: from mexforwardwc.lss.emc.com ([137.69.224.88]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Dec 2007 14:37:18 -0500
Received: from mailhubwc.lss.emc.com (buto.lss.emc.com [137.69.224.85]) by mexforwardwc.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lBMJbHUf027151 for <rochette_jean-louis(a)mail.corp.emc.com>; Sat, 22 Dec 2007 11:37:18 -0800 (PST)
Received: from wcigw.emc.com (mania.lss.emc.com [137.69.120.85]) by mailhubwc.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lBMJbGv6004264 for <rochette_jean-louis(a)mailhubwc.lss.emc.com>; Sat, 22 Dec 2007 11:37:16 -0800 (PST)
Received: from mail223-sin-R.bigfish.com (mail-sin.bigfish.com [207.46.51.74]) by wcigw.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lBMJbEUj029749 for <rochette_jean-louis(a)emc.com>; Sat, 22 Dec 2007 11:37:14 -0800
Received: from mail223-sin (localhost.localdomain [127.0.0.1]) by mail223-sin-R.bigfish.com (Postfix) with ESMTP id 3A57E13D8164 for <rochette_jean-louis(a)emc.com>; Sat, 22 Dec 2007 19:35:31 +0000 (UTC)
Received: by mail223-sin (MessageSwitch) id 1198352127927900_27242; Sat, 22 Dec 2007 19:35:27 +0000 (UCT)
Received: from highlandsun.propagation.net (highlandsun.propagation.net [66.221.212.168]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail223-sin.bigfish.com (Postfix) with ESMTP id 231FF1830077 for <rochette_jean-louis(a)emc.com>; Sat, 22 Dec 2007 19:35:22 +0000 (UTC)
Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id lBMJacMH015224; Sat, 22 Dec 2007 13:36:39 -0600
Content-class: urn:content-classes:message
Subject: Re: (ITS#5296) Search netgroup by triple don't report existing entry
Date: Sat, 22 Dec 2007 14:29:35 -0500
Message-ID: <476D659F.3070508(a)symas.com>
In-Reply-To: <200712211137.lBLBbcIP071531(a)boole.openldap.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: (ITS#5296) Search netgroup by triple don't report existing entry
thread-index: AchE0hDhl1cnpViATYaYO5itS8oD6g==
References: <200712211137.lBLBbcIP071531(a)boole.openldap.org>
From: <hyc(a)symas.com>
To: <Rochette_Jean-Louis(a)emc.com>
Cc: <openldap-its(a)openldap.org>
This is a multi-part message in MIME format.
------_=_NextPart_003_01C844D2.10754180
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
rochette_jean-louis(a)emc.com wrote:
> Full_Name: Jean-Louis ROCHETTE
> Version: 2.3.39
> OS: Linux Fedora
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (152.62.109.163)
>=20
>=20
> Brief description of the problem
> --------------------------------
> Lookup of a netgroup by triple doesn't work in last stable release =
slapd 2.3.39,
> though it worked well with slapd 2.3.27.
> This looks like a regression in slapd.
> This should be easy to reproduce.
> The problem was first noticed in slapd 2.3.30.
> The lookup by triple succeeds with a iPlanet server.
There are no matching rules defined for nisNetgroupTriple in nis.schema. =
There=20
have never been, since RFC2307 doesn't define any. As such, filtering by =
nisNetgroupTriple is totally undefined. Any server that returns your =
expected=20
result using the search filter you provide is broken.
There is no regression here. Your distro vendor may have hacked their =
own=20
schema files to provide one, that's an issue for you to discuss with =
your=20
vendor. This ITS will be closed.
--=20
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
------_=_NextPart_003_01C844D2.10754180
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>Re: (ITS#5296) Search netgroup by triple don't report existing =
entry</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>rochette_jean-louis(a)emc.com wrote:<BR>
> Full_Name: Jean-Louis ROCHETTE<BR>
> Version: 2.3.39<BR>
> OS: Linux Fedora<BR>
> URL: <A =
HREF=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming=
/</A><BR>
> Submission from: (NULL) (152.62.109.163)<BR>
><BR>
><BR>
> Brief description of the problem<BR>
> --------------------------------<BR>
> Lookup of a netgroup by triple doesn't work in last stable release =
slapd 2.3.39,<BR>
> though it worked well with slapd 2.3.27.<BR>
> This looks like a regression in slapd.<BR>
> This should be easy to reproduce.<BR>
> The problem was first noticed in slapd 2.3.30.<BR>
> The lookup by triple succeeds with a iPlanet server.<BR>
<BR>
There are no matching rules defined for nisNetgroupTriple in nis.schema. =
There<BR>
have never been, since RFC2307 doesn't define any. As such, filtering =
by<BR>
nisNetgroupTriple is totally undefined. Any server that returns your =
expected<BR>
result using the search filter you provide is broken.<BR>
<BR>
There is no regression here. Your distro vendor may have hacked their =
own<BR>
schema files to provide one, that's an issue for you to discuss with =
your<BR>
vendor. This ITS will be closed.<BR>
--<BR>
-- Howard Chu<BR>
Chief Architect, Symas Corp. <A =
HREF=3D"http://www.symas.com">http://www.symas.com</A><BR>
Director, Highland =
Sun <A =
HREF=3D"http://highlandsun.com/hyc/">http://highlandsun.com/hyc/</A><BR>
Chief Architect, OpenLDAP <A =
HREF=3D"http://www.openldap.org/project/">http://www.openldap.org/project=
/</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_003_01C844D2.10754180--
------_=_NextPart_001_01C84874.F71A55E7--
hyc(a)symas.com wrote:
> hyc(a)symas.com wrote:
>> dwhite(a)olp.net wrote:
>>> Full_Name: Dan White
>>> Version: 2.3.39
>>> OS: Linux
>>> URL: http://support.olp.net/ldap/log.txt
>>> Submission from: (NULL) (65.161.252.42)
>> Nice bit of debugging there. This could be a bit tricky because the slapd
>> auxprop code assumes it's always executing on behalf of an LDAP operation
>> (usually a Bind request). In this case, there is no active request; it's the
>> cleanup action on a closed connection, and most of the state that slapd needed
>> has already been torn down. It may take some restructuring to allow this to
>> work, we never expected sasl_dispose() to be anything other than a pure
>> destructor.
>
> Fixed in CVS HEAD.
>
Howard,
This fix works for me.
Thanks,
- Dan
Howard Chu wrote:
> This is a bug in Cyrus SASL; the setpass function is zeroing out the
> connection state when it should be leaving it intact. The attached patch
> will fix the problem. (Verified using saslauthd and most of the above
> components.)
Thanks Howard. This patch works for me.
- Dan
This is a multi-part message in MIME format.
--------------040002000303080307090101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
dwhite(a)olp.net wrote:
> Full_Name: Dan White
> Version: 2.3.39
> OS: Linux
> URL: http://support.olp.net/ldap/log2.txt
> Submission from: (NULL) (65.161.252.42)
>
>
> If I enable SASL auto_transition, I receive the following error during
> authentication:
>
> SASL(-14): authorization failure: invalid authcid
>
> I'm using openldap version 2.3.39 for both slapd and my ldap utils
> (ldapsearch).
> I'm using the bdb backend.
>
> I'm also using Debian Etch with the following versions of software:
>
> Cyrus SASL 2.1.22(.dfsg1-8)
> libdb 4.2.52(+dfsg-2)
> libc6 2.3.6(.ds1-13etch2)
> PAM 0.79(-4)
> pam_ldap 184(-2)
>
> I'm using saslauthd's PAM backend, and in turn using pam_ldap for
> authentication, although I don't believe the problem is related to the
> saslauthd/pam configuration.
>
> Here's the client side output from the attempted bind:
>
> hiro:~# ldapsearch -LLL -Y PLAIN -U abrown(a)olp.net uid=n/a
> SASL/PLAIN authentication started
> Please enter your password:
> ldap_sasl_interactive_bind_s: Insufficient access (50)
> additional info: SASL(-14): authorization failure: invalid authcid
>
> If I turn off auto_transition, it works:
>
> hiro:~# ldapsearch -LLL -Y PLAIN -U abrown(a)olp.net uid=n/a
> SASL/PLAIN authentication started
> Please enter your password:
> SASL username: abrown(a)olp.net
> SASL SSF: 0
> hiro:~#
>
> My slapd.conf SASL service file looks like:
>
> hiro:~# cat /usr/lib/sasl2/slapd.conf
> keytab: /etc/krb5.keytab-ldap
> pwcheck_method: saslauthd
> auxprop_plugin: slapd
> auto_transition: yes
> log_level: 7
>
> And the server log (loglevel -1) is located at:
>
> http://support.olp.net/ldap/log2.txt
>
> The error appears to be occurring while transitioning the password to the
> auxprop store, in the slap_sasl_authorize function:
>
> /* Skip SLAP_SASL_PROP_CONN */
> prop_getnames( props, slap_propnames+1, auxvals );
>
> /* Should not happen */
> if ( !auxvals[0].values ) {
> sasl_seterror( sconn, 0, "invalid authcid" );
> return SASL_NOAUTHZ;
> }
>
> What I'm expecting to happen during the bind, is to have SASL overwrite my
> userPassword and cmusaslsecretOTP attributes, via the slapd auxprop plugin.
>
> I have a lot of passwords in crypted form (which PAM authenticates), and I'm
> aiming towards a clear-text password store by using this functionality.
This is a bug in Cyrus SASL; the setpass function is zeroing out the
connection state when it should be leaving it intact. The attached patch will
fix the problem. (Verified using saslauthd and most of the above components.)
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--------------040002000303080307090101
Content-Type: text/plain;
name="dif.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="dif.txt"
Index: server.c
===================================================================
RCS file: /cvs/src/sasl/lib/server.c,v
retrieving revision 1.147
diff -u -r1.147 server.c
--- server.c 3 Jul 2006 14:43:16 -0000 1.147
+++ server.c 23 Dec 2007 01:52:25 -0000
@@ -129,6 +129,7 @@
int result = SASL_OK, tmpresult;
sasl_server_conn_t *s_conn = (sasl_server_conn_t *) conn;
const char *password_request[] = { SASL_AUX_PASSWORD_PROP, NULL };
+ struct propctx *propctx = NULL;
sasl_server_userdb_setpass_t *setpass_cb = NULL;
void *context = NULL;
int tried_setpass = 0;
@@ -172,14 +173,18 @@
pass = NULL;
passlen = 0;
}
-
- result = prop_request(s_conn->sparams->propctx, password_request);
+
+ propctx = prop_new(0);
+ if ( !propctx ) {
+ RETURN(conn, SASL_NOMEM);
+ }
+ result = prop_request(propctx, password_request);
if (result == SASL_OK) {
- result = prop_set(s_conn->sparams->propctx, SASL_AUX_PASSWORD_PROP,
+ result = prop_set(propctx, SASL_AUX_PASSWORD_PROP,
pass, passlen);
}
if (result == SASL_OK) {
- result = sasl_auxprop_store(conn, s_conn->sparams->propctx, user);
+ result = sasl_auxprop_store(conn, propctx, user);
}
if (result != SASL_OK) {
_sasl_log(conn, SASL_LOG_ERR,
@@ -189,6 +194,7 @@
_sasl_log(conn, SASL_LOG_NOTE,
"setpass succeeded for %s", user);
}
+ prop_dispose(&propctx);
}
/* We want to preserve the current value of result, so we use tmpresult below */
--------------040002000303080307090101--
Full_Name: Howard Chu
Version: HEAD
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (76.91.220.157)
Submitted by: hyc
While testing the fix for ITS#5259 I realized that the SASL DN is being
allocated on the Operation's slab, but may be referenced by a different
Operation if a Bind requires multiple steps.
For OTP there are 2 operations - the identities are canonicalized and saved in
step 1, when the challenge is generated for the client, and then the OTP is sent
and validated in a subsequent operation.
(DIGEST-MD5 also occurs in 2 steps, but no usernames are provided in step 1, all
canonicalization and validation occurs in step 2 so it's all within a single
operation.)
To avoid this problem, the DNs probably should be dup'd using the SASL
allocator, so they can be cleaned up automatically when SASL completes.
hyc(a)symas.com wrote:
> dwhite(a)olp.net wrote:
>> Full_Name: Dan White
>> Version: 2.3.39
>> OS: Linux
>> URL: http://support.olp.net/ldap/log.txt
>> Submission from: (NULL) (65.161.252.42)
>
> Nice bit of debugging there. This could be a bit tricky because the slapd
> auxprop code assumes it's always executing on behalf of an LDAP operation
> (usually a Bind request). In this case, there is no active request; it's the
> cleanup action on a closed connection, and most of the state that slapd needed
> has already been torn down. It may take some restructuring to allow this to
> work, we never expected sasl_dispose() to be anything other than a pure
> destructor.
Fixed in CVS HEAD.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/