Bug 155791

Summary: userpasswd does not seem to update kerberos v5
Product: [Fedora] Fedora Reporter: Jason Hoover <jasonhoover>
Component: usermodeAssignee: Miloslav Trmač <mitr>
Status: CLOSED WORKSFORME QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-03-14 00:15:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jason Hoover 2005-04-23 03:03:22 UTC 
Description of problem:

Userpasswd doesn't update kerberos 5 passwords through the applicable pam token.
However, vanilla passwd seems to have no trouble doing it. I'm filing it as
normal because it hampers the usefulness of the holy-grail kerberos single sign
on IMHO.

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

1.79-2

How reproducible:

Every time.

Steps to Reproduce:
1. Change passwd with userpasswd. Try to kinit with new passwd.
2. Watch it fail.
3. Change passwd with passwd (after re-setting them both to the same).
4. Kinit again with new passwd, and viola!

Additional info:

Standard PAM configuration with kerberos selected and properly configured in
authentation system prefrence control pannel type thing.

Yes, my kerberos server is set up properly. No, I haven't muddled with my pam
config.

There's potential that this is a symtom of Bug 1685 but, I have no way to verify
this for sure.
Comment 1 Jindrich Novy 2005-04-23 04:51:04 UTC 
Hello Jason, are you sure that bug 1685 has anything to do with this usermode
problem? Could you please write here a correct reference let me have a look at it?

Thanks,
Jindrich
Comment 2 Jason Hoover 2005-04-23 18:19:58 UTC 
Hah. Oops.

I meant Bug 16815.

Like I said, there's only potential, as they could be asking for a fix to work
with yppaswd ( or for pam_unix to do yppasswd changes ).

Sorry for the confusion.
Comment 3 Christian Iseli 2007-01-22 11:52:24 UTC 
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 4 Miloslav Trmač 2007-03-13 23:36:21 UTC 
I'm sorry about the late response.

If you can still reproduce the problem, can you attach the relevant PAM config
files, please?

The default PAM configuration is currently
  password    requisite     pam_cracklib.so try_first_pass retry=3
  password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
  password    sufficient    pam_krb5.so use_authtok
  password    required      pam_deny.so
which means that successfull change of the local password terminates the
password change operation and pam_krb5 is never used.
Comment 5 Jason Hoover 2007-03-14 00:12:07 UTC 
Sorry, it was a long time ago, and I took that system apart by now. I'd have to
set up a krb5 server and a fc again. Though, that does explain a bit, as I had a
local user set up AND was using kerberos for authentication (set through the
appropriate gui interface at setup time). I think passwd changed both the local
and krb password by default, whereas userpasswd would do just the local
(shouldn't they work the same?).
Comment 6 Miloslav Trmač 2007-03-14 00:15:23 UTC 
They both use the same configuration, so they certainly should work the same,
and IIRC they did when I was testing it.