[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

trouble stacking password modules



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.







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []