[email protected] wrote: > Full_Name: Scott Salley > Version: HEAD > OS: Linux > URL: > http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch > 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-define-have-gssapi.patch > 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/
