Jeffrey Altman <jalt...@secure-endpoints.com> writes: > As with any Kerberos based GSSAPI mechanism there needs to be a > credential cache. Even klog.krb5 uses a credential cache. It just > destroys the contents of the cache it creates after it is finished. The > difference is that klog.krb5 is capable of directly requesting the > afs[/<cell>]@<REALM> service ticket and does not need to first obtain a > TGT. When the GSSAPI krb5 mechanism is used, a TGT is always required. > The GSSAPI, being mechanism agnostic, does not provide a method to > obtain initial credentials.
The root of the problems around usability of GSSAPI with Kerberos are primarily that the integration between Kerberos and GSSAPI at a local configuration level (as opposed to the network protocol level) is frankly horrible. The GSSAPI Kerberos mechanism is a Kerberos client that wants to use a conventional Kerberos ticket cache, and a Kerberized application that's using GSSAPI is also a Kerberos client, but there's absolutely no mechanism in the GSSAPI API for them to communicate important details between then since all communication is forced through a mech-independent layer. It's not surprising that this is true, and it's fairly obvious why it's set up this way. However, it causes a wide variety of practical problems and makes working with GSSAPI occasionally very painful. You simply cannot do obvious and reasonable things that you would be able to do in a pure Kerberos application, such as avoid using a Kerberos ticket cache, reasonably share Kerberos credentials between the application and the GSSAPI library, reasonably override local Kerberos configuration for the GSSAPI Kerberos mechanism implementation, and so forth. You're forced into horrible hacks that aren't thread-safe and have unintended consequences. This isn't something that can be properly fixed in any one GSSAPI client application. It really needs API help from the GSSAPI layer to provide some sort of mechanism-specific escape route so that you can do some Kerberos-specific configuration of the GSSAPI library behavior. Some Kerberos GSSAPI implementations have some non-standardized APIs for doing some of this, but I've never found everything that I really wanted. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
