Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org
On Jun 2, 2010, at 4:28 AM, gcarter(a)likewise.com wrote:
>=20
> Is it just the public ldap_bind_gssapi_s() signature that you
> have an issue with? If, as you suggest, we give you a patch
> that adds an LDAP_AUTH_GSSAPI flag to ldap_bind_s() but keep
> the same (existing) ldap_bind_gssapi_s() internals, would that
> be acceptable?
There's already LDAP_AUTH_NEGOTIATE which does this. So technically, =
the API is already exposed via ldap_bind_s.
But I strongly oppose the introduction of abuse of the LDAP_AUTH_* =
enumeration of LDAP authentication methods and ldap_bind_s(). This =
enumeration and method are intended to have a one-to-one relationship =
with the wire protocol. There is no "negotiate" LDAP authentication =
mechanism.
If this code is going to pursued (see my other comments), I think it =
should be treated as a high level negotiation wrapper similar to =
ldap_sasl_interactive_bind_s(). If at all possible, it should be =
integrated into ldap_sasl_interactive_bind_s() (which can handle =
non-interactive cases as well). However, I could (*) see it desirable =
for it to be separately accessible as well, so =
ldap_sasl_gss_spnego_bind_s() would be better. (* it might be easier to =
see this if a proponent of this feature would implement it in =
ldapwhoami(1) and slapd(8).)
However, I still have objections to releasing code which implements =
undocumented protocol features. Someone really needs to specify the the =
SASL GSS-SPNEGO mechanism and how its used in LDAP.
-- Kurt=20
>=20
>=20
>=20
>=20
>=20
>=20
> cheers, jerry
> - --=20
> Director of Engineering http://www.likewise.com/
> Likewise-CIFS http://www.likewiseopen.org/
> "What man is a man who does not make the world better?" --Balian
>=20
>=20
>=20
>=20
>=20
> On 6/2/10 12:10 AM, Scott Salley wrote:
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: Howard Chu [mailto:hyc@symas.com]
>> Sent: Tue 6/1/2010 6:07 PM
>> To: Scott Salley
>> Cc: openldap-its(a)openldap.org
>> Subject: Re: (ITS#6567) Enable GSSAPI support and expose =
ldap_gssadpi_bind_s
>>=20
>> ssalley(a)likewise.com wrote:
>>> Full_Name: Scott Salley
>>> Version: HEAD
>>> OS: Linux
>>> URL:
>> =
http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def=
ine-have-gssapi.patch
>>> Submission from: (NULL) (67.51.54.234)
>>>=20
>>>=20
>>> Note that a similar issue/contribution was submitted in 2008
>> (Contrib/5369) and
>>> appears to have been 'lost'.
>>=20
>>> The patch
>> =
http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def=
ine-have-gssapi.patch
>>> makes it possible to use the GSSAPI support in OpenLDAP by:
>>>=20
>>> 1. Defining --with-gssapi in configure which
>>> a. Checks for appropriate header files
>>> b. Checks for the appropriate library
>>> c. Defines HAVE_GSSAPI to 1 in everything is in order
>>>=20
>>> 2. Exposing ldap_gssapi_bind_s in ldap.h
>>=20
>> I am still disinclined to publish any of this. The standard mechanism =
for
>> using GSSAPI in LDAP is via SASL. I see no benefit to propagating =
more
>> non-standard one-off ldap_XXX_bind flavors. It's a poor design =
approach
>> and it
>> increases our support workload for no appreciable gain. It increases
>> application developer's workload as well, if they have to test for =
the
>> existence of multiple flavors of ldap_XXX_bind and code for them each
>> separately in their apps.
>>=20
>> If you really want to have "direct" access to other authentication
>> mechanisms,
>> the right way to do this is by adding new LDAP_AUTH_xxx definitions =
that can
>> be muxed out from a single ldap_bind API. Of course, by the time =
you've
>> implemented option parsing so that generic client code can be =
configured
>> with
>> arbitrary Bind mechanisms, you would have re-implemented SASL.
>>=20
>> --
>> -- Howard Chu
>> CTO, Symas Corp. http://www.symas.com
>> Director, Highland Sun http://highlandsun.com/hyc/
>> Chief Architect, OpenLDAP http://www.openldap.org/project/
>>=20
>=20
>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>=20
> iD8DBQFMBj/7IR7qMdg1EfYRAjmcAKC1MyKit8TKa1W96cZ2Uh3Cdm/EMACeJtbu
> 9/F8j8UQJ5C3X0sW5LytRq8=3D
> =3DtkYo
> -----END PGP SIGNATURE-----
>=20
>=20
13 years, 3 months
Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org
Lastly, I note that it might be good for proponent of this feature to at =
least offer extensions to ldapwhoami(1) and other command line tools. =
Aside from the educational value that would provide to developers in how =
this feature would be used along side other libldap features (such as =
ldap_sasl_interactive_bind_s), it would provide a means to test the =
code. Of course, without support in OpenLDAP's slapd(8), testing would =
be cumbersome for many.
-- Kurt
On Jun 1, 2010, at 6:08 PM, hyc(a)symas.com wrote:
> ssalley(a)likewise.com wrote:
>> Full_Name: Scott Salley
>> Version: HEAD
>> OS: Linux
>> URL: =
http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def=
ine-have-gssapi.patch
>> Submission from: (NULL) (67.51.54.234)
>>=20
>>=20
>> Note that a similar issue/contribution was submitted in 2008 =
(Contrib/5369) and
>> appears to have been 'lost'.
>=20
>> The patch =
http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def=
ine-have-gssapi.patch
>> makes it possible to use the GSSAPI support in OpenLDAP by:
>>=20
>> 1. Defining --with-gssapi in configure which
>> a. Checks for appropriate header files
>> b. Checks for the appropriate library
>> c. Defines HAVE_GSSAPI to 1 in everything is in order
>>=20
>> 2. Exposing ldap_gssapi_bind_s in ldap.h
>=20
> I am still disinclined to publish any of this. The standard mechanism =
for=20
> using GSSAPI in LDAP is via SASL. I see no benefit to propagating more=20=
> non-standard one-off ldap_XXX_bind flavors. It's a poor design =
approach and it=20
> increases our support workload for no appreciable gain. It increases=20=
> application developer's workload as well, if they have to test for the=20=
> existence of multiple flavors of ldap_XXX_bind and code for them each=20=
> separately in their apps.
>=20
> If you really want to have "direct" access to other authentication =
mechanisms,=20
> the right way to do this is by adding new LDAP_AUTH_xxx definitions =
that can=20
> be muxed out from a single ldap_bind API. Of course, by the time =
you've=20
> implemented option parsing so that generic client code can be =
configured with=20
> arbitrary Bind mechanisms, you would have re-implemented SASL.
>=20
> --=20
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>=20
>=20
13 years, 3 months
Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org
In looking at the code a bit more closely, one could argue that what =
this code actually provides is an alternative to =
ldap_sasl_interactive_bind_s() which, instead of negotiating any =
mechanism, is designed to negotiate GSS API mechanisms via GSS-SPNEGO. =
In that light, maybe it should be integrated into =
ldap_sasl_interactive_bind_s() or renamed to be more clear to be a =
higher level negotiation routine, maybe ldap_sasl_gss_spnego_bind_s().
However, one issue I have with this code is that highly dependent =
behaviors which, aside from not be standardized, aren't even specified =
in RFCs. For instance, there is no RFC describing dnsHostName or =
ldapServiceName or any specification detailing how GSS-SPNEGO is to be =
used in LDAP. Without a formal specification (e.g., RFC), I oppose =
release of this code. That is, it should stay HEAD only until such time =
that a formal specification (e.g., RFC) is available.
I would assume GSS-SPNEGO is usable without these attributes. It seems =
odd to me that this code requires them.
I note that use of the SASL GSS-SPNEGO in LDAP has actually be =
discouraged in IETF circles because SASL "GSS-SPNEGO" is itself not well =
specified and multiple levels of negotiation leads to downgrade attacks. =
The general consensus in the IETF seems that application protocol =
clients (including LDAP clients) should use SASL mechanism negotiation =
to select mechanisms, whether GSS API based mechanisms or non GSS API =
based mechanisms. There is a general move on foot that all new SASL =
mechanisms be described as GSS API mechanisms, ala SCRAM.
-- Kurt=
13 years, 3 months
Re: FW: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by gcarter＠likewise.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Howard,
We are trying to make likewise-open packages available for Fedora
but they only want to pull OpenLDAP patches from upstream. So
I'm in a bit of a spot here. You've already accepted the lsap_bind_gssapi
patch, this one simply exposes the existing code.
Is it just the public ldap_bind_gssapi_s() signature that you
have an issue with? If, as you suggest, we give you a patch
that adds an LDAP_AUTH_GSSAPI flag to ldap_bind_s() but keep
the same (existing) ldap_bind_gssapi_s() internals, would that
be acceptable?
cheers, jerry
- --
Director of Engineering http://www.likewise.com/
Likewise-CIFS http://www.likewiseopen.org/
"What man is a man who does not make the world better?" --Balian
On 6/2/10 12:10 AM, Scott Salley wrote:
>
>
>
> -----Original Message-----
> From: Howard Chu [mailto:hyc@symas.com]
> Sent: Tue 6/1/2010 6:07 PM
> To: Scott Salley
> Cc: openldap-its(a)openldap.org
> Subject: Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
>
> ssalley(a)likewise.com wrote:
>> Full_Name: Scott Salley
>> Version: HEAD
>> OS: Linux
>> URL:
> http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-de...
>> Submission from: (NULL) (67.51.54.234)
>>
>>
>> Note that a similar issue/contribution was submitted in 2008
> (Contrib/5369) and
>> appears to have been 'lost'.
>
>> The patch
> http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-de...
>> makes it possible to use the GSSAPI support in OpenLDAP by:
>>
>> 1. Defining --with-gssapi in configure which
>> a. Checks for appropriate header files
>> b. Checks for the appropriate library
>> c. Defines HAVE_GSSAPI to 1 in everything is in order
>>
>> 2. Exposing ldap_gssapi_bind_s in ldap.h
>
> I am still disinclined to publish any of this. The standard mechanism for
> using GSSAPI in LDAP is via SASL. I see no benefit to propagating more
> non-standard one-off ldap_XXX_bind flavors. It's a poor design approach
> and it
> increases our support workload for no appreciable gain. It increases
> application developer's workload as well, if they have to test for the
> existence of multiple flavors of ldap_XXX_bind and code for them each
> separately in their apps.
>
> If you really want to have "direct" access to other authentication
> mechanisms,
> the right way to do this is by adding new LDAP_AUTH_xxx definitions that can
> be muxed out from a single ldap_bind API. Of course, by the time you've
> implemented option parsing so that generic client code can be configured
> with
> arbitrary Bind mechanisms, you would have re-implemented SASL.
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFMBj/7IR7qMdg1EfYRAjmcAKC1MyKit8TKa1W96cZ2Uh3Cdm/EMACeJtbu
9/F8j8UQJ5C3X0sW5LytRq8=
=tkYo
-----END PGP SIGNATURE-----
13 years, 3 months
Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru
* alexs(a)ulgsm.ru <alexs(a)ulgsm.ru> [2010-01-19 07:25:25 +0000]:
> * alexs(a)ulgsm.ru <alexs(a)ulgsm.ru> [2009-11-05 07:43:02 +0000]:
>
>
OpenLDAP 2.4.22, 8.1-PRERELEASE is still crashed.
>
>
> New OpenLdapd 2.4.21 on new freebsd 8.0 is still crashed.
> I can make a public test server, to let some one check my configs and
> see faults.
>
> Also intresting have any body same failures?
>
>
>
>
> > Full_Name: Aleksey
> > Version: 2.4.19
> > OS: Freebsd7.2
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (93.93.136.26)
> >
> >
> > Openldap 2.4.19 installed from freebsd ports. All configs in defauls
> > Freebsd 7.2 amd64
> > Slapd built with the "-g" flag and install with the make install STRIP=""
> >
> > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports.
> > In slapd config added using hdb as backend and indexes.
> >
> > Testing database consist of 1000 users accounts with minimum attributes.
> >
> > On stress test load slapd Segmentation fault in 10-30 sec.
> >
> >
> > #ldd /usr/local/libexec/slapd
> > /usr/local/libexec/slapd:
> > libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000)
> > liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000)
> > libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000)
> > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000)
> > libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000)
> > libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000)
> > libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000)
> > libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000)
> > libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000)
> > libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000)
> > libthr.so.3 => /lib/libthr.so.3 (0x8014dd000)
> > libc.so.7 => /lib/libc.so.7 (0x8015f5000)
> >
> >
> >
> >
> > #gdb /usr/local/libexec/slapd
> > (gdb) run -d 0
> > Starting program: /usr/local/libexec/slapd -d 0
> > [New LWP 100311]
> > [New Thread 0x801a020b0 (LWP 100311)]
> > [New Thread 0x801a02880 (LWP 100073)]
> > [New Thread 0x8034040b0 (LWP 100076)]
> > [New Thread 0x803404240 (LWP 100077)]
> > [New Thread 0x8034043d0 (LWP 100078)]
> > [New Thread 0x803404560 (LWP 100116)]
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x803404560 (LWP 100116)]
> > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address
> > 0x7ffffd9f9f38: Bad s.
> > ) at idl.c:511
> > 511 {
> > (gdb)
> > (gdb)
> > (gdb) where
> > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory
> > address 0x7ffffd9f9f38: dress.
> > ) at idl.c:511
> > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800,
> > txn=0x80352b040, k=0x8069005
> > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50
> > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040,
> > ava=0x7ffffda7a4f0,
> > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788
> > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000,
> > rtxn=0x80352b040, f=0x7ffffda7a550,
> > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154
> > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040,
> > flist=0x7ffffda7a5 f
> > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at
> > filterindex.c:581
> > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000,
> > rtxn=0x80352b040, f=0x7ffffda7a530,
> > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204
> > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040,
> > flist=0x7ffffda7a5 f
> > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at
> > filterindex.c:581
> > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000,
> > rtxn=0x80352b040, f=0x7ffffda7a570,
> > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c:
> > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30,
> > e=0x7ffffda7a71 tx
> > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206
> > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at
> > search.c:586
> > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at
> > search.c:366
> > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at
> > search.c:217
> > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70,
> > arg_v=0x803521000) at connection
> > .c:1123
> > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12)
> > at connection.c:125
> > 9
> > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from
> > /usr/local/lib/libldap_r-2.4.so.
> > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3
> > #16 0x0000000000000000 in ?? ()
> > Error accessing memory address 0x7ffffdbfb000: Bad address.
--
alexs
13 years, 3 months
Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org
On Jun 2, 2010, at 1:08 AM, hyc(a)symas.com wrote:
> ssalley(a)likewise.com wrote:
>> Full_Name: Scott Salley
>> Version: HEAD
>> OS: Linux
>> URL: =
http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def=
ine-have-gssapi.patch
>> Submission from: (NULL) (67.51.54.234)
>>=20
>>=20
>> Note that a similar issue/contribution was submitted in 2008 =
(Contrib/5369) and
>> appears to have been 'lost'.
>=20
>> The patch =
http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def=
ine-have-gssapi.patch
>> makes it possible to use the GSSAPI support in OpenLDAP by:
>>=20
>> 1. Defining --with-gssapi in configure which
>> a. Checks for appropriate header files
>> b. Checks for the appropriate library
>> c. Defines HAVE_GSSAPI to 1 in everything is in order
>>=20
>> 2. Exposing ldap_gssapi_bind_s in ldap.h
>=20
> I am still disinclined to publish any of this. The standard mechanism =
for=20
> using GSSAPI in LDAP is via SASL. I see no benefit to propagating more=20=
> non-standard one-off ldap_XXX_bind flavors. It's a poor design =
approach and it=20
> increases our support workload for no appreciable gain. It increases=20=
> application developer's workload as well, if they have to test for the=20=
> existence of multiple flavors of ldap_XXX_bind and code for them each=20=
> separately in their apps.
I concur and add: At one time I thought it might be useful to implement =
a few SASL mechanisms directly in libldap for cases where one didn't =
want to suck in a SASL library. But for most mechanisms removing the =
SASL library is worth it in my eyes, especially any mechanism other than =
PLAIN or EXTERNAL. But where this is worth it, it should be done =
through existing APIs. Adding mech specific APIs should be avoided.
>=20
> If you really want to have "direct" access to other authentication =
mechanisms,
> the right way to do this is by adding new LDAP_AUTH_xxx definitions =
that can=20
> be muxed out from a single ldap_bind API.
I could see adding new API to support new authentication frameworks to =
which LDAP was extended to support. For instance, if LDAP was extended =
to directly support GSS API mechanisms, then adding LDAP_AUTH_GSSAPI =
would make sense (here GSS API refers to the GSS API not the SASL =
Kerberos mechanism called GSSAPI). But for security reasons, it =
unlikely this will ever happen,
=20
> Of course, by the time you've=20
> implemented option parsing so that generic client code can be =
configured with=20
> arbitrary Bind mechanisms, you would have re-implemented SASL.
>=20
> --=20
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>=20
>=20
13 years, 3 months
Re: (ITS#6536) Autogroup overlay enhancement
by hyc＠symas.com
raphael.ouazana(a)linagora.com wrote:
> Full_Name: Raphael Ouazana
> Version: 2.4.21
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/raphael-ouazana-autogroup-100427.patch
> Submission from: (NULL) (213.41.232.151)
>
>
> Hi,
>
> The attached patch allow the autogroup overlay to handle correctly the attr part
> of the URL ldap://dc=example,dc=com?attr?sub?(filter). Before this patch, the
> attr part was simply ignored. Now the group entry is populated by the values of
> the attribute attr in the resulting entries.
>
> Implementation details:
> Some cases (modify, delete) are harder to handle when you store values instead
> of dn. In this cases the overlay try to detect if groups have been modified and
> then simply refresh them. This can cause performance hits if the search
> specified by the URL deals with an important number of entries.
>
> Legal notice:
> This patch file is derived from OpenLDAP Software. All of the modifications to
> OpenLDAP Software represented in this following patch were developed by Raphael
> Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to
> any
> license of Linagora.
>
> The attached modifications to OpenLDAP Software are subject to the following
> notice:
> Copyright 2010 Raphael Ouazana, Linagora
> Redistribution and use in source and binary forms, with or without
> modification,
> are permitted only as authorized by the OpenLDAP Public License.
The code patch looks OK to me, but could you also provide a patch for the
README file summarizing this new behavior? I'm not too keen on supporting
groups of anything other than DNs in general, but I see the usefulness of it.
However the potential performance hit can be quite a concern.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 3 months
