ccapiserver required, but krbcc32s was not

[Benjamin Kaduk]

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