Bug 155791 - userpasswd does not seem to update kerberos v5
userpasswd does not seem to update kerberos v5
Product: Fedora
Classification: Fedora
Component: usermode (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2005-04-22 23:03 EDT by Jason Hoover
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-13 20:15:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jason Hoover 2005-04-22 23:03:22 EDT
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):


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

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 00:51:04 EDT
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?

Comment 2 Jason Hoover 2005-04-23 14:19:58 EDT
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 06:52:24 EST
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 ?

Comment 4 Miloslav Trmač 2007-03-13 19:36:21 EDT
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-13 20:12:07 EDT
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-13 20:15:23 EDT
They both use the same configuration, so they certainly should work the same,
and IIRC they did when I was testing it.

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