New cred cache breaks Win2k service

[Danilo Almeida]

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.

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?

- Danilo

-----Original Message-----
From: kerberos-admin at MIT.EDU [mailto:kerberos-admin at MIT.EDU] On Behalf
Of Marc Reyhner
Sent: Friday, February 22, 2002 12:57 AM
To: kerberos at mit.edu
Subject: Re: New cred cache breaks Win2k service

""Danilo Almeida"" <dalmeida at mit.edu> wrote in message
news:000d01c1ba41$6a916a80$1b011212 at mit.edu...
> This is by design.  As I recall, the original problem was this:
>
> A process doing impersonation cannot start a program as the user being
> impersonated because the process level tokens are the service's and
not
> the user's.
>
> Therefore, the service cannot start the creds cache process.  So, if
the
> user does not already have the creds cache process, the service not be
> able to access the cache.  Granted, there are no creds in the cache,
but
> what if the service is trying to stuff some creds in there?
>
> In order to avoid any such weirdness as to under what impersonation
> circumstances the creds cache may or may not work, I chose to
circumvent
> the whole issue by disallowing access to the user's cache when doing
> impersonation.
>
> I can revisit this if someone puts forth a good proposal for how
things
> should work.
>
> However, in the meantime, services doing impersonation need to
> communicate creds via some other mechanism that is appropriate for the
> service in question (e.g. LRPC).
>
> For more information, look at the release notes in the KfW 2.1.2
source
> distribution.

I've got a solution more or less working that I've written to support
the
Stanford S/Ident protocol and to make our Kerberized POP/IMP proxy work
in a
Terminal Server environment.  For our mailproxy we have users set their
mail
server to be the localhost and then we have a service which proxies
there
POP or IMAP session to the campus mail servers after first using
Kerberos to
authenticate the connection.  To make this work with Windows Terminal
Services (and XP Fast User Switching) we've had to write an NT service
which
listens on the correct ports and when a connection comes in figure out
which
user session it belongs to.  Once we've figured out which user session
it
belongs to we connect to the ticket cache for that user and authenticate
the
connection.  If they don't currently have a TGT then we use a COM event
sink
to get have our client running in the client session prompt them for
their
credentials.  To make this work our NT service needs to be able to
switch
back and forth between different ticket caches as connections come in.
What
I did to solve my problem was to add the local system account to the ACL
for
the kerberos ticket cache and add support into the ticket cache client
for
talking to a ccache server in a different security context.  I did not
attempt to solve the impersonation problem since I'm running this
service as
local system.  Local system can already do whatever it wants on the
machine
so you don't lose any secure by adding it to the ACL for the ticket
cache.

On the client side I added methods to the krbcc32.dll for disconnecting
from
the ticket cache RPC server as well as connecting to a server with a
specific RPC endpoint name.  I also changed krbbc32 to not attempt to
connect the RPC server until cc_initialize is called.  This serves the
double purpose of not starting the RPC server when I start my server
process
as well as removing the problems we've seen with DllMain calling things
that
it shouldn't and sometimes causing problems.  In krbvrw32.dll I added
new
entry points for disconnecting and reconnecting from the ticket cache as
well as also delaying initializing the ticket cache until its actually
needed.  Our services are currently Kerberos 4 only so I haven't tested
if
the krb5 dll works without any modifications.  I don't think any
modifications to make it work would be that hard since the design is a
lot
cleaner than the kerb 4 implementation.

I'm more than happy to submit my changes back for addition into KfW once
I
get a chance to clean them up a bit.  The code is working fine in my
testing
though it could do with a bit of polishing up.

Marc