Bug 142119

It would appear that turning on the requires_preauth attribute for the
user prevents login.

It doesn't fix anything though.   Turning debug on for pam in
/etc/krb5.conf gives me this when I log in:

Feb  7 11:21:44 sheep login: pam_krb5[2196]: configured realm
'UK.SCALIX.COM'
Feb  7 11:21:44 sheep login: pam_krb5[2196]: flags: forwardable
Feb  7 11:21:44 sheep login: pam_krb5[2196]: flag: no ignore_afs
Feb  7 11:21:44 sheep login: pam_krb5[2196]: flag: user_check
Feb  7 11:21:44 sheep login: pam_krb5[2196]: flag: no krb4_convert
Feb  7 11:21:44 sheep login: pam_krb5[2196]: flag: warn
Feb  7 11:21:44 sheep login: pam_krb5[2196]: ticket lifetime: 36000
Feb  7 11:21:44 sheep login: pam_krb5[2196]: renewable lifetime: 36000
Feb  7 11:21:44 sheep login: pam_krb5[2196]: banner: Kerberos 5
Feb  7 11:21:44 sheep login: pam_krb5[2196]: ccache dir: /tmp
Feb  7 11:21:44 sheep login: pam_krb5[2196]: keytab: /etc/krb5.keytab
Feb  7 11:21:44 sheep login: pam_krb5[2196]: authenticating
'jch.COM'to 'krbtgt/UK.SCALIX.COM.COM'
Feb  7 11:21:44 sheep login: pam_krb5[2196]:
krb5_get_init_creds_password(krbtgt/UK.SCALIX.COM.COM)
returned -1765328353 (Decrypt integrity check failed)
Feb  7 11:21:44 sheep login: pam_krb5[2196]: pam_acct_mgmt returning 0
(Success)

And since the decrypt integrity check fails it means I don't have a
kerberos key.   This is not terribly useful.

Does this still occur with the released version of RHEL4?

Yes, it behaves exactly the same.

I'm happy to help debug this if you want to get in touch directly.

You mention that removing the account management line allows you to log in
without a TGT.  How are you authenticating in that case?  Can you attach the
complete debug output?

Putting in NEEDINFO to reflect the current state of needing info from the reporter.

I can log in using telnet (well, krb5-telnet, which I enabled for the purpose. 
 Other than that I get this logged when I turn pam logging in /etc/krb5.conf:

Mar 15 11:32:05 sheep login: pam_krb5[6126]: configured realm 'UK.SCALIX.COM'
Mar 15 11:32:05 sheep login: pam_krb5[6126]: flags: forwardable
Mar 15 11:32:05 sheep login: pam_krb5[6126]: flag: no ignore_afs
Mar 15 11:32:05 sheep login: pam_krb5[6126]: flag: user_check
Mar 15 11:32:05 sheep login: pam_krb5[6126]: flag: no krb4_convert
Mar 15 11:32:05 sheep login: pam_krb5[6126]: flag: warn
Mar 15 11:32:05 sheep login: pam_krb5[6126]: ticket lifetime: 36000
Mar 15 11:32:05 sheep login: pam_krb5[6126]: renewable lifetime: 36000
Mar 15 11:32:05 sheep login: pam_krb5[6126]: banner: Kerberos 5
Mar 15 11:32:05 sheep login: pam_krb5[6126]: ccache dir: /tmp
Mar 15 11:32:05 sheep login: pam_krb5[6126]: keytab: /etc/krb5.keytab
Mar 15 11:32:05 sheep login: pam_krb5[6126]: authenticating
'jch.COM'to 'krbtgt/UK.SCALIX.COM.COM'
Mar 15 11:32:05 sheep login: pam_krb5[6126]:
krb5_get_init_creds_password(krbtgt/UK.SCALIX.COM.COM) returned
-1765328360 (Preauthentication failed)
Mar 15 11:32:05 sheep login: pam_krb5[6126]: pam_acct_mgmt returning 7
(Authentication failure)
Mar 15 11:32:05 sheep login: Authentication failure

I changed my (unix) password so that it's different from my kerberos password
and that lead me to what the problem actually is.

/etc/pam.d/system-auth has these lines (I've removed a lot of the detail in the
interests of clarity):

auth required pam_env
auth sufficient pam_unix
auth sufficient pam_krb5
auth required pam_deny

So, let's suppose I log in with my unix password (the one that's in
/etc/shadow): all the PAM authentication stops are pam_unix because that's
sufficient.   However, the account lines are like this:

account required pam_unix
account sufficient pam_if uid < 100
account required pam_krb5

(It's not exactly that, but the intent is the same.)  The problem now is that
the password that was supplied during authentication doesn't enable me to get a
TGT from the kerberos server so pam_krb5 fails and I don't get to log in.

If, on the other hand, I log in with my kerberos password (which is now
different from my unix password), the pam_unix authentication check fails, but
the pam_krb5 authentication check is sufficient and when I get through to the
account check I have a valid password and kerberos session and so I can obtain a
TGT.

I'm not 100% sure what's going on here since I haven't looked at what happens
when in the pam_krb5 code, but if my unix password and kerberos password are the
same then the account phase fails because I haven't been through pre-authentication.

Obviously if I remove the "account pam_krb5" line from /etc/pam.d/system-auth
then I'm only using kerberos for authentication and not for obtaining a key and
everything is fine.

Looking at an RHEL3 system I suspect that the same problem exists there but
since I rolled my own system-auth file when I ran RHEL3 I expect that the
problem didn't arise.

Looking at the password lines also explains while I was able to change my unix
password and not my kerberos password with "passwd" since the unix password
changing is marked as "sufficient".

I'm not sure what the right configuration is.   It definitiely seems wrong that
when I have a unix password that's the same as the kerberos password that I
can't log in.

For me on my laptop when I sometimes want to use kerberos authentication (so
that I have a TGT) and sometimes I want to use my laptop when the kerberos
server is unavailable I do want something different.  The RHEL3 configuration
was slightly better in that a "service_err" was ignored so it was possible to
achieve this.

To get around the immediate problem -- not being able to log in -- simply
swapping the pam_kr5b and pam_unix lines (and moving use_first_pass!) lets me
log in.   I'll be able to update this when I can see if I can still log in at
home when I don't have the kerberos server.

This should have been fixed by 2.1.8-1.  Please reopen this bug if you find that
it wasn't.