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.

- Danilo


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of Mike Frisch
Sent: Wednesday, February 20, 2002 9:37 AM
To: [EMAIL PROTECTED]
Subject: New cred cache breaks Win2k service

With the recent changes to the Kerberos Credentials Cache, my service on
Windows 2000 is now broken.  Without being able to use impersonation,
how do I allow a Windows 2000 service to perform Kerberos/GSS operations
on behalf of other users?

Thanks in advance,

Mike.


_______________________________________________
Kerberos mailing list
[EMAIL PROTECTED]
http://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to