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.