Completely disabling root logins on Solaris 11

Since Solaris 8 it has been possible to make the root account a role.  That means you can't login directly as root (except in single user mode) but have to login as an authorised user first and assume (via su) the root role.  This still required the root account to have a valid and known password as it is needed for the su step and for single user access.

With Solaris 11 it is possible to go one step further and completely disable all need for a root password even for access in single user mode.

There are two complementary new features that make this possible.  The first is the ability to change which password is used when authenticating to a role.  A new per role property called roleauth was added, if it isn't present the prior behaviour of using the role account password is retained, if roleauth=user is set instead then the password of the user assuming the role is used.

The second feature was one that existed in the Solaris 11 Express release which changed how the sulogin command worked, prior releases all just asked for the root password.  The sulogin program was changed to authenticate a specific user instead so now asks for a username and the password of that user.  The user must be one authorised to enter single user mode by being granted the 'solaris.system.maintenance' authorisation - and obviously be one that can actually connect to the system console (which I recommend is protected by "other means" eg ILOM level accounts or central "terminal server")

The following sequence of commands takes root from being a normal root account (which depending on how you install Solaris 11 it maybe, or it might already be a role) and granting the user darrrenm the ability to assume the root role and enter single user mode.

# usermod -K type=role root
# usermod -R +root -A +solaris.system.maintenance darrenm
# rolemod -K roleauth=user  root
# passwd -N root

Note that some of the install methods for Solaris 11 will have created an initial user account that is granted the root role and has been given the "System Administrator" profile, in those cases only the last two steps are required as the equivalent of the first two will already have been done at install time for the initial non root user.

Note that we do not lock (-l) the root account but instead ensure it has no valid password (-N) this is because the root account does still have some cron jobs that we ideally want to run and if it was locked then the pam_unix_account.so.1 PAM module would prevent cron from running those jobs.

When root is a role like this you authenticate to the system first as yourself, in this case the user darrenm logs in first.  Once darrenm has logged in we use su(1M) to be come root - just like we would have if root wasn't a role.  The main difference here is that the password given to su(1M) in the above config is darrenm's password.

If you boot the system in single user mode (boot -s) you will be asked for a username and password, we give the username of darrenm and darrenm's password. Once you do that you get a # prompt that is truely root in single user mode.  The distinction here is we have an audit trail and know it was darrenm that authenticated and we have no separate root password to manage.

In some deployment cases there may not be any locally defined accounts, in those cases it is necessary to allow the root to allow direct login on the system console in multiuser mode.  This is achived by adding the following to /etc/pam.conf, and also give the root account a valid password.

login account required	pam_unix_account.so.1

By having that entry we do not have pam_roles.so.1 active for console login so the root account will be able to login directly.  The assumption here is that access to the system console is sufficiently secured (and audite) by means external to the Solaris instance.  For example the ILOM of the system is on an access restricted management network that has specific user accounts for SSH access to the ILOM.  You may also want to only give out that root password in emergency cases.  This will allow direct root login only on the console but require that users authenticate to root using their own password when using su.


    

If you have made root as role and you want to go back to a traditional direct login capability for root you can do so by simply running:

 # rolemod -K type=normal root

Update 1 to answer the first question: Basically exactly the same as if the password was locked, expired or forgotten if you just used root directly.  Failed account locking is not enabled by default.  As for forgetting who was the authorised account that isn't a problem Solaris can fix on its own that is part of your administative procedures.  You can have any number of authorised users and the userattr, roles, profiles commands can be used tell you who they are and manage them.

Update 2 to make it clearer how you use this in multi-user and single user.

Update 3 add information on how to allow root on console.


Comments:

what happens when userid "darrenm" is locked, password expired, password forgotten, or nobody even knows "darrenm" is the only authorized root-role acct. What happens when you weld the manhole cover shut?

Posted by 321contact on November 10, 2011 at 01:33 AM GMT #

Having had to deal with the mess on Ubuntu Linux systems resulting from their 'no root account' policy, I was hoping Solaris would not make the same mistakes.

What if you are only user on the machine with a local login account based on /etc/passwd & etc/shadow and you want to make changes to the account, the home directory or its location? You have have to log in to assume the root role but you can't make changes affecting your account account as root while you are logged in. What to do?

Posted by Andy on November 11, 2011 at 10:45 AM GMT #

You can make some changes to your account while you are logged in. You will get a warning about some types of change not taking effect until next login. However there are some changes you can't do while logged in, for example changing your home directory location.

The workaround for that is to login in single user mode and make the change there. As I indicated above in Solaris 11 you can authenticate using *your* username and password at single user mode even when root has no password. I don't believe you can do that in Ubuntu.

Alternatively you can make the changes manually by editing the /etc/passwd file using an editor rather than using usermod(1M) but you will have some manual work to do in order to get a home directory change to take effect.

