New cred cache breaks Win2k service

[Marc Reyhner]

""Danilo Almeida"" <dalmeida at mit.edu> wrote in message
news:004601c1bbd1$f9f07950$1b011212 at mit.edu...
> 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