Regarding Credential Cache

[Mohit Aggrawal]

HI Ben,

Createprocess() is succeeding for me in the find_server()  function.  The
real issue in in

*if (!status) {
            status = WaitForSingleObject(hEvent, (SECONDS_TO_WAIT)*1000);
It is returning 258 means timeout
            status = RpcMgmtIsServerListening(ccs_request_IfHandle);*
and above api is returning 1715 i.e. RPC_S_NOT_LISTENING

in the debugger output I am getting the message as
"The RPC server is unavailable."

It looks to me that  the server is not reachable .

Also the krb5_cc_default is returning KRB5_FCC_INTERNAL
which means "The name of the default credential cache cannot be obtained"

Please let us know if we are missing any env variables  for setting the
credential cache.??
or  is there any difference in the way we use latest version (3) of CCAPI.

-Many Thanks
     Mohit


On Thu, May 30, 2013 at 8:30 AM, Benjamin Kaduk <kaduk at mit.edu> wrote:

> On Wed, 29 May 2013, Mohit Aggrawal wrote:
>
>  Thanks Benjamin for the details.I have debugged the code and our analysis
>> is as follows
>>
>> we have build and copies the Kerberos library in our windows system so the
>> registry value are not initialized . I have debugged the code
>> of function *krb5_cc_default_name* and find out that we are checking the
>> environment variable* **KRB5_ENV_CCNAME* and if it is not set then we are
>> calling function *get_from_os* and *get_from_os_buffe*r . In which we are
>>
>> checking the registry values HKCU and HKLM and if they are not present
>> then
>> we are initialing the *os_ctx->default_ccname* name as* API:krb5cc*.
>>
>> After that as shown in code snippet we are passing the default_name value
>> *
>> API:krb5cc*  to *krb5_cc_resolve*  and after debugging this function I
>> have
>> found out that* **find_serv*er  function in file client.cxx line no 383 is
>> failing and after debugging the * find_server* function
>> I found that   *sWaitForSingleObject(hEvent, (SECONDS_TO_WAIT)*1000);*  is
>> returning 258 and function  *RpcMgmtIsServerListening(ccs_**
>> request_IfHandle);
>> * is returning 1715 . In the stack unwinding phase * **
>> cci_os_ipc_thread_init* in file *ccapi_os_ipc.cxx *is returning 1813 which
>>
>> is passed on to the other higher layers and at last returned by  function
>> krb5_cc_default.
>> I have checked the system error codes which gives it's meaning as
>> *ERROR_RESOURCE_TYPE_NOT_**FOUND.
>> *Do i need to configure or set and resource for kerberos 1.11.??
>>
>> I have also observed that the* endpoint* parameter in the*
>> find_server*function is taking value as
>> *krbcc.999.0.ep* is it correct ??
>>
>>
>> Since we were using the kerberos library 1.5.3 previously and now we are
>> upgrading it to 1.11 . Please let me know if we need to do some extra
>> configuration and setting for kerberos 1.11.
>>
>
> Thank you for these details, I actually had not traced through the code
> path for this case previously.  I am sorry that I did not note in my
> previous mail that the API: cache type relies on inter-process
> communications and a separate process ccapiserver.exe to actually hold the
> credentials in-memory (see src/ccapi/server/win).  It had not fully sunk in
> the extent of the customization of your build that you may not have this
> binary available in the PATH.
> Within find_server(), this separate process is supposed to be created at
> bRes = CreateProcess(szExe, ...).
> In a non-DEBUG build, this should cause the subsequent cci_debug_printf("*
> *CreateProcess returned %d; LastError[...]",...) to print to the running
> terminal (if available).  Running the application in question from cmd.exe
> should suffice to see these print statements.
> Given what you have sent already, I find that the most likely explanation,
> and again I am sorry I did not mention it sooner.
> If CreateProcess() is succeeding we will need to dig harder.
>
> The 1.11 code should be using the CCAPI version 3, whereas the 1.5
> codebase would have been using an older version of the CCAPI, which I
> believe had a different mechanism for storing credentials (in a companion
> process).  That work predates my involvement, unfortunately.
>
> -Ben
>