Re: Keytab MEMORY in error message
Perhaps lib/krb5/keytab.c:krb5_kt_get_entry around line 372 should have: 371 krb5_kt_get_name (context, id, kt_name, sizeof(kt_name)); 372 krb5_enctype_to_string(context, enctype, enctype_str); if (kt_name[0] == '\0') strcpy(kt_name, MEMORY); 373 374 if (kvno) 375 snprintf(kvn... Otherwise you get: Failed to find [EMAIL PROTECTED](kvno 1) in keytab (des-cbc-crc) as opposed to the superior: Failed to find [EMAIL PROTECTED](kvno 1) in keytab MEMORY (des-cbc-crc) I'm splitting these issues. For the first one, will using krb5_kt_get_full_name() instead be acceptable to you ? Love
Re: Keytab MEMORY in error message
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 [EMAIL PROTECTED] 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
Re: Keytab MEMORY in error message
On Fri, 9 Feb 2007 12:28:40 +1100 Love Hörnquist Åstrand [EMAIL PROTECTED] wrote: Perhaps lib/krb5/keytab.c:krb5_kt_get_entry around line 372 should have: 371 krb5_kt_get_name (context, id, kt_name, sizeof(kt_name)); 372 krb5_enctype_to_string(context, enctype, enctype_str); if (kt_name[0] == '\0') strcpy(kt_name, MEMORY); 373 374 if (kvno) 375 snprintf(kvn... Otherwise you get: Failed to find [EMAIL PROTECTED](kvno 1) in keytab (des-cbc-crc) as opposed to the superior: Failed to find [EMAIL PROTECTED](kvno 1) in keytab MEMORY (des-cbc-crc) I'm splitting these issues. For the first one, will using krb5_kt_get_full_name() instead be acceptable to you ? Sure. -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/
Re: Keytab MEMORY in error message
On Fri, 9 Feb 2007 12:41:40 +1100
Love Hörnquist Åstrand [EMAIL PROTECTED] wrote:
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 [EMAIL PROTECTED] 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.
Don't know. MS servers require padata so I think this might happen with
gss_acquire_cred which could be pretty common. If I run into again I
make a note of the use-case specifics and bring it up again.
Mike
--
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/
