Jeff Taylor's Weblog

  • Sun
    May 28, 2013

Adding users in Solaris 11 with power like the initial account

During Solaris 11.1 installation, the
system administrator is prompted for a user name and password which
will be used to create an unprivileged account. For security reasons,
by default, root is a role, not a user, therefore the initial login
can't be to a root account. The first login must use the initial
unprivileged account. Later, the initial unprivileged user can acquire
privileges through either "su" or "sudo".

For enterprise class deployments, the system administrator should be
familiar with RBAC and create users with least privileges.

In contrast, I'm working in a lab environment and want to be able to
simply and quickly create new users with power like the initial user.
With Solaris 10, this was straight forward, but Solaris 11 adds a couple
of twists.

Create a new user jenny in Solaris 11:

# useradd -d localhost:/export/home/jenny -m jenny
# passwd jenny

Jenny can't su to root:

jenny@app61:~$ su -


Roles can only be assumed by authorized users

su: Sorry

Because Jenny doesn't have that role:

jenny@app61:~$ roles

No roles

Give her the role:

root@app61:~# usermod -R root jenny

And then Jenny can su to root:

jenny@app61:~$ roles


jenny@app61:~$ su -


Oracle Corporation      SunOS 5.11      11.1    September 2012

You have new mail.


But even when jenny has the root role, she can't use sudo:

jenny@app61:~$ sudo -l
Sorry, user jenny may not run sudo on app61.

jenny@app61:~$ sudo touch /jenny
jenny is not in the sudoers file.  This incident will be reported.

Oh no, she is in big trouble, now.

User jeff was created as the initial account, and he can use sudo:

jeff@app61:~$ sudo -l
User jeff may run the following commands on this host:
    (ALL) ALL

But jeff isn't in the sudoers file:

root@app61:~# grep jeff

So how do you make jenny as powerful as jeff with respect to sudo?

Turns out that jeff, created during the Solaris installation, is in

root@app61:~# cat

jeff ALL=(ALL) ALL

My coworker, Andrew, offers the following advice: "The last line of
/etc/sudoers is a directive to read "drop-in" files from the
/etc/sudoers.d directory. You can still edit /etc/sudoers. It may better
to leave svc-system-config-user alone and create another drop-in file
for local edits. If you want to edit sudoers as part of an application
install then you should create a drop-in for the application - this
makes the edits easy to undo if you remove the application. If you have
multiple drop-ins in /etc/sudoers.d they are processed in alphabetical
(sorted) order.  There are restrictions on file names and permissions
for drop-ins. The permissions must be 440 (read only for owner and
group) and the file name can't have a dot or ~ in it. These are in the
very long man page."

Join the discussion

Comments ( 5 )
  • Mohammad Tuesday, February 25, 2014


  • guest Thursday, December 4, 2014

    Thanks Jeff, once again you come through for others !

  • Emmanuel Friday, November 11, 2016


    Would you mind telling me, then how can I edit those files you mention? Everytime I try to edit the file it says read-only file. Thank you :) I am new in this!

  • nhal Wednesday, February 22, 2017


    is it possible if I want to delete the initial user created during installation and replace it with another user?

  • guest Wednesday, February 22, 2017

    Hi nhal,

    Instead of deleting the initial user created during installation and replacing it with another user, which is possible using useradd and userdel, you might want to use "usermod" to change the login name of the initial user.


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.