Re: Keytab "MEMORY" in error message

[Love Hörnquist Åstrand <lha@kth.se>]

8 feb 2007 kl. 15.49 skrev Michael B Allen:

> Also, I would like to mention a very very minor issue related to the
> message above.
>
> If lib/krb5/get_in_tkt.c:init_as_req is called with krb5_kt_get_entry
> as key_proc and it does not find the desired key, the enctype listed
> in the error message will likely (always?) be 'des-cbc-crc'. This is
> because it may search through archfour-hmac-md5, des-cbc-md5 and  
> finally
> des-cbc-crc. So because des-cbc-crc is always last, it is what always
> appears in the error text.
>
> Anyway, my thought is that this very common error is a little
> confusing. It's perfectly correct behavior but to an operator  
> debugging a
> program, it will be a little confusing. If I was using archfour- 
> hmac-md5
> and I saw 'des-cbc-crc' I would think that perhaps some keys were old
> or messed up somewhere.
>
> The ideal message IMHO would be something like:
>
>   Failed to find user@FOO.NET in keytab MEMORY with kvno 1 and enctype
>   archfour-hmac-md5, des-cbc-md5 or des-cbc-crc.
>
> I realize the state of the error is lost with each call to key_proc  
> but
> if you're remotely interested in a patch I think I could add something
> at the end of the if(preauth != NULL) { clause in init_as_req.
>
> I don't suspect you'll want to bother but I didn't think it could hurt
> to try :-)

I think you are right in that the error message should be better,  
however
doesn't this happen when you do optimistic pre-auth type selection.

Ie, if you use NULL or KRB5_PADATA_NONE this doesn't happen.

Love