On Wed, 6 Mar 2013, Thomas Sondergaard wrote: > I am upgrading a Windows application of ours to depend on kfw-4.0.1. It > works but there is one problem: > > With kfw-3.2.2 it works without the need for shipping krbcc32s.exe, but > with kfw-4.0.1 it only works if it can start ccapiserver.exe and after > the application shuts down ccapiserver.exe keeps running. > > I assume that krbcc32s.exe and ccapiserver.exe are equivalent services.
Yes. They are helper processes to support the "API:" credentials cache type, a fancier version of the "MEMORY:" cache type which is available to more than one process. krb5cc32s.exe serves the ccapi version 2, and ccapiserver.exe servers the ccapi version 3. > Is there a way to prevent ccapiserver.exe from being needed with kfw-4.0.1? The 'MIT Kerberos.exe' appliation requires the presence of a ccapiserver, though this might be avoidable with a patched source tree. (The ticket manager application periodically iterates all available credentials to update the display, and if the ccapiserver is absent a warning dialog pops up each time, that krb5_cccol_cursor_next failed.) If you do not need to use the ticket manager application, it is possible to avoid the ccapiserver. > We actually have two applications that are built against kfw-3.2.2 and > one of them do need krbcc32s.exe, while the other doesn't. The one that > doesn't sets KRB5CCNAME to a file. Could that be why it doesn't need > krbcc32s.exe? Your insight is correct. As the helper process is only needed to support the "API:" credentials cache family, if a different type of credentials cache is used, the helper is not needed. The KRB5CCNAME environment variable will work for this, as will the registry key HKCU\Software\MIT\Kerberos5\ccname (or HKLM if neither of the others are set). -Ben Kaduk _______________________________________________ kfwdev mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/kfwdev
