[39157] in Kerberos
Re: GSS-API error gss_accept_sec_context: Request ticket server HTTP/
daemon@ATHENA.MIT.EDU (Kerberos Enthusiast)
Tue Nov 15 01:59:09 2022
MIME-Version: 1.0
In-Reply-To: <81516897-8535-0d62-ac52-3ffaf151d86f@mit.edu>
From: Kerberos Enthusiast <kerberos.enthusiast@gmail.com>
Date: Tue, 15 Nov 2022 09:12:05 +0530
Message-ID: <CAGshih_gaYUyR6mNE4AdDm-37AatrnMXRrK=yUvxuUZYr6MVdw@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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 <ghudson@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
