[16052] in Kerberos_V5_Development
Re: Windows future
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Aug 12 19:26:35 2010
From: Sam Hartman <hartmans@mit.edu>
To: Jeff Blaine <jblaine@kickflop.net>
Date: Thu, 12 Aug 2010 19:26:18 -0400
In-Reply-To: <4C645EC5.1070900@kickflop.net> (Jeff Blaine's message of "Thu,
12 Aug 2010 16:51:17 -0400")
Message-ID: <tslpqxns99h.fsf@mit.edu>
MIME-Version: 1.0
Cc: Stephen C Buckley <sbuckley@mit.edu>, "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
I assume you're generally familiar with SSPI.
Today, SSPI provides you with a way to get GSS-API. You need to either
be part of a domain, be willing to store your password in a service
called credman, or modify your application to explicitly pass the
password into the SSPI calls.
On the server, you need to either be part of a domain or explicitly pass
a password into the acceptor for each application.
There's nothing quite like krb5_rd_cred, krb5_mk_cred, krb5_mk_priv,
krb5_rd_priv, krb5_mk_safe, or krb5_rd_safe.
Support for multiple accounts is not as well developed as KFW.
There is no API compatibility with MIT.
There are a few things you can do with GSS-API that you cannot do with
SSPI, mostly surrounding gap/out of order tokens. If you use SSPI's
facilities for handling sequencing, you cannot process missing tokens in
a UDP protocol.
That's my rough understanding of the current state.
--Sam
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev