Greetings,

I am having a problem with kcheckpass and Kerberos.

I have Kerberos installed and working on SL3, SL4 and SL5. Everything
works, except kcheckpass under a special condition.  I only use Kerberos
to manage passwords. Using an account with its password in the Kerberos
database, I can:
        
        1) Create either a KDE or Gnome session
        2) ssh into a remote machine
        3) su to the Kerberos account
        4) su to root from the account
        
When I start a KDE session, both a Kerberos V4 and V5 ticket gets
created. klist displays the correct principal, and all looks and works
fine at this point. If I lock the screen, all is still fine. The trouble
happens when I use Kerberos to get a ticket for a different realm;
needed in order to get an AFS token for a remote site. At this point
kcheckpass (the KDE screen authenticating program) fails to unlock the
screen. xscreensaver does not have this problem. I have compiled and
installed pam_krb5 2.3.2 on a SL4 machine. I added some extra debugging
code to pam_krb5 and it appears to me that the error occurs when
kcheckpass/pam_krb5 tries to store new V5 credentials. It does a check
to see if the two principals are the same (the one stored in the cache
and the one that kcheckpass is using to authenicate the user) This fails
because a different Kerberos ticket was created for the other Kerberos
realm; Kerberos can only manage tickets for 1 realm at a time. Turning
on debugging in pam_krb5 produces the output:

Oct  7 10:50:21 backup01 kcheckpass: pam_krb5[5984]: flags: forwardable
renewable
Oct  7 10:50:21 backup01 kcheckpass: pam_krb5[5984]: flag: ignore_afs
Oct  7 10:50:21 backup01 kcheckpass: pam_krb5[5984]: flag: user_check
Oct  7 10:50:21 backup01 kcheckpass: pam_krb5[5984]: flag: krb4_convert
Oct  7 10:50:21 backup01 kcheckpass: pam_krb5[5984]: flag: warn
Oct  7 10:50:21 backup01 kcheckpass: pam_krb5[5984]: ticket lifetime: 0
Oct  7 10:50:21 backup01 kcheckpass: pam_krb5[5984]: renewable lifetime: 
0
Oct  7 10:50:21 backup01 kcheckpass: pam_krb5[5984]: minimum uid: 1
Oct  7 10:50:21 backup01 kcheckpass: pam_krb5[5984]: banner: Kerberos 5
Oct  7 10:50:21 backup01 kcheckpass: pam_krb5[5984]: ccache dir: /tmp
Oct  7 10:50:21 backup01 kcheckpass: pam_krb5[5984]: keytab: /etc/krb5.ke
ytab
Oct  7 10:50:21 backup01 kcheckpass: pam_krb5[5984]: called to update
credentials for 'drjohn'
Oct  7 10:50:21 backup01 kcheckpass: pam_krb5[5984]: _pam_krb5_sly_refres
h
returning 3 (Error in service module)

The part of pam_krb5 code that produces the return code PAM_SERVER_ERR
is: 

        if (krb5_cc_get_principal(ctx, ccache, &princ) == 0) {
                if (krb5_principal_compare(ctx, princ,
                                           userinfo->principal_name) ==
 FALSE) {
                        krb5_free_principal(ctx, princ);
                        krb5_cc_close(ctx, ccache);
                        return PAM_SERVICE_ERR;
                }
                krb5_free_principal(ctx, princ);
        }

/etc/pam.d/system-auth contains:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_krb5.so minimum_uid=1
auth        sufficient    /lib/security/$ISA/pam_unix.so try_first_pass
likeauth nullok
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 
quiet
account     required      /lib/security/$ISA/pam_permit.so

password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_autht
ok
md5 shadow
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_krb5.so

I can get around the problem by doing a kdestroy before getting the
second Kerberos ticket, but that seems like a kluge that users will not
like. The consequences of forgetting to do it are a locked session. I
must doing something special because a google search for
"_pam_krb5_sly_refresh returning 3" turns up zero hits. Any hints or
help will be greatly appreciated.

        Thank you,
        doug