Howard Chu wrote:
You are right if you think that SASL with GSSAPI support should do that stuff. But firstly the SASL/GSSAPI code in openldap seems to support only the authentication part if you try to connect to something like an MS Active Directory Controller. After authentication is done successfully it seems so that integrity and confidential protection part via SASL/GSSAPI will be switched off.....hmmmmm. Secondly it seems so that Cyrus SASL code does not support SSF larger than 56 for GSSAPI based signing/encryption (aka integrity/confidential protection). But tickets from an AD are encrypted by default with RC4-HMAC which is SSF of 128. Additionally when I set the option "SASL_SECPROP minssf=128" this does not work with GSSAPI and I never get working communication with AD if GPO "Domain controller: LDAP server signing requirements" is turned on. Tests with DES encrypted tickets does not work too if that option is switched on.mikbec wrote:Patch related to "(ITS#6110) GSSAPI signing/encryption for unsuspectingly applications" is more an enhancement than a bug report.That's fine, patches are supposed to be tracked in ITS anyway.However, it seems to me that these patches are duplicating functionality that's already provided by SASL/GSSAPI. On that basis I'm inclined to
But if ldap_gssapi_bind_s() can be used then communication works well.
reject them. I'm beginning to regret including the ldap_gssapi_bind_s() function as well; that is totally nonstandard and duplicates functionality that has been available in the standard API for over 8 years.At this point I think it can be one decision to wait till someone corrects Cyrus SASL stuff related to GSSAPI mechanism because this is the mostly used free SASL implementation. In contrast to GNU SASL (libgsasl) seams not to be an alternative for that issue at this time because it gots only partial support for GSSAPI. The part "integrity or confidentiality protection in GSSAPI mechanism" is currently not implemented (found that info on http://www.gnu.org/software/gsasl/manual/gsasl.html). Another decision can be to provide a compatibility hook via ldap_sasl_interactive_bind_s() so clients get that problem temporary work but without changing the API of openldap and without recompiling of client applications. And at some day when GNU SASL implements that feature (I think no one will do that for Cyrus SASL) this hook can be removed again.
I really don't know what is the right decision....hmmm.
Please have a look at patch onftp://ftp.openldap.org/incoming/mike-becher-090512.libraries-libldap.patchor ITS report on http://www.openldap.org/its/index.cgi/Incoming?id=6110;selectid=6110 In short that patch: 1) adds call of ldap_gssapi_bind_s() at the beginning of ldap_sasl_interactive_bind_s() which can be turn on or off by an GSSAPI OPTION (manual update of ldap.conf (5) included) to provide GSSAPI signing/encryption for applications that use (and only know) ldap_sasl_interactive_bind_s(), 2) adds the missed implementation of "switch off" functionality of all other GSSAPI OPTIONS. 3) corrects one string length problem in guess_service_principal() and 4) corrects one hostname resolving problem in guess_service_principal(). Sorry for that kind of announcement but I hope now it is on the right mailing list. best regards Mike