Bug 1120 - Syncing Unix passwords fails when "unix password sync" command is set to Yes and a non-root user attempts a password change
Summary: Syncing Unix passwords fails when "unix password sync" command is set to Yes ...
Status: RESOLVED WORKSFORME
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts (show other bugs)
Version: 3.0.2
Hardware: All Linux
: P3 major
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact:
URL:
Keywords:
: 1122 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-24 03:55 UTC by Ben Jensz
Modified: 2005-02-08 21:58 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Jensz 2004-02-24 03:55:20 UTC
Samba setup essentially as a PDC with encrypted passwords, when enabling "unix
password sync", unprivileged users cannot change their password using the
"smbpasswd" command, the following error is produced:

[user@server /]$ smbpasswd
Old SMB password:
New SMB password:
Retype new SMB password:
machine 127.0.0.1 rejected the password change: Error was : RAP86: The specified
password is invalid.
Failed to change password for user

If you turn off "unix password sync", then non-root users can then change their
own passwords.  I also note that trying to change your password from a Windows
machine produces the same failure to change password when unix password sync is
enabled.

I have tested this on a Fedora Linux Core 1 machine with Samba versions 2.2.8a
and 3.0.2, and with 2.2.8a on a Red Hat Linux 7.3 machine and it produces
exactly the same results.  I double checked my smb.conf configuration with John
Terpstra via the Samba mailing list and he commented that he can reproduce
exactly the same problem himself and suggested I make this bug report.

Thanks for your time. :)
Comment 1 Tim Potter 2004-03-02 03:18:15 UTC
*** Bug 1122 has been marked as a duplicate of this bug. ***
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-02-08 21:58:36 UTC
seems to be ok in 3.0.11