Bug 142119 - After configuring pam_krb, users can no longer log in
After configuring pam_krb, users can no longer log in
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: pam_krb5 (Show other bugs)
4.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-07 09:43 EST by John Haxby
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: 2.1.8-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-11 11:16:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Haxby 2004-12-07 09:43:37 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020
Firefox/0.10.1

Description of problem:
After using system-config-authentication to configure Kerberos for
login, no one who has a Kerberos principal name can log in any more.

kinit works just fine.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Use system-config-authenticate to configure Kerberos authentication.
2. Attempt to log in as a user with a Kerberos principal.
    

Actual Results:  User cannot log in.

Expected Results:  User should be logged in and have a TGT.

Additional info:

Kerberos otherwise appears to be working OK.   I can use kinit to
acquire a TGT and then do other kerberos things.   I'm not sure how to
go about pinning this one down to see what's causing the problem -- I
know if I comment out the pam_krb5 account line I can log in but then
I don't get a TGT.
Comment 1 John Haxby 2005-02-07 06:25:36 EST
It would appear that turning on the requires_preauth attribute for the
user prevents login.
Comment 2 John Haxby 2005-02-07 06:32:05 EST
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@UK.SCALIX.COM'to 'krbtgt/UK.SCALIX.COM@UK.SCALIX.COM'
Feb  7 11:21:44 sheep login: pam_krb5[2196]:
krb5_get_init_creds_password(krbtgt/UK.SCALIX.COM@UK.SCALIX.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.
Comment 3 Suzanne Hillman 2005-03-02 16:37:12 EST
Does this still occur with the released version of RHEL4?
Comment 4 John Haxby 2005-03-03 04:55:00 EST
Yes, it behaves exactly the same.

I'm happy to help debug this if you want to get in touch directly.
Comment 5 Nalin Dahyabhai 2005-03-03 13:48:42 EST
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?
Comment 6 Suzanne Hillman 2005-03-07 16:27:08 EST
Putting in NEEDINFO to reflect the current state of needing info from the reporter.
Comment 7 John Haxby 2005-03-15 07:11:54 EST
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@UK.SCALIX.COM'to 'krbtgt/UK.SCALIX.COM@UK.SCALIX.COM'
Mar 15 11:32:05 sheep login: pam_krb5[6126]:
krb5_get_init_creds_password(krbtgt/UK.SCALIX.COM@UK.SCALIX.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.
Comment 8 Nalin Dahyabhai 2006-08-11 11:16:38 EDT
This should have been fixed by 2.1.8-1.  Please reopen this bug if you find that
it wasn't.

Note You need to log in before you can comment on or make changes to this bug.