Unexpected return codes from KDC -- krb5-1.6.3

[Tom Yu]

Mike Friedman <mikef at berkeley.edu> writes:

> This is a 'sequel' to my earlier postings about getting bad return codes 
> from the KDC.  However, I've moved from a binary Linux distribution to a 
> FreeBSD port of MIT Kerberos and my symptoms are a bit different, so I'm 
> starting a new thread.
>
> My problem is this:
>
> I'm using programs based on the MIT API to do authentication, via 
> get_in_tkt_with_password (or get_in_tkt_with_keytab), krb5_mk_req, 
> krb5_rd_req. (This is perl code using the Authen::Krb5 module, which I've 
> been running for a couple of years on my production 1.4.2 system).

The get_in_tkt APIs are deprecated in favor of the get_init_creds
APIs.  I know that this fact is probably not well-documented.

> If I have a principal that has any of the following set, then, even if I 
> supply the correct password, I get back a return code of 31 (decrypt 
> integrity check), instead of the more specific return code that would 
> correspond to the specific situation:
>
>    CLIENT_NOT_FOUND
>    CLIENT EXPIRED
>    REQUIRED PWCHANGE
>    CLIENT KEY EXPIRED
>
> But if none of the above is true, then my authentication succeeds (RC=0) 
> if I supply the correct password, and fails with the expected RC=31 if I 
> enter an invalid password.

What error shows up in the KDC logs during those failure conditions?