> > Unless I misunderstand your e-mail, the hacking of krbcc that you > > did is the kind of thing we do not want to see happening. Instead > > of having your service connect to krbcc32s directly, you should > > just > connect to your client and just have it give creds to the > > service. > > I considered that approach and rejected it as not being the way I > wanted to go. To make this work I could have done it one of two > ways that I can think of. I could either have used RPC/COM to the > client for every single Kerberos call which required access to the > ticket cache or I could have grabbed the client tgt and shoved it in > my own cache and gone from there. I rejected the second approach > since I know of no way to make that work with the Kerberos 4 > libraries and be able to service requests for multiple users at the > same time. The only way I know of to make it work would be to clear > out the ticket cache every time I need to do a switch to a different > client session. While that would be possible to implement it would > be ugly and the performance hit for having to clear out the cache so > often just wouldn't be pretty. Proxying all the Kerberos calls via > RPC/COM to the client session wouldn't have been too bad to > implement for K4 since there aren't many calls that need wrapping > but would get nastier once k5/gssapi support gets done later. The > effort of wrapping all the calls into the kerberos library is far > more than the effort of just making the kerberos libraries willing > to talk to other processes. Proxying an entire gssapi > authentication session between the service and the client process > would just not be pretty. > > I decided it would be a lot cleaner to just allow my service to > switch the kerberos libraries to the correct ticket cache for the > user. It isn't a very large change to the kerberos libraries to > make it work and seemed a lot cleaner.
You can switch ticket cache names in both krb4 and krb5. With krb4, you can use krb_set_tkt_string(). With krb5, you can use krb5_cc_set_default_name(). Just keep each user's creds under a different cache name. That way, you can use different sets of creds w/o having to proxy the krb4, krb5 or gssapi calls. > We've been working against KfW 2.1 though I'm going to work on > getting us up to the latest version. The problems we've seen are > with both krbcc and krbv4w32. The problem is that both of those > DLLs would end up forcing the ticket cache server to start which > we've seen cause various problems. It looks like your changes fix > the krbcc problems but krbvrw32 still calls cc_initialize which is > going to result in the RPC server being launched from dll main. I'll look into the krbv4w32.dll issue. - Danilo ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
