2009/7/2 D G Teed <[email protected]> > In testing the effects of the passwd command, I have found the following... > > I run the passwd command with an account having > an Active Directory name as well. If I disobey > the prompt: > > (current) UNIX password: > > and enter my AD authentication, it changes > the AD password rather than the local password. > That might be desirable in some situations, but > we don' t want that to happen. > > Here is our system-auth, which ssh is using. > > [snip]
> password requisite pam_cracklib.so try_first_pass retry=3 > password sufficient pam_unix.so md5 shadow try_first_pass use_authtok > password sufficient pam_winbind.so try_first_pass use_authtok > password required pam_deny.so > [snip] > > winbind is not set in /etc/nsswitch.conf . We have simply: > > passwd: files > > This Redhat server also has a samba service, which authenticates > off AD, so it has joined the domain as a machine. > > Is there room for improvement in our pam settings which would prevent > inadvertent reset of the AD account authentication? > The nsswitch thing is a red herring -- you're really only concerned with the PAM configuration. You can disable AD password changing altogether by commenting out that pam_winbind line, but this is probably not what you want. You can also disable the local password database, but this probably isn't what you want either. When you're changing your password, the first pass collects your current password and uses it for authentication. pam_cracklib is isn't interested in your current password and doesn't ask, pam_unix is and asks for your current password. If you provide your unix password then authentication will fail and, as the module is only sufficient, it'll move on to pam_winbind. pam_winbind says "try_first_pass" (which would seem to be the default) and as the password matches that'll be sufficient and we'll stop there. On the second pass, pam_cracklib looks at your new password (the authtok, and why "try_first_pass" is there is a mystery, it's pointless), pam_unix ignores it (and fails) because password provided earlier was wrong and pam_winbind sets the password to the newly provided password. So it's doing what it's supposed to do :-) I think, however, that you can achieve the effect that you want if you add "not_set_pass" to the list of arguments to pam_unix. Unfortunately, I only have a man page for pam_unix on Fedora 10 and 11, but "not_set_pass" does appear in the strings in the offending module so I have reasonably high hopes that it will work and may well do what you want! jch
_______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
