HOW TO DUPLICATE ROOT'S ACCESS...

[TeleBOYWONDER]

NOT ALL OF IT!
I just want a user (scmen) to have the same rights to changes user passwords words.
Running SunOS 5.7.

THanks.

 

[dbase77]

Hi,

Check "sudo" application.

dbase77

 

[spamly]

You could also give the user the userid of 0. I wouldn't though. Very bad things result when people play this game.

 

[TeleBOYWONDER]

I guess I should have said, something like I'm a newbie with some c++ experience but most of my unix comes from my callcenter experience with CMS-call management systems, being the driving factor.

Can you perhaps give me a little more detailed information.
Basically I don't want to pay the vendor, $300 bucks to do something that should be simple as edit to login profile??

THANKS.

 

[pneely]

You could copy root's entry in the /etc/passwd file calling the new entry... ie:'kroot'. Don't forget to run "pwconv".

 

[TeleBOYWONDER]

pneely,
Then could I rename "kroot" to scmen or would it just be better to cop root's entry to scmen?
What EXACTLY is the command line to copy it and is "passwd" the file I would need to edit??

("TEST:x:0:1:Super-User:/:/usr/bin/ksh" is what I find when I cat "passwd" in /etc directory, along with all users. )

Lastly, is there a notch uner "Super-User" in far as rights/privelages? If so that is what I would like the 'scmen' login to have.

Again thanks for your patience and help.

 

[nawlej]

id still go with sudo, so all of the activity is logged and you could only let them do certain things. It works great. Any time you duplicate a super user function and not make an audit trail, your asking for a lot of trouble.

___________________________________
[morse]--... ...--[/morse], Eric.

 

[TeleBOYWONDER]

nawlej,
Sudo won't work cause them I would have to go in and edit each user's passwd file right? Again, not a lot of unix experience so I would need to know the exact, verbatim and detailed instructions.
The other thing is I can't install any additional software on this system. If not installed by the vendor which would cost me more than the $300.00 to have them grant the right to 'scmen' in the first place.

 

[bfitzmai]

Not really sure if this will work... Try giving the user scmen group 14 (System Administrator) privileges.

 

[TeleBOYWONDER]

bfitzmai,
Tell me more? How do I up the rights??

 

[leejan]

Method 1:
If u intend to assign user "scmen" to help root to change user's password using only 'passwd' command, then follow dbase77 and nawlej suggestion (which is using sudo). You may download the sudo program from :

http://www.courtesan.com/sudo/

To learn how to use sudo, pls refer to the same website for its documentation.

Method 2:
If the "scmen" user is also allowed to assist root to manage some adminstrative tasks, then you can assign "scmen" to belong to this group called sysadmin (GID=14) -- as suggested by bifitzmai. Once scmen belonged to sysadmin, then he/she is allowed to help other user to change password.

How to assign "scmen" to sysadmin?
Log in as root and do the following:
# usermod -G 14 scmen

Then from now on, scmen is allowed to use admintool to assist root to perform some administrative tasks. So if scmen needs to change password for user1 using admintool:
1. Login as scmen and starts admintool:
$ admintool &
2. Select user1 from the admintool-user window using yr mouse and then choose Edit-Modify menu.
3. NOw you should be able to see Modify-User window, so you may change the user password from Password Type, select Normal Password.
4. Then, click OK.

NOTE: Please be reminded that once scmen belonged to sysadmin group, he/she would be able to perform other adminstrative tasks like modifying user accounts, groups accounts, printers, softwares, hostnames, and serial ports. However, scmen can only do all these tasks by using admintool utility, but not through command-line (cannot use useradd, usermod or userdel).If you do not intend to allow scmen to do this, the best is to use sudo program.

And pls DO NOT duplicate another root account by changing yr scmen's UID into 0. (Observe column 3 for UID)
Eg:
# vi /etc/passwd
scmen:x:0:14::/export/home/user1:/bin/ksh

If you do the above step, it means now scmen has exactly the same amount of privileges like root. Do you want yr user scmen to be able to change everything in yr system without consulting root first (ie. shutdown system, delete system files)?

 

[TeleBOYWONDER]

leejan,
Wow a log of great info and detal!! Excellant!

1)Again I CAN NOT add software to the box that is not apart of the vendor application running. This box is for callcenter and the vendor provides maint. and all programming...AT A COST.
Any programming we/I do it's our problem if something goes wrong and they only fix at a cost outside of the maintenance agreement.