In general though you shouldn't need to change the home directory entry for a user if you use the automounter since /etc/passwd will say /home/andy. You can edit /etc/auto_home to point to the new/moved home directory. You can then force unmount /home/andy, refresh automounter and logout and back in again.

Posted by Darren Moffat on November 14, 2011 at 05:56 AM GMT #

So, what exactly is the procedure to be able to login as root? I am just curious and using virtual box. So security is not an issue. If, say, "oracle" is the default user with the sysadmin (root role) capability, then what are the exact steps to enable a root login?

Posted by Roy on November 15, 2011 at 04:34 PM GMT #

Roy, I've updated the article text to hopefully explain your question - substitute darrenm with oracle.

Posted by Darren J Moffat on November 16, 2011 at 05:44 AM GMT #

I dont think "boot single user" to fix is a serious solution to a PRODUCTION box. If you have ERP systems that make millions of dollars a day in OLTP transactions it's not in the cards to say "I have to bring the system down to fix it". Because @holes in the IT security dept want "90 days max" to password expiration, and I can't count how many times I've had to log in as root because my non-root id was expired.

Posted by 321contact on November 18, 2011 at 06:47 PM GMT #

I dont think "boot single user" to fix is a serious solution to a PRODUCTION box. If you have ERP systems that make millions of dollars a day in OLTP transactions it's not in the cards to say "I have to bring the system down to fix it". Because @holes in the IT security dept want "90 days max" to password expiration, and I can't count how many times I've had to log in as root because my non-root id was expired.

Posted by 321contact on November 18, 2011 at 06:47 PM GMT #

File-Permissions and "root"-role:

If I switch from normal user-account to root-role by using "su", then I get:

-rw------- root root .bash_history
-rw------- root root .lesshst

within my normal user-account's $HOME-dirctory.

Btw: If logged in as normal user-account, output of "roles"-command gives: "root". Therefore, "root"'s a role.

Methinks, this overwriting of file-permissions would deserve to be fixed, would'nt it?

Posted by utl on November 20, 2011 at 07:34 AM GMT #

utl, with regard to the file permissions that is because you used 'su' rather than 'su -'. When you use 'su' the value of most environment variables including $HOME stays the same. This is very long standing UNIX behaviour and has nothing to do with root being a role.

Posted by Darren J Moffat on November 21, 2011 at 05:20 AM GMT #

First of all, thanks for your quick answer!

Your' re certainly right about the long-standing behavior of "su"
and "su -".

I rather thoughtlessly read an expample in the documentation of role-switching using "su" without "-" being appended, and just copied it to my command line.

It was my mistake (An example of "Reading without Thinking").

Best wishes to you and your team.

Greetings!

utl

Posted by utl on November 22, 2011 at 12:32 AM GMT #

Darren, you're right about Ubuntu, normal users cannot login in single user mode - only root can assuming a known password has been set for the root account (which I always do on Ubuntu systems with 'sudo passwd root'). But as 321contact has pointed out, bringing systems down to runlevel 1 to make changes that can be easily done in higher run levels on other *n*x systems isn't always possible nor desirable.

Posted by guest on November 22, 2011 at 02:53 AM GMT #

We have migrated all our systems to use LDAP for user accounts because of the number of systems supported and 90 day password expiration.

How would a user be authenticated - or would it be possible in single user mode? Since networking is not enabled by default, I doubt this would be possible. Can you comment?

Posted by richarc on December 01, 2011 at 11:30 AM GMT #

You can still make the changes by editing the files it is just that in Solaris 11 GA there were a few checks left in useradd(1M) that should have been - this is a bug that I'm fixing.

Posted by Darren J Moffat on December 02, 2011 at 04:17 AM GMT #

richarc,

Networking is enabled in single-user mode, however if you have no local admin accounts then this isn't an appropriate thing to do because there could be cases where the reason you need into single user mode is because you have nameservice problems. How far you go along the line of root as a role to root not even having a valid password depends on how the system is used and wither you have local accounts or only remote nameservice (NIS or LDAP) accounts.

Posted by Darren J Moffat on December 02, 2011 at 04:20 AM GMT #

How do you return the root role access to the original state after executing the command:
# rolemod -K type=normal root

Posted by guest on January 10, 2012 at 03:16 PM GMT #

May be:
"
The following sequence of commands takes root from being a normal root account (which depending on how you install Solaris 11 it maybe, or it might already be a role) and granting the user darrrenm the ability to assume the root role and enter single user mode.
# usermod -K type=role root
# usermod -R +root -A +solaris.system.maintenance darrenm
# rolemod -K roleauth=user root
# passwd -N root
"

Posted by guest on January 10, 2012 at 04:17 PM GMT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

DarrenMoffat

Search

Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today