Mike Friedman <[email protected]> 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? ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
