problems with making calls to gssapi32.dll on Windows XP

[Jeffrey Altman]

David Bienvenu wrote:

> Hi,
> 
> My name is David Bienvenu, and I work on mail&news for the Mozilla
> Foundation. I'm trying to make calls to gssapi32.dll from Mozilla code,
> to add MIT Kerberos support to Mozilla Mail and Thunderbird 

David:

I am very anxious to help you add support for dynamic recognition and
use of MIT KFW from within Mozilla's applications.

(My
> understanding is that using SSPI on Windows won't work with MIT's KDC,
> and I want to support MIT's KDC since I think that's widely used). 

It is not true that the SSPI is not compatible with MIT's KDC.  However,
there are many usage scenarios in which the SSPI is not the best choice
for end users.   The SSPI is most useful when the machine is joined to
an Active Directory domain.

MIT KFW is usable with client principals that do not have a relationship
to the credentials associated with the machine account.

> I
> took Mozilla's existing negotiateuth code (
> http://bonsai.mozilla.org/rview.cgi?cvsroot=/cvsroot&dir=mozilla/extensions/negotiateauth&module=default&rev=
> ) and flipped some makefile switches so that we'd use GSSAPI on Windows,
> like we do successfully for linux and mac. I had to add gssapi32 to the
> list of libraries we look for.  After that, our gssapi code found the
> right entry points and was able to call them successfully. But, the out
> parameters to those calls, e.g., gss_indicate_mechs_ptr, initially look
> OK, but as I execute code after the call, the values become corrupted,
> and we crash. For example, calling gss_release_oid_set_ptr crashes
> because the gss_OID_set mech_set either gets nulled out, or corrupted in
> weird ways. It's bizarre to step through the vc 6.0 debugger and
> eventually see the local variables change value even though the
> disassembled code doesn't change the local vars. I'm wondering if you
> have any idea what could be going on, or point me to someone who might
> know. I would suspect some sort of calling convention problem, but we're
> using the standard cdecl calling convention.

I'm not sure why you are seeing corruption.  However, I think the
preferred method for you to add support to Mozilla is to dynamically
detect the presence of gssapi32.dll and load function pointers utilizing
the loadfuncs routines we provide as part of the KFW SDK.

> The gssapi32.dll in windows/system32 has a version of 1.2.3.0, created
> 3/20/2002. 

Where did the gssapi32.dll in %windir%\system32 come from?   KFW does
not install DLLs into the %windir%\system32 directory.

I believe the Kerberos version is 2.1.2.0, which is what the
> institution I'm trying to help uses. I'm using the vc 6.0 dev tools, and
> we compile with fairly vanilla flags, /Zi, basically. This is a debug
> build of Mozilla.

The current version of KFW is 2.6.5.   The version of the gssapi32.dll
and krb5_32.dll are based upon the version number of the Kerberos 5
release on which they are based.   The most recent version is 1.3.5.

MIT KFW is built using the .NET 2003 compiler and is linked the 7.1 C
Run-time Libraries.

It sounds to me as if you are linking against one set of headers and
loading a conflicting set of DLLs.

NOTE: There is a long history of organizations forking the Kerberos
distribution and building localized versions.   This has frequently
resulted in DLLs with functions having different entry points in
different versions of the DLL.   This is one reason we recommend loading
functions with the loadfuncs routines as each function pointer is
loaded by name instead of by entry point.

In any case, I recommend that the organization you are helping take a
look at MIT KFW 2.6.5 and seriously consider distributing this version
unmodified to their user base.   KFW 2.6.5 provides support to use the
MSLSA credentials when available.  In addition, it is shipped with an
MSI that can be customized via a transform to suit the needs of the
local organization.

I would hope that the Mozilla Foundation would also desire to support
the standard supported releases of our tools and not those that are
either customized local builds or those that are seriously out of date.

Feel free to contact me directly.

Jeffrey Altman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2707 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20050722/25df0c33/attachment.bin