gss_acquire_cred failing with no keytable entry found
amritanshu at gmail.com
Tue Nov 28 01:37:11 EST 2017
Greg many thanks! that worked I have used suggestion 2. I think it's best
for me to stick to MIT documentation than google for every API and take the
first link. :)
I will try other bits, the gssalloc failure was determined using a
printf on that line as well. The code actually goes very far for an invalid
Many thanks again.
On Tue, Nov 28, 2017 at 11:38 AM, Greg Hudson <ghudson at mit.edu> wrote:
> On 11/28/2017 12:41 AM, Amritanshu wrote:
> > GSS-API error acquiring credentials: No key table entry found matching
> > dell-vostro-155.domain.in/domain.in@ (39756033, 39756033, 0x025ea101)
> > The service_name passed is "gss/dell-vostro-155.domain.in at domain.in".
> It looks like this code is importing a krb5 principal name, but with a
> name type indicating a GSS host-based service name. (gss_nt_service
> name is more properly spelled GSS_C_NT_HOSTBASED_SERVICE; I'm not sure
> why the Microsoft documentation is using the archaic identifier.)
> You can do one of the following:
> 1. Don't import a name or acquire creds. Pass GSS_C_NO_CREDENTIAL to
> gss_accept_sec_context() as the verifier cred handle. The client will
> be able to authenticate to any key in the keytab, so make sure the
> keytab doesn't contain extraneous entries. This is the approach
> recommended by most Kerberos developers.
> 2. Use the GSS_KRB5_NT_PRINCIPAL_NAME name type instead of
> gss_nt_service_name, in order to treat the imported name as a krb5
> principal name.
> 3. Use a GSS host-based service name instead of a principal name. The
> host-based service name might look like "gss at dell-vostro-155.domain.com"
> for this key (although "gss" isn't really a proper first component as it
> doesn't name a service protocol). With MIT krb5 1.10+, you can also
> just specify the first component ("gss" in this case), allowing the
> client to authenticate to any keytab entry matching that first component.
> For more, see
> particularly the "Name types" and "Acceptor names" sections.
> > I downloaded and compiled the bits set up traces and breakpoints in
> > bits while stepping through I found in krb5_gss_acquire_cred_from I see
> > name that is passed is invalid and the gssalloc fails because it is asked
> > to allocate a very large amount of memory.
> Did you build with optimization? You might be getting deceptive results
> from the debugger. If this were the case, you would see an "Out of
> memory" error instead of a "No key table entry found" error.
More information about the Kerberos