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@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 <ghud...@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 > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos