Bug 105946 - system-auth is not properly set for Kerberos V authentication
Summary: system-auth is not properly set for Kerberos V authentication
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: authconfig
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: CambridgeBlocker
TreeView+ depends on / blocked
 
Reported: 2003-09-29 19:49 UTC by Felipe Alfaro Solana
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version: test3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-10-23 10:48:21 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
system-auth as configured by authconfig (1011 bytes, text/plain)
2003-09-29 19:51 UTC, Felipe Alfaro Solana
no flags Details
system-auth configured manually (1011 bytes, text/plain)
2003-09-29 19:53 UTC, Felipe Alfaro Solana
no flags Details

Description Felipe Alfaro Solana 2003-09-29 19:49:31 UTC
Description of problem: 
----------------------- 
I have been having problems using "pam_krb5" with Fedora Core Test 2. Usually, 
I run "authconfig" to set up Kerberos 5 authentication and it has worked fine 
in previous distributions (e.g. Severn Beta 1). However, with Fedora Core Test 
2, I found that I could log on with a Kerberized user, but the user didn't get 
any Kerberos V credentials - in the form of a Ticket Granting Ticket (TGT). I 
even opened a Bugzilla bug: 
 
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=105829 
 
I think, however, that the problem is not within "pam_krb5" itself, but with 
how "authconfig" sets up the authentication modules stack in "/etc/pam.d/
system-auth". Fedora's Core Test 2 "authconfig" is forcing "pam_unix" 
authentication in first place with level "sufficient". Thus, I guess that, if 
the user which tries to log in has a local shadow password, it will log on, but 
won't get any Kerberos V credentials since the "pam_unix" module is 
"sufficient" and, thus, "pam_krb5" won't get invoked anyway. 
 
The fix is to fiddle with "/etc/pam.d/system-auth" to ask for Kerberos V 
authentication in first place and, if it doesn't work, fall back to default 
UNIX authentication. So, "/etc/pam.d/system-auth" should look like this: 
 
  #%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 
  auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok 
use_first_pass 
  auth        required      /lib/security/$ISA/pam_deny.so 
  ... 
 
Now, "pam_krb5" is invoked in first place and, if it fails, then the UNIX 
authentication module (pam_unix) will get invoked with the password the user 
typed at the very beginning of the login process (use_first_pass). 
 
Version-Release number of selected component (if applicable): 
------------------------------------------------------------- 
authconfig-4.3.7-2 
 
How reproducible: 
----------------- 
Always 
 
Steps to Reproduce: 
------------------- 
1. Install Fedora Core Test 2 
2. Run "authconfig" and enable Kerberos V authentication. 
3. "system-auth" will look like the attached file "system-auth.authconfig": 
 
Actual results: 
--------------- 
"system-auth", when Kerberos V is enabled, should look as the attached file 
"system-auth.manual": 
 
<snip> 
auth        required      /lib/security/$ISA/pam_env.so 
auth        sufficient    /lib/security/$ISA/pam_krb5.so 
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok 
use_first_pass 
auth        required      /lib/security/$ISA/pam_deny.so 
</snip> 
 
Expected results: 
----------------- 
"system-auth" should look like this: 
 
<snip> 
auth        required      /lib/security/$ISA/pam_env.so 
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok 
auth        sufficient    /lib/security/$ISA/pam_krb5.so use_first_pass 
auth        required      /lib/security/$ISA/pam_deny.so 
</snip> 
 
Additional info: 
---------------- 
Thanks to Nalin from helping me in figuring out what was wrong and how to fix 
it.

Comment 1 Felipe Alfaro Solana 2003-09-29 19:51:32 UTC
Created attachment 94831 [details]
system-auth as configured by authconfig

This will prevent PAM from getting to pam_krb5 to get Kerberos V credentials
for any user (well, only if the user has local, shadow password on the system
onto which he or she is logging)

Comment 2 Felipe Alfaro Solana 2003-09-29 19:53:16 UTC
Created attachment 94832 [details]
system-auth configured manually

This allows for Kerberos V authentication.

Comment 3 Michael K. Johnson 2003-10-21 19:32:21 UTC
@@ -2,11 +2,11 @@
 # 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_unix.so likeauth nullok
-auth        sufficient    /lib/security/$ISA/pam_krb5.so use_first_pass
+auth        sufficient    /lib/security/$ISA/pam_krb5.so
+auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
use_first_pass
 auth        required      /lib/security/$ISA/pam_deny.so
 
-account     required      /lib/security/$ISA/pam_unix.so
+account     sufficient    /lib/security/$ISA/pam_unix.so
 account     [default=bad success=ok user_unknown=ignore service_err=ignore
system_err=ignore] /lib/security/$ISA/pam_krb5.so
 
 password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=


Comment 4 Bill Nottingham 2003-10-21 19:33:28 UTC
Does this work for you with newer pam_krb5?

Comment 5 Matt Wilson 2003-10-21 19:34:27 UTC
(works for me as of Oct 14th tree, I get a tgt with what authconfig wrote)


Comment 6 Chris Ricker 2003-10-21 19:39:28 UTC
It's working for me now as well

Comment 7 Felipe Alfaro Solana 2003-10-23 10:48:21 UTC
Works also for me! I'm closing this bug, if everyone agrees. 

Comment 8 Pawel Salek 2004-04-09 10:02:05 UTC
I think this report has to be reopened: the kerberos tickets are not
fetched FC2t2+development as of yesterday. Making the manual change to
system-auth fixes the problem, though. It seems that the change to
system-auth as in the comment above by MKJ got lost on the way.

I cannot reopen this bug, should I open a new report?


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