On Mon, Aug 27, 2012 at 11:32 AM, Derek Warren <[email protected]> wrote: > Okay, since (quite understandably) nobody wants to touch my earlier > NFSv4/AD/Kerberos question, here's a simple one: > > Given a working Kerberos environment where I can kinit -k HOST$ and add > a service principal: > > 1) What is a Kerberos context?
The word "context" here can be confusing. A "krb5_context" is a C programming language type -- defined by the MIT Kerberos API. A GSS-API "security context" is an abstract (and C) type in the GSS-API. The two kinds of contexts refer to entirely different things! A krb5_context is like a handle to a library. You initialize one and pass it to all functions in the API, which allows the library to put all state that would otherwise be global into a data structure that gets passed around. A GSS-API security context refers to the shared state that results after an exchange of "security context tokens", which are used to exchange key material and to authenticate. So a GSS-API security context refers to the authenticated names and exchanged session keys (among other things). A GSS-API security context is much more like a krb5_auth_context in the MIT Kerberos API, and it's not at all like a krb5_context. Now, to make things even more confusing: we typically use Kerberos through the GSS-API, so we might refer to a "Kerberos security context", in which case we really mean "a GSS-API security context for the Kerberos mechanism". I'm going to assume that you meant "GSS context", not "Kerberos context". > 2) Why would rpc.gssd on the client be unsuccessful in creating a > Kerberos context? Depends on which kind of context you really meant. Assuming you meant "GSS security context"... it could be lots of things. Nico -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
