Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
by michael@stroeder.com
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.
6 years, 2 months
Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
by rick@openfortress.nl
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
6 years, 2 months
Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
by quanah@symas.com
--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>
6 years, 2 months
Re: (ITS#8563) Documentation inconsistency for syncrepl for mdb
by quanah@symas.com
--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>
6 years, 2 months
Re: (ITS#8562) Typos in the documentation
by quanah@symas.com
--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>
6 years, 2 months
Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by michael@stroeder.com
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.
6 years, 2 months
Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by william.b.clay@acm.org
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).
6 years, 2 months
Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by michael@stroeder.com
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.
6 years, 2 months