krb5-1.6.1 problems (on RedHat) (was: AS_REQ Return code 60 for principal expired?)

Mike Friedman mikef at berkeley.edu
Tue Jan 13 13:16:55 EST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Now I'm having another problem with my 1.6.1 (RedHat Linux) test KDC.  It 
seems that if I set the REQUIRES_PWCHANGE attribute for a principal and 
try to authenticate with an invalid password, I get back a return code of 
31 ('decrypt integrity check failed'), instead of a 23 (password expired). 
The KDC log actually shows 'REQUIRED PWCHANGE' in the reply to the AS_REQ, 
yet I'm still getting a return code of 31!

(My code depends on the RC=23 to verify that the REQUIRES_PWCHANGE 
attribute is, in fact, set.  This code has been running successfully for 
years on earlier KDC versions, 1.4.2 currently, though not on Linux 
systems).

I should also mention that during the period of my testing, the following 
messages are scattered through the KDC logs:

     o Authentication attempt failed: <origin IP address>, GSS-API error strings are:
     o Unspecified GSS failure.  Minor code may provide more information
     o Unknown code kdb5 27
     o GSS-API error strings complete.

(Note that the first message does not end with any GSS-API error strings, 
so I assume they are null values).

It's hard for me to correlate each of the above messages with the specific 
actions I'm taking.  But for the most part all I'm doing is 
authentication, which involves an AS_REQ, followed by a TGS_REQ using a 
special host service principal set up for this purpose.

Just as with my other problem (see below), this doesn't happen on my 
production 1.4.2 system, using the same API code.

I suppose that in both cases I could be doing something wrong when I point 
to the 1.6.1 system instead of the 1.4.2 (production) KDC.  But since 
things work correctly on the former EXCEPT under the two conditions I've 
described thus far (expired principal and principal with 
REQUIRED_PASSPHRASE set), I'm suspicious that there's something amiss with 
the 1.6.1 system.

It may be a problem with how that KDC is configured, which is why I'm 
posting this, to get some ideas of what to look for.

Thanks.

Mike

====================================================================
On Mon, 12 Jan 2009 at 16:38 (-0800), Mike Friedman wrote:

> On Fri, 19 Dec 2008 at 14:35 (-0500), Tom Yu wrote:
>
>> Mike Friedman <mikef at berkeley.edu> writes:
>>
>>> I've been doing some testing of my programs that use the MIT API 
>>> against a KDC running 1.6.1 on a Linux system.  On all prior systems 
>>> where I've run a KDC, and according to the Kerberos docs, a principal 
>>> expired condition should set a return code of 1.  But on this test 
>>> system, it seems I'm getting back a 60, which the docs define as a 
>>> 'generic error'.
>>
>> I am unable to reproduce this condition.  Is the krb5-1.6.1 KDC 
>> possibly built using the --with-vague-errors option?
>
> Tom,
>
> Sorry for the delayed reply;  I was on vacation for 3 weeks during the 
> holiday period.
>
> I just ran a simple test, with my perl program that uses the MIT API for 
> authentication.  The results are very simple:
>
> 1.  If the principal has not expired, authentication succeeds.
>
> 2.  If the principal has expired, I get this error message from the KDC, 
> specifically when I'm doing a krb5_mk_req:
>
>     Generic error (see e-text)
>
> and a return code of 60.
>
> In the KDC log, for a failure, I see the following:
>
>  In response to the AS_REQ:
>    CLIENT EXPIRED: mikef at BERKELEY.EDU for krbtgt/BERKELEY.EDU at BERKELEY.EDU, Client's entry in database has expired
>
>  From the krb5_mk_req attempt:
>    PROCESS_TGS: authtime 0,  <unknown client> for krbproxy/oldsage.berkeley.edu at BERKELEY.EDU, No matching key in entry
>
> Yet, if the principal is not expired, I get this:
>
>  In response to the AS_REQ:
>    ISSUE: authtime 1231806450, etypes {rep=1 tkt=18 ses=1}, mikef at BERKELEY.EDU for krbtgt/BERKELEY.EDU at BERKELEY.EDU
>
>  Followed by,
>    ISSUE: authtime 1231806450, etypes {rep=1 tkt=18 ses=1}, mikef at BERKELEY.EDU for krbproxy/oldsage.berkeley.edu at BERKELEY.EDU
>
> i.e., success, which seems to imply that my service keytab is set up OK.
>
> Unfortunately, this KDC was installed using a RedHat Linux pre-compiled 
> RPM binary of MIT krb5-1.6.1, by someone other than me, so I can't 
> answer your question about the '--with-vague-errors' option (which I had 
> never heard of).
>
> Any ideas?
>
> Mike

_________________________________________________________________________
Mike Friedman                        Information Services & Technology
mikef at berkeley.edu                   2484 Shattuck Avenue
1-510-642-1410                       University of California at Berkeley
http://mikef.berkeley.edu            http://ist.berkeley.edu
_________________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkls2pcACgkQFgKSfLOvZ1TFAgCeIgFQ9QnTjLGYTe4AtpbEgsb6
FVAAnReDAdykAAruvqDoscb7KiBz3Ze+
=R0Bf
-----END PGP SIGNATURE-----



More information about the Kerberos mailing list