Normal users should not able to change their password. To get this behavior, i don't want to change the permissions on 'passwd' command or to the users. I think we can do this using PAM, but i don;t know how to implement this. Can some one here help me out in this ?

Edit the /etc/pam.d/passwd file and add "auth required pam_deny.so" to the top of the file. Use pam_rootok ahead to make it OK for root to use passwd. But really, why not just change permissions of /bin/passwd? Also, it's really not a good idea to not allow users to change their password (what if they accidentally disclose it and the admin isn't around?). Hopefully you have lined up another method for user password changes.

Hi btmiller,

I made the changes as you told. But still its not working.
These are the settings i have in my /etc/pam.d/passwd file after making changes.

cat /etc/pam.d/passwd
#%PAM-1.0
auth required pam_deny.so pam_rootok
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth

Moreover i am using RHEL4

Thank you,
RaghuNi

I wouldn't even bother with PAM stuff.

here's what I'd do.

cd to the appropriate directory where the passwd command resides (use which passwd to determine)
chown root passwd
chmod 700 passwd

That should do it for you.

It's quick, it's easy and fairly easy to undo if needed.

Hi Nawar,
Thank you for you reply, but as i said in my first post, i don;t want to change any permissions to passwd command.

Raghuni.

Just out of curiosity, why shouldn't the users be able to change their passwd?

This isn't right, pam_deny and pam_rootok are separate modules -- try:

auth sufficient pam_rootok.so
auth required pam_deny.so

The first line automatically grants authorization to root without any further checking. The second says that pam_deny is required, but pam_deny will always deny authorization, no matter what, so at that point all other users will be locked out. At least this is my understanding based on my (fairly limited) knowledge of PAM. If it doesn't wortk, post exactly what isn't working (is root locked out? Can normal users change passwords?).

As myself and others have said, you really ought to think carefully about doing something like this...

I tried with all the combinations mentioned below..., but still its not working... i.e normal user is able to change his/her password.

auth sufficient pam_rootok.so
auth required pam_deny.so
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth

auth sufficient pam_rootok.so
auth requisite pam_deny.so
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth

auth sufficient pam_rootok.so
auth reqired pam_deny.so
#auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth

auth sufficient pam_rootok.so
auth requisite pam_deny.so
#auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth

And mucking around with PAM config, which may get overwritten during a patch or update install is any better?

The more you overtake the plumbing, the easier it is to stop up the drain.

When in doubt, apply the KISS method. (Keep It Simple Silly)

However, if you feel you must play with PAM, then btmiller's post should solve your issue.

I'm not sure what kind of setup you are attempting to make. However, I thought I'd share a little information with you.

I work for a publicly traded company, and we are REQUIRED by audit regulations to ONLY allow end users to change their passwords.
Any passwords set by administrators have to be temporary, forced to expire after one login attempt. IE - users log in once with the admin set passwords, then have to choose their own password.
Forcing users to remember admin set passwords, and use them only makes matters worse. Look around their work areas, and you'll probably find a scrap of paper with the password(s) written on it.


(Update: I will try and see if I can make a working config with either my RH4 EWS VM or SuSe 9.3 Enterprise VM, once I get out of this hell-hole I'm in)

JMTCW,

Nawar

Hi, Nawar
Thank you for your all information, and i understood that, in any organization, users should have access to change their passwords and even it is one the best security practice.

For ex: Suppose, one wants to take all the backups automatically, and put them on remote machine.
In this case, the backup script will use some xyz user name and password to copy files remotely. So once we define a user name and password to upload the files remotely, the password should not be changed accidentally.

On remote system, we have given (r-w) permissions to only that particular (normal) user.

Now, if i want to remove permissions on passwd command for a single or set of users, how can i do that ?
So, i thought, the best way is to fine tune the PAM. If you have any other ideas for this please let me know, so that i will be very thankful to you.

Thank you once again for all your efforts,
RaghuNi

I was going to point you in the direction of ACLs, however, after doing a little experimentation, it appears that different distro support of ACLs is somewhat lacking.

So we're back to permission changes, and the use of a nice utility called sudo.

Changing the perms on passwd to 700 so that the passwd command can only be executed by root.

Then we add an entries into the sudoers files that states that certain users can run the passwd command.

Cmnd_Alias PASSUSR1=/usr/bin/passwd user1
Cmnd_Alias PASSUSR2=/usr/bin/passwd user2
Cmnd_Alias PASSUSR3=/usr/bin/passwd user3

user1 ALL=(root) PASSUSR1
user2 ALL=(root) PASSUSR2
user3 ALL=(root) PASSUSR3

Now, what this does, is allow user1, user2 and user3 to run the passwd command, but only for their userids.

They would run sudo /usr/bin/passwd user1 (or user2, or user3 as appropriate)

If ACLs had worked, it would have been simple enough to leave the perms at 755, then add ACLs to dis-allow certain userids from running the passwd command.

setfacl m:u:userid:000 /usr/bin/passwd

alas, since ACLs don't appear to work, it doesn't matter.



Now, as for your example of copying backups from one system to another.
What I would do, is use OpenSSH's scp command, combined with public key authentication.

Setup the user like normal on the remote system, set a password, then modify the user's .profile (or .bash_profile) to read "exit 0"

This will prevent users from *logging in* as this userid.

Next, create a key-pair on the system being backed up, and copy the public component of the key-pair to the remote system.

Put the public-key into the appropriately named file, in the user's home/.ssh subdirectory. Some system use "authorized_keys", others use "authorized_keys2".

Make sure the permissions on the user's home directory are set to 740 or less (700 would be ideal). The same goes for the .ssh subdirectory. Public key authentication will not work with a group/world writeable home directory, so as loose as 744 would work. If you're not sure which file-name to use, check the /etc/ssh/sshd_config file to see which file naming convention is used. The entry in question starts with AuthorizedKeysFile.
Also, make sure that the remote system's /etc/ssh/sshd_config file has the following entries set.
RSAAuthentication Yes
(if you are using RSA key authentication)
DSAAuthentication Yes
(old version of PUBKeyAuthentication)
PubKeyAuthentication Yes
(latest version setting for DSA key authent)

Now, make sure that the master system (the system being backed up) has the following set in it's /etc/ssh/ssh_config file (or wherever the ssh_config file is located at)
RSAAuthentication Yes
DSAAuthentication Yes
PubKeyAuthentication Yes

Now, finally in your script on the system being backed up, try the following.

scp -i /path/to/private/key/file archive.tar user@remotesys:/path/to/store/backup

Substitute the userid in question for "user".
Replace /path/to/private/key/file with the fully qualified private key file name.
Replace /path/to/store/backup with the fully qualified directory to store the backup file.

This will copy the file from one system to another, without prompting for a password, and without ever allowing anyone to ever log in as that userid.


HTH,

Nawar

To disable login, set user's shell to
/bin/false
in his /etc/passwd entry.

That would also disable the ability to *su* to the userid if needed for some reason, which is why I did not specify that option.

However, that is very much a true statement.

Hey guys,

Here, i got one more option to do the same...

passwd -n <No.Of.Days Password should not be changed> <UserName>


If we give very longer number then it will be .....

RaghuNi.

Heh - as always, with UNIX/Linux - there's more than one way to do things.