gss_acquire_cred failing with no keytable entry found

Amritanshu amritanshu at
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
name provided.
Many thanks again.

On Tue, Nov 28, 2017 at 11:38 AM, Greg Hudson <ghudson at> wrote:

> On 11/28/2017 12:41 AM, Amritanshu wrote:
> > GSS-API error acquiring credentials: No key table entry found matching
> gss\/
> > (39756033, 39756033, 0x025ea101)
> > The service_name passed is "gss/ at".
> 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"
> 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
> libgss
> > bits while stepping through I found in krb5_gss_acquire_cred_from I see
> the
> > 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 mailing list