New cred cache breaks Win2k service

[Marc Reyhner]

""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