gss_accept_sec_context failing after getting service ticket usingservice name and password
gauravg77 at gmail.com
Wed May 31 05:08:48 EDT 2006
Here I am trying to use kerberos user-to-user authentication for my desktop
service. But GSSAPI does not support kerberos user to user authentication.
krb5_get_credentials (a kerberos call) does give me the credentials but from
this I need to derive (not get) the gssapi credentials. That is what I was
looking at. So, it is in that context that I was repeatedly talking of
getting the service key.
Thanks for the explanation.
On 5/29/06, Jeffrey Hutzelman <jhutz at cmu.edu> wrote:
> On Monday, May 29, 2006 02:16:23 PM +0530 Gaurav Gaba <gauravg77 at gmail.com
> > Hi Praveen,
> > I do not want to use the file based keytab approach.
> > I want to get the service key at runtime using the service principal and
> > its password. I do not want service key to be stored in a keytab file or
> > the need to move keytab file across the network.
> > Also, is there a way by which I can do away with the keytab mechanism
> > together?
> You keep talking about "getting the service key", as if you do not fully
> understand. There's nothing to "get" - services are not clients; they
> don't have to contact the KDC to get a ticket before they can do anything.
> The GSS-API spec unfortunately makes it look as though initiators and
> acceptors have the same sorts of credentials, but that is simply not the
> case. In Kerberos, a service doesn't have credentials at all; it has a
> service key which is used to decrypt tickets sent by a client.
> Most Kerberos GSS-API implementations of which I'm aware do not have any
> interface for providing a service key other than in a keytab. I can see
> how there are situations where you might want to prompt someone for a
> password, then use that to derive (not "get" -- this is a local operation)
> a service key rather than reading it from a keytab. However, that would
> require a mechanism-specific, implementation-specific interface whose use
> would destroy the portability of your application, and which current
> implementations do not provide in any event.
> In any event, it's usually not a good idea for a service to routinely
> require manual intervention such as typing a password in order to start.
> Further, unless you happen to be using a Windows KDC, Kerberos services
> normally don't _have_ passwords - they have randomly-generated keys, which
> are considerably stronger (Windows gets away with this for services by
> using randomly-generated passwords with similar strength, and not ever
> revealing them to humans - you can't type a computer account's password,
> because you don't know it).
> Maybe if you describe more of what you're trying to do, someone can
> a way to achieve what you need.
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
> Sr. Research Systems Programmer
> School of Computer Science - Research Computing Facility
> Carnegie Mellon University - Pittsburgh, PA
More information about the krbdev