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.
Anyone else have comments?
-------- Original Message -------- Subject: Re: Likewise has added GSS-SPNEGO support to openldap libraries Date: Sat, 26 Jan 2008 23:17:18 +1100 From: Luke Howard lukeh@padl.com Organization: PADL Software Pty Ltd To: Krishna Ganugapati krishnag@likewisesoftware.com CC: Howard Chu HYC@symas.com References: A4670A1B9F4A714DA683071F29FC5A390C0402B8@ms08.mse3.exchange.ms
Hi Krishna,
Sounds good! The standard procedure is to file an ITS at:
and then the OpenLDAP team will review it. I still might have commit access. :-)
I think the OpenLDAP team would want to consider how adding LDAP_AUTH_NEGOTIATE (which isn't a new authentication method at the protocol layer) would interact with the existing implementation of ldap_sasl_interactive_bind_s(). I personally have no problem with the MSDN APIs but the team may prefer to keep the existing API usage.
regards,
-- Luke
Krishna Ganugapati wrote:
Luke,
I wanted to let you know that we’ve added support for the LDAP_AUTH_NEGOTIATE option to support GSS-SPNEGO in the open-ldap libraries. I’d contracted with Sernet to do this work and the work was done by Stefan Metzmacher of Sernet. We have this support in our own tree right now and it is super cool.
See here for details http://msdn2.microsoft.com/en-us/library/aa366156.aspx
The advantage is that if you want to make authenticated requests to Active Directory, it is a piece of cake as opposed to having to negotiate gss contexts yourself. If you get a tgt from a AD domain controller, you can seamlessly connect to AD directories.
I’d like to get this in to the open-ldap source base. I notice that you (your company) partners with Symas and the open-ldap team. Could I impose on you to make introductions? I think they will be more inclined to accept the code when they realize that this work has been done by Sernet (Volker Lendecke’s company) on contract to Likewise and we at Likewise are delighted to push this upstream. I completely understand if you would not be comfortable doing so.
By the way, our team has ported the dce-rpc libraries to just about every platform possible and we plan to release it back to the community very soon. We’re also going to release our libnetapi libraries which provide a API level compatibility with most of the Net APIs
Best regards,
Krishna
*Krishna** Ganugapati* Vice President, Engineering
*T* 425.378.7887 x241 *F* 425.484.6316 *M* 425.736.1076 *E* _krishnag@likewisesoftware.com mailto:krishnag@likewisesoftware.com_
15395 SE 30th Place, Suite 140 Bellevue, WA 98007 *_www.likewisesoftware.com http://www.likewisesoftware.com/_**__*
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
On Mon, Jan 28, 2008 at 12:53:37PM +1100, Luke Howard wrote:
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.
The current code implements another SASL module as a separate source file (gssapi.c). Generic parts of SASL code in cyrus.c have been moved to sasl.c and thus enabled adding gssapi.c. Entire GSS-API conversation is however dependent on system installed gss libraries. I have one issue to sort out and will file ITS asap.
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.
I have one issue to sort out and will file ITS asap. I just don't want to waste your time spent on reviewing if there's a bug.
cheers,
-
Howard Chu -
Luke Howard -
Rafal Szczesniak