Hello Kerberos,

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


*"GSS-API error gss_accept_sec_context: Request ticket server HTTP/ not
found in keytab" *(major code - 186a5, d0000)

Using this api *krb5_gss_register_acceptor_identity() *to set the default keytab file for kerberos authentication.

It seems to be a single global keytab file used by the krb5 library.
Can we use any other gss_api to maintain the local context of the keytab
file and send this keytab for every authentication request?

Thanks,

On Fri, 11 Nov 2022 at 19:20, Kerberos Enthusiast < [email protected]> wrote:

Hello Kerberos,

I am trying to make a windows client authenticate with an authentication server(using AD machine for KDC) to access multiple services.
There is a multiple keytab file per authentication server.

But I'm facing this error below, while this does not occur every time, it occurred when sending multiple authentication requests (around 200
requests) for the same service from different client machines while users
are already domain users.

*GSS-API error gss_accept_sec_context: Request ticket server HTTP/ not
found in keytab*
Probability of this issue occurring is around 20% only.

Using GSS-API to acquire cred : gss_acquire_cred().
For loading keytab file : krb5_gss_register_acceptor_idennntity().

How can we resolve this?
Can we use any other GSS-API in place of this?

Thanks,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: [email protected]

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: [email protected]

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/[email protected] 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 <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)