[19940] in Kerberos_V5_Development
Re: gss_store_cred_into() and gss_acquire_cred_from() on a client
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu May 23 18:30:57 2019
To: moore moore <moore_chestnut@yahoo.ie>, "krbdev@mit.edu" <krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <ea5122b0-ddb2-81ec-97db-814243d44c33@mit.edu>
Date: Thu, 23 May 2019 18:30:44 -0400
MIME-Version: 1.0
In-Reply-To: <1009790862.8405534.1558647360292@mail.yahoo.com>
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On 5/23/19 5:36 PM, moore moore wrote:
> So, if I simply change the cred_usage to GSS_C_INITIATE ( it was BOTH),
> I get a slightly different error from gss_acquire_cred_from()
>
> Retrieving clientuser1@TEST.COM from
> FILE:/krb5/dest/var/krb5/user/0/client.keytab (vno 0, enctype 0) with
> result: 2/Key table file '/krb5/dest/var/krb5/user/0/client.keytab' not
> found
>
> So it is still looking for a keytab and I'm not sure how or why.
It's normal for gss_acquire_cred() to check the client keytab if it
doesn't find credentials in the ccache, so this trace message isn't the
reason why the operation is failing. Look for ccache operations earlier
in the trace output.
> gss_store_cred_into() uses:
[...]
> [18869] 1558646982.419342: Storing proxyuser@TEST.COM ->
> krbtgt/TEST.COM@TEST.COM in MEMORY:clientuser1@TEST.COM
>
> Does that prove it is going into a MEMORY ccache?
Yes.
The same process is handling the gss_store_cred_into() and the later
gss_acquire_cred_from(), right?
> I do have cred usage on the gss_store_cred_into() as BOTH also, but I
> also tried with GSS_C_INITIATE
GSS_C_INITIATE is correct, but in the current implementation there isn't
a behavior difference.
> On the second point, I tried to store the "user_cred_handle" which is
> the output the call to gss_acquire_cred_impersonate_name() but that
> would not go into the store either.
>
> There is nothing in the trace but the local logging error gives:
>
> gss_store_cred_into: No credentials were supplied, or the credentials
> were unavailable or inaccessible
That's GSS_S_NO_CRED. By my reading of the code, gss_store_cred_into()
only returns that if its input_cred_handle is null (aka
GSS_C_NO_CREDENTIAL). Can you double-check that you aren't passing a
null handle when you get this error?
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
