The Linux-PAM documentation describes the generic option
"try_first_pass" in a few different places, and includes this
parenthetical comment in at least two of them, "(This option is intended
for auth modules only). " However, try_first_pass is listed as one of
the generic options for password management in the Linux-PAM Modules
Writers' Guide, on page 13. Either the comment should be removed, or
the option should not be listed for password modules. I suspect
removing the comment is the right choice. Then the modules themselves,
like pam_unix and pam_smbpass, will need to be fixed so that they
actually do prompt the user for another password if the first one
doesn't work.
There should also be more specific guidance in the module writers'
guide, section 5.2, Use of syslog(3), on what specific information
should be logged. The module producing a message to the user should be
identified in the message, for ecample. It is confusing to see
duplicate messages with slight variations from stacked modules without
any indication of which module produced them. Try to interpret the
following transcript.
-bash-2.05b$ passwd
Changing password for user jck.
Changing password for jck
(current) UNIX password:
New UNIX_and_SMB password:
Retype new UNIX_and_SMB password:
Password changed for user jck.
passwd: Authentication token manipulation error
-bash-2.05b$
Maybe the configuration and log messages would help.
password required /lib/security/pam_cracklib.so retry=3
type=UNIX_and_SMB debug
password required /lib/security/pam_unix.so nullok md5
use_authtok try_first_pass debug
password optional /lib/security/pam_smbpass.so nullok
use_authtok try_first_pass debug
Jan 14 09:43:42 zang passwd(pam_unix)[3028]: username [jck] obtained
Jan 14 09:43:48 zang PAM_smbpass[3028]: username [jck] obtained
Jan 14 09:43:48 zang PAM_smbpass[3028]: failed auth request by jck for
service passwd as jck(999)
Jan 14 09:45:24 zang passwd(pam_unix)[3028]: username [jck] obtained
Jan 14 09:45:24 zang PAM_smbpass[3028]: username [jck] obtained
Jan 14 09:45:24 zang PAM_smbpass[3028]: password for (jck/999) changed
by (jck/999)
Jan 14 09:45:26 zang PAM_smbpass[3028]: 1 authentication failure from
jck for service passwd as jck(999)
As far as I can tell, by actually logging in with "ssh -l jck zang" and
"smbclient //zang/jck -U jck", no passwords were actually changed. I am
using very slightly modified versions of the latest releases of both
modules, but I don't think I have actually changed their behavior yet.
I am working on some patches to make this work the way I think it
should. I have been able to make the originals work right only if the
UNIX and SMB passwords are the same and the pam_smbpass module is used
before pam_unix, but I would like to migrate users from another system
that did not automatically keep both passwords the same, and I think
that users might be able to get their passwords out of sync again by
changing the UNIX password through NIS.
_______________________________________________
Pam-list@redhat.com
https://listman.redhat.com/mailman/listinfo/pam-list
