On Wed, 2008-05-14 at 11:20 -0700, Noriko Hosoi wrote:
Thank you for the background info and suggestions, Howard and
We are thinking auto-bind could be useful for some type of applications
and trying to make it co-existing safely with the current features.
Here is the summary of the changes:
436388 (Item 1): --enable-autobind is supported. Unless it's set, the
auto-bind code is not compiled in.
436390 (Item 2): I updated the previous proposal based upon the
feedbacks: now auto-bind is executed only from the bind code and when
the client explicitly sends the SASL/EXTERNAL request to the server. On
the server side, it's disabled, by default. To enable it,
nsslapd-ldapiautobind needs to be set to "on" by an administrator.
Having these changes, e.g., this search request is authenticated as
Directory Manager if it's launched by a super user.
# ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-<ID>.socket
-b "cn=config" "(cn=*)"
If the EXTERNAL request is not passed, it's bound as anonymous.
436400 (Item 3): Currently, dse.ldif stores extra configuration
attributes only necessary for auto-bind, by default. They should not be
there unless auto-bind is enabled.
Your comments would be greatly appreciated.
This looks much better.
If the client explicitly sends the SASL EXTERNAL bind, then this is a
desirable feature, and should (subject to ACLs and some configuration
that maps from unix to directory identities) work, preferably in the
default build (but perhaps, like OpenLDAP, without gaining any useful
privileges unless enabled by configuration).
I don't have any objection to SASL EXTERNAL binds, when described as
such. Howard and I have both objected to the concept, as described in
the wiki page, of AutoBind, where contrary to the spec, requests are
authenticated implicitly, without that SASL EXTERNAL bind.
In short: SASL EXTERNAL is the right way to do this, if you do it this
way, the objections go away.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.