GSS-API error gss_accept_sec_context: Request ticket server HTTP/ not found in keytab

[Kerberos Enthusiast]

Hi Greg,

Thanks for the response.

Still getting this error with gss_acquire_cred ():

*GSS-API error gss_accept_sec_context: d0000: Unspecified GSS failure.
Minor code may provide more information *
*GSS-API error gss_accept_sec_context: 186a5 : Request ticket server
HTTP/krbsite.krb.local at KRB.LOCAL not found in keytab (ticket kvno 4)*

Sequence of gss apis call for this kerberos authentication :
            krb5_gss_register_acceptor_identity();
            gss_import_name();
            gss_acquire_cred();
            gss_accept_sec_context();

*Note : After merging both keytab files this issue did not occured.*

>>
When using gss_acquire_cred_from()  in place of gss_acquire_cred() getting
below error :

One additional argument in gss_acquire_cred_from() that is
"*gss_const_key_value_set_t
cred_store"* where specified keytab name when acquiring credentials.
Is there any loop (upto count no.) needed to run for
multiple authentication requests for different services ?

*GSS-API error gss_acquire_cred_from: d0000 : Unspecified GSS failure.
Minor code may provide more information *
*GSS-API error gss_acquire_cred_from: 25ea101: No key table entry found
matching HTTP/**krbsite.krb.local@*

It seems file based keytab is not updated for every kerberos
authentication call.

Is the gss_acquire_cred_from() call still required to call
krb5_gss_register_acceptor_identity or not ?

Thanks,


On Sat, 12 Nov 2022 at 00:14, Greg Hudson <ghudson at mit.edu> wrote:

> On 11/11/22 10:33, Kerberos Enthusiast wrote:
> > It seems, if multiple servers supply separate keytabs, then the
> > subsequent kerberos auth request targeted for multiple kerberos servers
> > with separate keytabs and application keep on
> > updating "default_keytab_name" global variable and it causes some of the
> > authentication requests to fail and it throws this error
>
> There is no global variable named default_keytab_name in MIT krb5.
> There is a krb5.conf configuration variable with this name, but it is
> never changed by the GSS or Kerberos libraries.
>
> > *"GSS-API error gss_accept_sec_context: Request ticket server HTTP/ not
> > found in keytab" *(major code - 186a5, d0000)
>
> This message is a little bit puzzling, because the principal name
> ("HTTP/") is incomplete, and because the message of this form in the
> code includes a parenthetical about the ticket kvno.
>
> > Using this api *krb5_gss_register_acceptor_identity() *to set the default
> > keytab file for kerberos authentication.
>
> This function sets a thread-specific global variable.  It should work to
> invoke it before each call to gss_acquire_cred(), or before each call to
> gss_accept_sec_context() using the default acceptor credential.  Or:
>
> > Can we use any other gss_api to maintain the local context of the keytab
> > file and send this keytab for every authentication request?
>
> gss_acquire_cred_from() allows the caller to specify a keytab name when
> acquiring credentials.  See:
>
>
> https://web.mit.edu/kerberos/krb5-latest/doc/appdev/gssapi.html#credential-store-extensions
>