*Excellent* error message missing from newer krb5-libs versions...

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

*Excellent* error message missing from newer krb5-libs versions...

Spike_White
All,
I'm not a KRB5 professional; I'm a devops guy.  And former software developer.
A co-worker & I just spent a couple of wks doing a deep-dive. On an obscure failure on Kerberized SSH SSO.  (We have Kerberized SSH SSO working throughout enterprise, only on 1-2 servers do we get an error.  Only on cross-domain, it works intra-domain.)
Entire error returned by SSHD in debug mode was:  Wrong principal in request
Which was no help; we looked at the user principal early on.  All good.  Also, this user principal works on other servers.
Finally, I was debugging on an older krb5-libs version and it told this:
(gdb) print *context
$28 = {magic = -1760647388, in_tkt_ktypes = 0x0, in_tkt_ktype_count = 0, tgs_ktypes = 0x0, tgs_ktype_count = 0,
  os_context = {{magic = -1760647387, time_offset = 0, usec_offset = 0, os_flags = 0, default_ccname = 0x0}},
  default_realm = 0x0, profile = 0x2aaaaad64c30, db_context = 0x0, ser_ctx_count = 0, ser_ctx = 0x0, clockskew = 300,
  kdc_req_sumtype = 7, default_ap_req_sumtype = 7, default_safe_sumtype = 8, kdc_default_options = 16,
  library_options = 1, profile_secure = 0, fcc_default_format = 1284, scc_default_format = 1284, prompt_types = 0x0,
  udp_pref_limit = -1, use_conf_ktypes = 0, profile_in_memory = 0, libkrb5_plugins = {files = 0x0}, vtbl = 0x0,
  locate_fptrs = 0x0, preauth_plugins = {files = 0x0}, preauth_context = 0x0, err = {code = -1765328240,
    msg = 0x2aaaaad6aa20 "Wrong principal in request (found host/[hidden email]<mailto:host/[hidden email]>, wanted host/[hidden email]<mailto:host/[hidden email]>)", scratch_buf = '\000' <repeats 1023 times>}}

