What I would do in your situation is kinit -c FILE:cachename -k -t FILE:keyfile
and then start your service with KRB5CCNAME set to FILE:cachename that is your best shot at ensuring that the cache is not accessed by other services. FILE:cachename should be in a directory that is only accessible to the program running kinit and the account that is being used to run your service. Jeffrey Altman Secure Endpoints Inc. [EMAIL PROTECTED] wrote: > Are there any special circumstances to be aware of for a Windows Service > to access a credentials cache which was created outside the context of the > service? > > I have a user running an application as a Windows Service. The service > eventually calls a cvs command which accesses the repository via ssh using > gssapi-with-mic authentication. > > The credentials cache needs to be created/renewed automatically, therefore > we will be calling kinit with a keytab/principal... probably with a > specific cache defined via KRB5CCNAME. > > There is no hook into the application service to call kinit so it must be > called external to the service. > > - Can the service be started using the "Local System account" or must it > be started as a specific user? > > - If KRB5CCNAME is defined as a "System Variable", will the service and > some other scheduled process be able to access the SAME credentials cache? > > - Does it matter what TYPE of credentials cache (API, FILE)? > > - If KRB5CCNAME is NOT defined... in other words both the service and > automated kinit will use the default value, will that make any difference? > ________________________________________________ > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
