""Danilo Almeida"" <[EMAIL PROTECTED]> wrote in message 004601c1bbd1$f9f07950$[EMAIL PROTECTED]">news:004601c1bbd1$f9f07950$[EMAIL PROTECTED]... > Marc, > > 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. > However, I am interested in the DllMain() problems you have been seeing. > There were fixes to some DllMain() problems in krbcc put into KfW 2.1.1. > What version of KfW and which DllMain() are you talking about (krbv4w32 > or krbcc)? What problems were you having? 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. Marc ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
