Problems with Heimdal Module for PAM
Hi,
I am having some problems with the Heimdal module for PAM. I'm getting
the following in /var/log/{syslog,authlog} when performing 'su - matt'
as matt.
Feb 8 15:50:58 chromium sudo: pam_krb5: pam_sm_authenticate(sudo
matt): pam_get_data(): ccache data already present
Feb 8 15:50:58 chromium sudo: pam_krb5: pam_sm_authenticate(sudo
matt): exit: failure
Feb 8 15:51:25 chromium sudo: pam_krb5: pam_sm_authenticate(sudo matt): entry:
Feb 8 15:51:28 chromium sudo: pam_krb5: pam_sm_authenticate(sudo
matt): exit: success
Feb 8 15:51:28 chromium sudo: pam_krb5: pam_sm_authenticate(sudo matt): entry:
Feb 8 15:51:30 chromium sudo: pam_krb5: pam_sm_authenticate(sudo
matt): pam_get_data(): ccache data already present
Feb 8 15:51:30 chromium sudo: pam_krb5: pam_sm_authenticate(sudo
matt): exit: failure
pam_authenticate: Authentication service cannot retrieve authentication info.
I can kinit as matt just fine. Sudo su - matt as root works, but it
spits out an error about not being able to get authentication
information. I have tested this out on the KDC as well as one client,
and it works nowhere.
Does anyone have any thoughts?
Best,
Matt
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: Does this happen in the new mechglue too?
The issue was that trying to acquire a credential could result in a redundant AS-REQ. It turned out to be lib/mechglue/g_acquire_cred.c:gss_acquire_cred was looping over all mechanisms. The problem was that with SPNEGO it did KRB5 twice, once for KRB5 mech and once through SPNEGO mech calling KRB5. I added a clause that checked for mech-mech_type == GSS_SPNEGO_MECHANISM to skip that mech (unless it was explicitly specified). Please consider this condition wrt the new mechglue code if necessary. After a fast read though of the code it looks like this could still happen in the new mech-glue code. This is the second issue with gssapi mech-glue layer hides too much from SPNEGO. I need figure out the implications of this (split or merged mech-glue/SPNEGO). Love
Re: Detect when KRB5CCNAME changes for certain server scenarios
8 feb 2007 kl. 16.14 skrev Michael B Allen: Please consider the below patch. This will cause krb5_cc_set_default_name to be called if KRB5CCNAME changes at all. It assumes getenv returns the same address but if it does not the code is at least correct. Shouldn't all inputs that changes the default name affect the probe function Right now that is KRB5CCNAME and uid of the process. Also, if you use a static variable, you need to use a pthread mutex. In this case I don't think it would matter much, but better be safe. 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/
Re: Detect when KRB5CCNAME changes for certain server scenarios
On Fri, 9 Feb 2007 12:35:22 +1100 Love Hörnquist Åstrand [EMAIL PROTECTED] wrote: 8 feb 2007 kl. 16.14 skrev Michael B Allen: Please consider the below patch. This will cause krb5_cc_set_default_name to be called if KRB5CCNAME changes at all. It assumes getenv returns the same address but if it does not the code is at least correct. Shouldn't all inputs that changes the default name affect the probe function Right now that is KRB5CCNAME and uid of the process. Not if KRB5CCNAME is allowed to change at runtime. Consider a single threaded server that authenticates a client and calls setenv(KRB5CCNAME=deleg/ccache1) and then calls gss_init_sec_context to authenticate with second server. That will trigger context-default_cc_name to be set. Then a second client is authenticated and calls setenv(KRB5CCNAME=deleg/ccache2). Again gss_init_sec_context is called but now context-default_cc_name will *not* be set and the *wrong* ccache file will be used. Also, if you use a static variable, you need to use a pthread mutex. In this case I don't think it would matter much, but better be safe. True. I think on some archs you can get a bus error or similar. Considering the error scenario is largely specific to GSSAPI the proper fix would be to have GSSAPI call krb5_cc_set_default_name whenever it detects a change in KRB5CCNAME. Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/
