[19789] in Kerberos_V5_Development
Re: Multiple KDC's realm heuristic for KRB5CCNAME=DIR:/tmp/mydir/
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Jul 25 16:23:12 2018
To: Martin Gee <geemang_2000@yahoo.com>, "krbdev@mit.edu" <krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <d7e47fb2-9df2-b93f-0380-add32e220768@mit.edu>
Date: Wed, 25 Jul 2018 16:22:58 -0400
MIME-Version: 1.0
In-Reply-To: <1137891485.2337371.1532545441648@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 07/25/2018 03:04 PM, Martin Gee wrote:
> I'd like to use the automatic ccache creation that
> gss_acquire_cred_* does. gss_acquire_cred is failing with a custom
> keytab location/name.
Have a look at:
http://web.mit.edu/kerberos/krb5-latest/doc/basic/keytab_def.html#default-client-keytab
The client keytab is located separately from the server keytab.
> Seems gss_acquire_cred only works when /etc/krb5.keytab is present.
I wouldn't expect gss_acquire_cred() to use /etc/krb5.keytab unless one
of the locators for the client keytab was explicitly set to point to it.
So this and the corresponding attempts to use /etc/krb5.keytab in the
trace logs are confusing to me. Precisely what GSS calls are being traced?
> I've tried these:
> export
> KRB5_KTNAME=/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab
> setenv("KRB5_KTNAME",
> "/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab",
> 1)
> krb5_gss_register_acceptor_identity("/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab");
These all set the server keytab location.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