2)Perfect example:
yesterday a girl was making a changes to passwords as root. somehow she changes the "root" password. Luckily I told her not to touch anything else until I got there. Long story short I was able to tell by what was on her screen that instead of resetting a user passwor to "sceil477xp" thats what she set the root password.
WHICH IS WHY I WANT THEM TO DO IT UNDER 'scmen" LOGIN.
And basically that's all they will do. ALso that scmen login runs some cronjobs daily that is essential to the callcenter. I don't want to lower/hender it's ability at all, just give it access to change passwords.


3)there is already a "root2" login and I suspect the vendor has installed it just in case a customer accidently erases root password and forget or damages the root login somehow.
In most cases their customers don't have interaction with users that can get around "OK" within the unix enviroment.
There is always a login and password that lets the customer change passwords but in this particular install that was not set and because we did not bring it to thier attention until 4 months later they feel it's out of the scope of the original install.

Lastly, not I don't mind if "scmen" has the EXACT same authority as root. The users other than myself don't know any unix commands, so they only know to change passwords.
AND TRUST THEY KNOW THE CONSEQUENCES OF PLAYING AROUND TRYING TO "LEARN" OR "EXPLORE". We fired a guy last thanksgiving for doing similar exploration on the PBX.

Again, thanks a lot for you suggesntions and help.

KEEP IT COMING!!!!!!!!!!!!!!!

 

[bfitzmai]

You have a problem... You have amatures with the root password. Regardless of the fact that you want to create another user with the privileges of root... If you are allowing amatures to have root privileges, you are asking for trouble.

I just proved on my workstation and NIS server that group 14 users can modify user accounts/passwords but can not modify the root account/password. My suggestion is to change the root password so only you and an alternate know it. Explain to your alternate that the root password is not to be given out to anyone. Give the people who need to change user accounts and passwords group 14 privileges.

 

[TeleBOYWONDER]

bfitz,
I should step back and say the users don't have access to the Sun box AT ALL! There are no workstations with access. The vendor's application is their interface to the data/programs they use daily.
The sun box is only touched by my IT group, 4 of us. However the other 3 are experts at the vendor application level but very little unix experience.
The general community of users that need password reset and changes does not even know the box exist. As an IT guy I never say never 100% but with this workforce it's as close as you will ever get.

The issue here is we use to have the access with the scmen login prior to the new install. I just want to get it back somehow without paying a ransom of $300.00.
I'm not at all worried about abuse but moreso about another accident where the root passwd is changed accidently. I can't be the only person to change passwords and it's kinda the 2 junior employess job.

Bottom line, it sounds I will need to grant "scmen" group 14 privileges.

Thanks guys for all your input.

 

[KenCunningham]

Sounds much like a training issue for our team to me. That said, sudo is certainly the way to go, so the $300 might be money well spent if it saves you some sleepless nights. If you consider this a ransom, why did your company agree to it in the first place - never sign contracts you're going to regret later (advice from a once-bitten twice-shy guy there! ;-) ). Good luck.

 

[TeleBOYWONDER]

Ken,
It's not really a training thing because for the past 7 years it has been standard for the vendor to supply this login with privileges to change passwords.
Matter of fact we had the access up until April when they updated our Sun box. (The old sun box sits in a lab and the SCMEN userid can change passwords-we kept it live just in case the data transfer went bad.)

It's a matter of the vendor wanting to screw the business partner who we are assoicated with. To make a long story short our BP isn't well liked by the vendor and they would like us to switch or go to them direct.

I don't much care for the BP either but it's the principal of the thing not the $300.00.(We have an IT budget of over 60 mil, so my VP would probably look at me with 3 heads over the money issue.

Lastly for the last 7 years of my 15 year experience this has been the case with scmen userid. Every single other customer of this product has it this way.

WE ARE NOT UNIX CENTRIC BUSINESS. It just so happens the call managment system runs on a sun box and the vendor uses unix as it's backend. My staff, sure they could learn to be very very careful, but again it the principal.
I want it the way it was prior to new install and I'm not going to pay a loust 300.00 bucks because you say it's 90 days out of the window for install related fixes and must be covered under my maint.

Well anyways, thanks guys!

 

[KenCunningham]

No probs - but don't get in a tailspin about this. If your budget's what you say it is - just do it! As the adverts say. Good luck.