03-13-2013 05:21 AM
If i have a user xyz which should only be allowed to login in test account .
is it possible ?
User xyz must not be able tologin in another account using su - apps ;
he must only use su - test
hpux 11i v2
Solved! Go to Solution.
03-13-2013 05:53 AM
Don't tell him the password to the apps account, and don't give him root access.
If you have sudo installed, you can configure a sudoers rule like:
xyz ALL = (test) NOPASSWD: ALL
so the user can switch to the test account with "sudo -iu test"; you don't have to give the user the permissions to run the "su" command at all.
03-14-2013 02:39 AM
Hi Matti ,
I dont want to give su rights for this user.
I just want user xyz to login in his own accout which is "test" .
He must not be able to login in apps account ( su - apps ) even if he knows the password.
I tried your settings but am still able to login in apps account using "su"
03-14-2013 03:42 AM - edited 03-14-2013 03:45 AM
>He must not be able to login in apps account (su - apps) even if he knows the password.
It seems you have a management problem, not an admin problem.
Change the password.
Or just tell him not to do this on pain of possible termination. (It would be logged in su.log.)
03-17-2013 11:47 PM
If user doesn't wants to use su ,
add the below in alias file in user .profile
-------------------->if not don't share the password.
04-02-2013 02:04 AM
Hi Madhu ,
am saying for a user say "test" i want him to to login in another user say "app"
at the same time he must not be able to login to "dev" , how can we achieve this.
For this i think sudo group will only be the right software i think.
04-02-2013 03:57 AM
> For this i think sudo group will only be the right software i think.
The problem here is with your security procedures: having non-personal user accounts like "app" and "dev" with passwords known to the users is a mistake. Users can usually be taught to not reveal their personal passwords to anyone else, but the passwords of shared accounts are almost always shared too far, to people that are not supposed to know them. And when an account password is shared by many people, it will be very difficult to change it without inconveniencing at least one legitimate user. This is why shared passwords are a bad thing.
If a user is allowed to use the "su" command and knows the password of the target user, the standard su command will always allow the user to switch to the target user. There is no way to allow switch from user A to user B without also allowing a switch from user A to user C, if the user knows the passwords.
I had exactly this problem in year 2001.
To fix this, you need a way for the users to switch to accounts like "app" or "dev" without knowing the passwords of "app" nor "dev" - but only selectively, so that the accounts each user is allowed to switch to can be controlled.
This is exactly what sudo is designed to do.
The first step is to install and configure a system that will allow the kind of control you need. Sudo is the standard solution for that. Once the users are taught to use sudo, the next step is to change the passwords of "app", "dev" and similar shared user accounts to long, random strings that are impossible to guess, very hard to remember and inconvenient to type - and NOT reveal the passwords to your users. This makes sudo the only allowed mechanism to login to shared accounts.
You can store the list of passwords of the shared accounts in a sealed envelope that is held in Boss's safe, to be used in exceptional situations only - or you can even intentionally "forget" those passwords, so that if the "app" or "dev" password is ever needed, root must change the password of the shared account first. Once the exceptional situation is over, a new long, random password should be generated.
Once your users learn to fully use sudo, you will see that the list of shared account passwords is never actually needed in practice. The only exception is the root account: even if you use sudo for root access normally, the real root password should be kept safe and usable in case there is a problem with sudo or other security settings, or the system cannot boot to normal multi-user mode. In these situations, you might have to login as root on the system console to recover.