Howard Chu wrote:
This sounds redundant to me, given that OpenLDAP interfaces to GSS thru SASL. If this code belongs anywhere at all, it's in the SASL library. As for the mechanism itself - we've only recently excised all the other non-standard/obsolete Bind mechanisms from our code base. If Microsoft wants to publish some RFCs/specs for these other mechs, then maybe it'd be OK to incorporate. But until then, to me it just feels like pollution.
LDAP_AUTH_NEGOTIATE is at the API level only; it's equivalent to doing ldap_sasl_interactive_bind_s() for GSS-SPNEGO (assuming, of course, your SASL and GSS-API implementations support SPNEGO). (This assertion probably does not apply to some of the other Microsoft-specific mechanisms which possibly predate SASL.)
If the code belongs anywhere at all, it's actually as a loadable GSS-API pseudo-mechanism: not in the LDAP library, not in the SASL library, not even in the GSS-API library itself. But few operating systems have their act together sufficiently to ensure this is the case. So having a lightweight implementation that avoids Cyrus SASL is perhaps not a bad thing.
In debating the merits of this, we should be careful to separate overloading ldap_bind_s() with LDAP_AUTH_NEGOTIATE from the actual implementation of GSS-SPNEGO. The first issue is a question of maintaining existing API conventions; the latter one of modularity.
-- Luke