Hi
I would like to create another root account, for example root2. I added a new user named root2 and set it's uid and gid ( in /etc/passwd ) to 0. Then I logged in ( account root2 ) and the server asked to change the password, so I changed.
And the problem happend. The password of both root and root2 changed. I had to log in ( root ) by new password, and everytimes I logged in ( root2 ) , the server asked to change password again. That also means I couldn't use account root2.
Ok,
So you manually edited the /etc/passwd file.
Lesson no.1 You never do that.
Now, coming to your problem, after you change the password for root2, is it letting you in to the system?
Do you have sudo setup for sysadmin users? if so, login as that user then sudo to root (NOT root2). Edit the /etc/passwd file and remove the entry for root2.
Change the root password and make sure that you have not exceed the defined unsuccessfult_login_count .
If this don't work I can provide you another solution. 1st try this and let us know.
I suggest not to do that.. you can use rbac(for AIX 6.1), create your roles and assing roles to other users. They have same authotity as root and it's safer thinking in security stuff.
Suppose you create a role myadminrole and assigned to a user israel, so log
1- log on as israel
2- swrole myadminrole
and do what ever you want.
This user can change the root password without any issues.
I counldn't log in as root2 because when I loged in as root2, the server always asked to change password, I changed password and then I was disconnected. I loged in 2nd times and the server asked again, and then again ...
I could log in as root normally, but with root2's password
If I remove the entry for root2, account root2 will not exist anymore ???
root2 never really existed at all -- that's kind of the problem. They were never independent the way you wanted and can't be, the UID prevents it. If you remove root2's line from /etc/passwd, it will just be /root again. Ordinarily I would never suggest editing /etc/passwd but you you did so in the first place, creating a situation the usual tools may not be equipped to handle.
Also, since you've changed the UID of root2 to the one of root, it changed the password of 'root' since that was the 'right' uid.
root2 didnt get the password update, since it has another original uid.
To avoid such disasters, i'd suggest to use these tools (as root obviously, and with care):
useradd
userdel
usermod
groupadd
groupdel
groupmod
Read their respective --help output.
Or go GUI either way system-config-users .
I would suggest not to use these tools, but in fact i do not even have to - they do not exist in AIX systems, only in Linux systems. Please take the forum you are posting to into account.
Same here. AIX tools do not have any options introduced with a double dash "--" and system-config-users simply doesn't exist.
To the problem:
A UNIX system identifies users by their UID, which is a number. When the system displays a user name instead of the number (like "root" instead of "0") it is because it translated the number first using "/etc/passwd" as translating table. Entries there are used from top to bottom. You can easily test this: create two users, "a" and "b" and modify the "/etc/passwd" so that both have the same UID. Now create a file and give the ownership to one of these accounts. Do a ls -l and you will see the first of the two users in "/etc/passwd" as owner. Now edit "/etc/passwd" and make the other entry the first. A ls -l will now show the other user (the one now coming first) as the owner.
If you do not exactly know what to do you should use the mkuser utility to create users, which makes all the necessary entries in "/etc/passwd", "/etc/security/passwd", "/etc/limits", etc.. You can change the UID later for the created account by modifying "/etc/passwd". Notice, though, that the id command and similar tools relying on "/etc/passwd" will identify this account as "root", for reasons stated above.
I have got a problem.
I have added all default roles to my user ( root2 )
lsuser -a roles root2
root2 roles=AccountAdmin,so,FSAdmin,sa,BackupRestore,DomainAdmin,SecPolicy,SysBoot,SysConfig,isso
but this user can't execute this command
bootlist -m normal -o
Then I maked "testrole" and added that command to it.
The problem is : when I "swrole" to testrole ( only one role ), I could execute that command. But when I "swrole" to testrole and these default role ( 11 roles in total ) , I couldn't execute that command anymore :(:(:(.
You got already advice about how to deal with your imminent problem. I would like to add some general remarks about RBAC: my professional experience is to better stay away from RBAC (as well as ACLs, for that matter, and for similar reasons) and restrict yourself to the classical user rights management UNIX offers.
The UNIX privilege model is very simple and - at first sight - not very flexible. On the other hand, as long as you stay within its boundaries it can be managed with an absolute minimum of effort. Any query or change, regardless of addressing a single user or many, a single file or many, can be done in a minimum of steps and in most cases only one command is needed.
RBAC (and ACLs as well) offer the ability to use a much more fine-grained model. Allow userA to execute cmdB but not cmdC and userB the other way round, etc.. This is an alluring prospect but if you really start to put all these offered capabilities into practice and quite soon you have system which is way too complex to be handled effectively. Instead of a simple "ls -l" you need to cross-corelate long lists of "userA is able to execute cmdB only when ... and then only at ... but not in the presence of ... except if ...". Once you got through all the ifs, whens, and excepts you probably have forgotten what you originally wanted to do in first place.
In short: UNIX privilege management is very simplistic, but it is so for a reason: stick with it and you always have a manageable system. Use all the fancy additional possibilities (RBAC, ACLs, even both) and very likely you will be able to solve a singular problem more easily but in the long run end up with a system which is hard (if not impossible) to manage and a privilege structure which is neither easily nor quickly adapted to changing demands.
RBAC, as bakunin said, it's not easy to manage. But it's not impossible either to create your own roles and enable it on your system.
In our case, we have more than 6 system admins and if all of them use root account, it's dificult to audit your system. Here's where RBAC is useful, because you can enable it for all system administrator and everyone do the work ( as root), but using with their users.
Also, it's very possitive and welcomed by auditors.
But why waste time when it takes you less than 5 minutes to configure sudo to do the same? Even better - e.g. without having to enter a passwd when root...
All the best
First, I'm not saying RBAC is better than others solutions you have said above. I just told bobochacha29 what we use in our enviroment.
My waste of time is simple:
There're a lot of users logged on on production enviroment. All these users are from differents groups, execute differents commands, etc etc. Some of them SU to another common account to make their tasks. Others system admins used only root account. So, after a an audit we deciced to use RBAC, so everyone use its personal account.
Greetings igalvarez,
I was not debating on your usage which makes sense, you are not in the same case as the Thread owner who has no history and knowlege about RBAC implementation and what it assumes, the same goes for quotas - its seems easy to use... I am happy I got rid of the last server that had quotas