Which *immediately* identified the problem!
Wrong principal in request (found host/[hidden email]<mailto:host/[hidden email]>, wanted host/[hidden email]<mailto:host/[hidden email]>
The server had formerly (incorrectly) registered in the AMER domain, was now (correctly) registered in the APAC domain.
I attempted to reproduce this meaningful error message on a newer Kerberos version, unable to do so.  All I could reproduce was original terse non-helpful error message (Wrong principal in request).
So here's the good code in krb5-1.6.1 that produces this meaningful error code.  (file is krb5-1.6.1/src/lib/krb5/krb/rd_req_dec.c):
static krb5_error_code
krb5_rd_req_decoded_opt(krb5_context context, krb5_auth_context *auth_context, const krb5_ap_req *req, krb5_const_principal server, krb5_keytab keytab, krb5_flags *ap_req_options, krb5_ticket **ticket, int check_valid_flag)
{
....
    if (server && !krb5_principal_compare(context, server, req->ticket->server)) {
        char *found_name = 0, *wanted_name = 0;
        if (krb5_unparse_name(context, server, &wanted_name) == 0
            && krb5_unparse_name(context, req->ticket->server, &found_name) == 0)
            krb5_set_error_message(context, KRB5KRB_AP_WRONG_PRINC,
                                   "Wrong principal in request (found %s, wanted %s)",
                                   found_name, wanted_name);
        krb5_free_unparsed_name(context, wanted_name);
        krb5_free_unparsed_name(context, found_name);
        retval =  KRB5KRB_AP_WRONG_PRINC;
        goto cleanup;
    }

It's the krb5_set_error_message() call that sets this wonderfully-descriptive error message.  Here's the analogous code from krb5-1.12.1 :
static krb5_error_code
rd_req_decoded_opt(krb5_context context, krb5_auth_context *auth_context,
                   const krb5_ap_req *req, krb5_const_principal server,
                   krb5_keytab keytab, krb5_flags *ap_req_options,
                   krb5_ticket **ticket, int check_valid_flag)
{
...
    if (!krb5_principal_compare(context, (*auth_context)->authentp->client,
                                req->ticket->enc_part2->client)) {
        retval = KRB5KRB_AP_ERR_BADMATCH;
        goto cleanup;
    }
...
As you can see, that excellent krb5_set_error_message() call has been stripped out.
Can that useful & descriptive error message be put back in please?
BTW, read the email archive (since 2002!).  Understand about krb5_set_error_message() vs localization/auditing, don't think this omission is part of some grand scheme.
I think it's just an oversight, as I'm getting descriptive error messages for other situations.  Here's an example of a constructed descriptive error string (in krb5-1.12.1).
debug1: Unspecified GSS failure.  Minor code may provide more information
Key table file '/etc/krb5.keytab' not found

Specific keytab file name plugged into format string.
Spike
PS Like this guidance ([hidden email] Tue Oct  5 22:26:22 2010):

Functions can also set extended error messages using
    krb5_set_error_message() (or, in dependencies of libkrb5,
    krb5int_set_error() on &context->err).  Code should set extended
    error messages when an error condition is moderately likely to
    occur and the default string for the error code is insufficiently
    clear.


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: *Excellent* error message missing from newer krb5-libs versions...

Greg Hudson
On 04/27/2014 01:49 PM, [hidden email] wrote:
>             krb5_set_error_message(context, KRB5KRB_AP_WRONG_PRINC,
>                                    "Wrong principal in request (found %s, wanted %s)",
>                                    found_name, wanted_name);
[...]
> As you can see, that excellent krb5_set_error_message() call has been stripped out.
> Can that useful & descriptive error message be put back in please?

Two big things have changed in krb5_rd_req since 1.6: server principal
aliases[1] in 1.7 and flexible acceptor names[2] in 1.10.  Because of
these features, it's not as simple as adding back a simple diagnostic
like the one in 1.6.

But I agree that the current error result is much less helpful than it
should be, given how often administrators have to diagnose ticket
decryption failures.  I have put together a candidate patch series which
I hope will make it easier to diagnose of ticket decryption failures.
It is at:

    https://github.com/krb5/krb5/pull/108

but it may change significantly before it is pushed to the master branch.

[1] http://k5wiki.kerberos.org/wiki/Projects/Aliases
[2] http://k5wiki.kerberos.org/wiki/Projects/Acceptor_Names
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: *Excellent* error message missing from newer krb5-libs versions...

Spike_White
Excellent work!

Any extra clues that help us harried sysadmins in diagnosing Kerberos-related misconfigurations would be greatly appreciated.  Just today, I've had to diagnose & fix 4 different unrelated server and/or principal misconfigurations.

Luckily, none as obscure as this first one.

Spike

-----Original Message-----
From: Greg Hudson [mailto:[hidden email]]
Sent: Monday, April 28, 2014 4:12 PM
To: White, Spike; [hidden email]
Subject: Re: *Excellent* error message missing from newer krb5-libs versions...

On 04/27/2014 01:49 PM, [hidden email] wrote:
> krb5_set_error_message(context, KRB5KRB_AP_WRONG_PRINC,
> "Wrong principal in request (found %s, wanted %s)",
> found_name, wanted_name);
[...]
> As you can see, that excellent krb5_set_error_message() call has been stripped out.
> Can that useful & descriptive error message be put back in please?

Two big things have changed in krb5_rd_req since 1.6: server principal aliases[1] in 1.7 and flexible acceptor names[2] in 1.10. Because of these features, it's not as simple as adding back a simple diagnostic like the one in 1.6.

But I agree that the current error result is much less helpful than it should be, given how often administrators have to diagnose ticket decryption failures. I have put together a candidate patch series which I hope will make it easier to diagnose of ticket decryption failures.
It is at:

https://github.com/krb5/krb5/pull/108

but it may change significantly before it is pushed to the master branch.

[1] http://k5wiki.kerberos.org/wiki/Projects/Aliases
[2] http://k5wiki.kerberos.org/wiki/Projects/Acceptor_Names
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev