On Wed, 2008-05-14 at 11:20 -0700, Noriko Hosoi wrote: > Thank you for the background info and suggestions, Howard and Andrew. > > 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. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-directory-devel mailing list Fedora-directory-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
