help-gsasl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSASL+Gnu GSS on Windows


From: Simon Josefsson
Subject: Re: GSASL+Gnu GSS on Windows
Date: Tue, 15 Jun 2010 09:51:45 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)

Johan Larsson <address@hidden> writes:

> Thank you for your great reply, Simon. It contain a lot of valuable
> information.
>
>> What is missing is the glue to read the MIT ticket files in GSS/Shishi.
>> Just the information where the file is stored on Windows would help.  On
>> GNU/Linux it is stored in /tmp/krb5cc*.
>
> By default, the MIT ccache is in non-swappable memory in Windows, although
> you can force it to be written to disk.

Then GSS/Shishi would need to be able to read the tickets from memory as
well...  pointers on how to do this are appreciated, although I suspect
the priority should be to make it support the on-file variant first.

> As a test, since the GSSAPI is intended to be a standardized API, I removed
> the Gnu GSS "libgss-1.dll" mentioned above, and replaced it by the
> MIT-supplied "gssapi32.dll", renamed into "libgss-1.dll" (and included the
> rest of the MIT DLL:s in the path). The result was that when my application
> came to the point where it called the GSASL methods with the appropriate
> properties for the GSSAPI mechanism, the GSASL implementation managed to
> call those MIT GSSAPI DLL-routines, and the MIT Network Identity Manager was
> kicked into action, requested my authentication credentials, retrieved a TGT
> and then also retrieved exactly the service ticket I was asking for (it
> remained in the ccache until I killed it). Then my application crasched...
> But it feels like doable (maybe with a little communication with the MIT
> people) to get GSASL to work with MIT:s Windows GSSAPI-implementation.

Cool!  Yes, if you get that far, then certainly it is likely only some
minor issue causing the crash.

> One thing I was thinking about is that the information to GSASL contains the
> service hostname, while the ccache contains a TGT with the realm name. The
> only mapping between server-/domain name and realm is in the Kerberos
> authentication client configuration file. Does that mean that the Gnu GSS
> (on Linux) does not only retrieve the MIT ccache, but also parses the
> configuration file?

Right now it does not.  Once the functionality to parse ccache files has
been integrated, it should also read the configuration file.  There is
already a GNU Shishi configuration token 'read-krb5conf' for this:

# Read MIT or Heimdal configuration file for the following parameters:
#   default-realm
#   realm-kdc
#   server-realm
#   kdc-timeout
#   kdc-retries
# You can override these values by specifying alternate values below.
# Not implemented yet.
#read-krb5conf=/etc/krb5.conf

Hopefully I'll find some time to work on this during the summer...

/Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]