ssalley@likewise.com wrote:

Full_Name: Scott Salley Version: HEAD OS: Linux URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defin... 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-defin... 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.