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: Mon, 14 Jun 2010 10:26:35 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)

Johan Larsson <address@hidden> writes:

> I'm using GSASL in an application running as well on Fedora as on Windows
> XP, where I in the latter case build it with mingw. I'm in the process of
> adding support for using Kerberos tickets in the application.

Hi, and thanks for your interest.  Looks like an interesting project!

> My idea is that I use a Kerberos authentication application, such as the MIT
> Network Identity Manager on Windows, to retrieve ticket granting tickets. My
> application links with a GSSAPI library, and when I use SASL, my hope is
> that if I choose to use the "GSSAPI" mechanism the result would be that the
> GSSAPI implementation retrieves the correct ticket granting ticket from the
> local credentials cache (kept by the Kerberos authentication application),
> communicates with the ticket granting server and gets a service ticket that
> I can use in communication with the service I want to use.

It should work, but there is a gap right now -- I don't know where the
MIT Network Identity Manage on Windows stores the tickets.  So
Shishi/GSS/GSASL won't find them.

You should be able to get it to work if you use the 'shishi' command
line tool to acquire tickets, however if you want a graphical interface,
there is none right now.

> On Linux, this works great and exactly as I was hoping. First I run the MIT
> "kinit" application, which gets me a ticket (confirmed by calling "klist").
> In my application, I use GSASL as the SASL implementation, and when I run
> the application with a valid ticket in the ccache, GSASL hides all the magic
> of calling the GSSAPI, finding the correct TGT, communicating with the TGS
> and retrieving the service ticket. So from my applications point of view
> there is no real difference between using e.g. DIGEST-MD5 and GSSAPI.

Excellent.  However, then you are most likely linking GNU SASL with
MIT's GSS-API library because by default GNU GSS does not read the MIT
ticket file.  It is on my todo list to make that happen, and it isn't
very complicated (we have the parser for the file format already) but
the glue to make it happen hasn't been added yet.

You can convert a MIT ticket file to a Shishi ticket file by invoking
the 'ccache2shishi' tool.  If the tickets are stored in a file on
Windows, that tool should be able to convert the tickets on Windows as
well, but you probably will need to supply the path yourself (in case it
isn't the same as under GNU/Linux).

> In Windows I use the Gnu GSS version 0.1.5 implementation of GSSAPI, built
> with mingw. When I start my application, it links with the "libgss-1.dll"
> library and GSASL confirms that it supports the GSSAPI mechanism. However,
> running the exact same code as in Linux, calling GSASL with the required
> property values, I no longer get data to send to the service server, but
> instead I get an error, and no network communication (with the TGS/kdc)
> seems to have been attempted by the GSSAPI.

Right.  This is likely what happens under GNU/Linux too, if you link GNU
SASL with GNU GSS, and don't run 'ccache2shishi'.

> My question is if I can use GSASL+Gnu GSS, built on mingw, to find locally
> cached TGT and retrieve an associate service ticket on Windows XP, and if
> this requires any special Kerberos authentication client (such as or instead
> of MIT Network Identity Manager), any special configuration and/or any
> special way of building the GSASL and/or Gnu GSS libraries (right now I
> simply do "configure"+"make"+"make install").

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*.

> If GSASL and/or Gnu GSS cannot be used to retrieve locally cached TGT:s on
> Windows XP, what SASL and/or GSS implementations should they be replaced by,
> and where can these be found?

You could also try linking GNU SASL with MIT's GSS-API library.  If they
have a Windows version, and it knows where to find the tickets, it
should work directly.

> Is there a GSS dll available, compatible with the Gnu GSS dll interface,
> that I can use instead of the libgss-1.dll generated when I build the Gnu
> GSS library, to get the behavior I want?

Any GSS-API library should be compatible here.  GNU SASL supports
natively the GSS-API libraries from GNU GSS, Heimdal and MIT Kerberos.

/Simon



reply via email to

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