""Danilo Almeida"" <[EMAIL PROTECTED]> wrote in message 000d01c1ba41$6a916a80$[EMAIL PROTECTED]">news:000d01c1ba41$6a916a80$[EMAIL PROTECTED]... > 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 _______________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
