In this release, you create and manage user accounts from the command line. The User Manager GUI is also available for performing some of the tasks that you typically perform by using the command line.
The following related topics are described in more detail:
The following features are new or have changed in this release:
Creating user accounts – User account creation has changed in the following ways:
User accounts are created as individual ZFS file systems, which enables users to have their own file system and their own ZFS dataset. Every home directory that is created with the useradd and roleadd commands places the user's home directory on /export/home as an individual ZFS file system.
User names and group names can be up to 32 characters. The 8 character limitation no longer exists.
The useradd command relies on the automount service, svc:/system/filesystem/autofs, to mount home directories. This service should never be disabled. Each home directory entry for a user in the passwd database uses the format, /home/username, which is an autofs trigger that is resolved by the automounter through the auto_home map.
The optional server name specifies the host on which the home directory resides. Entries in this form depend on the automounter and are maintained in the auto_home map. The path /home/username is maintained in the passwd database. When a user subsequently references /home/username, the automounter mounts the specified directory on /home/username. You can disable the autofs service if you do not specify home directory path names that include a server name or localhost.
Modifying user accounts – The usermod command works with LDAP and files. All security attributes can be assigned to a user by using this mechanism. For example, an administrator can add a role to a user's account by using the usermod command.
# roleadd -K roleauth=user -P "Network Management" netmgt # usermod -R +netmgt jdoe
User security attributes that are maintained in LDAP can be qualified to only apply to specific hosts or netgroup.
Access to services that require authentication such as the su, sudo, or ssh command can be restricted to specific days and times.
See usermod(1M) for additional examples.
Creating and managing groups – An administrator who has the solaris.group.manage authorization can create a group. At group creation, the system assigns the solaris.group.assign/groupname authorization to the administrator, which gives the administrator complete control over that group. The administrator can then modify or delete that groupname, as needed. See the groupadd(1M) and groupmod(1M) man pages.
Creating and managing roles – You can create roles locally and in an LDAP repository. To create a role and assign an initial password, you must be assigned the User Management rights profile. For instructions on creating a role, see Assigning Rights to Users in Securing Users and Processes in Oracle Solaris 11.3.
User Manager GUI – The User Manager GUI is part of the Visual Panels project and is accessible from the desktop. The GUI replaces some of the functionality of the Solaris Management Console. See Chapter 3, Managing User Accounts by Using the User Manager GUI in Managing User Accounts and User Environments in Oracle Solaris 11.3.
User password management and login information have changed in the following ways:
Assuming a role – All role assumption requires a password. In this release, at administrative discretion, the password that you supply to assume a role can be your own password.
Expanded login options during shutdown – During a system shutdown, an /etc/nologin file is created. This file displays a message that the system is being shut down and that logins are not possible. However, this type of shutdown does not prevent superuser from logging into the system. In this release, users who are assigned the root role and users who are assigned the solaris.system.maintenance authorization are also not blocked when the nologin file is present on the system.
Failed login count notification – The system notifies users of failed authentication attempts, even if the user account is not configured to enforce failed logins. Users who fail to authenticate correctly, will see a message similar to following upon successful authentication:
Warning: 2 failed authentication attempts since last successful authentication. The latest at Thu May 24 12:02 2012.
To suppress such notifications, create a ~/.hushlogin file.
Monitoring and restricting root access – In a default system configuration, a user cannot remotely log in to as root. When logging in remotely, users must log in with their user name and then become root by using the su command. You can monitor who has been using the su command, as well as restrict root access to a system. See Monitoring and Restricting root Access in Securing Systems and Attached Devices in Oracle Solaris 11.3
Password hashing algorithm – The default password hashing algorithm in this release is SHA256. This password hash is similar to the following:
Also, there is no longer an eight character limitation for user passwords. The eight character limitation only applies to passwords that use the older crypt_unix (5) algorithm, which has been preserved for backwards compatibility with any existing passwd file entries and NIS maps. Starting with Oracle Solaris 11, the crypt_sha256 algorithm is the default
Passwords are encoded by using one of the other crypt (3c) algorithms, including the SHA256 algorithm, which is the default in the policy.conf file. Thus, passwords can be much longer than eight characters. See policy.conf(4).
root password changes – It is no longer possible to use a system without assigning the root role a password of the requisite length that also meets other password complexity requirements.
Property definition refinements for the password command – This change clarifies which user accounts can and cannot be locked. The primary changes impact the LK and NL property definitions in the following ways:
The account is locked for UNIX authentication. The passwd –l command was run, or the account was automatically locked due to the number of authentication failures reaching the configured maximum that is allowed. See the policy.conf(4) and user_attr(4) man pages.
The account is a no login account. The passwd –N command was run.
An NFS or a SMB share of a ZFS file system is created and then shared.
The following sharing features are provided on ZFS storage pool version 34:
The share.nfs property replaces the sharenfs property in previous releases to define and publish an NFS share.
The share.smb property replaces the sharesmb property in previous releases to define and publish an SMB share.
ZFS share administration is simplified by leveraging ZFS property inheritance. If you want to share the tank/home file system, use syntax similar to the following:
# zfs set share.nfs=on tank/home
The share.nfs property value is inherited to any descendent file systems.
# zfs create tank/home/userA # zfs create tank/home/userB
Because home directories are created as ZFS file systems in Oracle Solaris 11, you typically do not need to manually mount home directories. The home directory is automatically mounted during its creation and also at boot time from the SMF local file system service. For instructions on manually mounting a user's home directory, see Manually Mounting a User’s Home Directory in Managing User Accounts and User Environments in Oracle Solaris 11.3.