User must not able to login in other accout (437 Views)
Reply
Regular Advisor
coollllllllllll
Posts: 140
Registered: ‎12-28-2012
Message 1 of 9 (437 Views)
Accepted Solution

User must not able to login in other accout

Hi,

 

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

Please use plain text.
Honored Contributor
Matti_Kurkela
Posts: 6,271
Registered: ‎12-02-2001
Message 2 of 9 (434 Views)

Re: User must not able to login in other accout

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.

MK
Please use plain text.
Regular Advisor
coollllllllllll
Posts: 140
Registered: ‎12-28-2012
Message 3 of 9 (416 Views)

Re: User must not able to login in other accout

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"

Please use plain text.
Acclaimed Contributor
Dennis Handly
Posts: 24,849
Registered: ‎03-06-2006
Message 4 of 9 (411 Views)

Re: User must not able to login in other account

[ Edited ]

>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.)

Please use plain text.
Occasional Advisor
madhuthelearner
Posts: 12
Registered: ‎03-04-2013
Message 5 of 9 (373 Views)

Re: User must not able to login in other account

If user doesn't wants to use su ,

 

add the below in alias file in user  .profile

 

alias su=hostname

 

 

 

-------------------->if not don't share the password.

 

regards

 

Madhu

Please use plain text.
Regular Advisor
coollllllllllll
Posts: 140
Registered: ‎12-28-2012
Message 6 of 9 (326 Views)

Re: User must not able to login in other account

Hi ,

 

But the user can always change his .profile right ???

Anyway as of now its fine , this suggestion is working for us.

Please use plain text.
Occasional Advisor
madhuthelearner
Posts: 12
Registered: ‎03-04-2013
Message 7 of 9 (318 Views)

Re: User must not able to login in other account

HI,

 

he need root access to change other .profile.

 

if he knows the root pwd,then no use in restricting su to other user.

 

regards

 

Madhu

Please use plain text.
Regular Advisor
coollllllllllll
Posts: 140
Registered: ‎12-28-2012
Message 8 of 9 (247 Views)

Re: User must not able to login in other account

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.

Please use plain text.
Honored Contributor
Matti_Kurkela
Posts: 6,271
Registered: ‎12-02-2001
Message 9 of 9 (235 Views)

Re: User must not able to login in other account

> For this i think sudo group will only be the right software i think.

 

Exactly.

 

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.

MK
Please use plain text.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation