What's New or Changed in Managing User Accounts and User Environments?

The following features are new or changed in this release:

• Security Changes That Impact User Account Management

• Introducing the User Manager GUI

• Administrative Editor (pfedit)

• /var/user/$USER Subdirectory

• groupadd Command Changes

• Failed Login Count Notification

Security Changes That Impact User Account Management

The following feat ures have changed in this release:

• State transition 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, and are as follows:

  LK

  The account is locked. 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.

  NL

  The account is configured for non UNIX authentication. The passwd -N command was run. Starting with this release, accounts in this state can be locked by running the passwd -l command and unlocked by running the passwd -u command.

• Qualified Authorizations. Authorizations can be qualified to apply to specific objects like groups, zones, or file names. See Administrative Editor (pfedit).

• The profiles command has been rewritten to manage rights profiles for local and LDAP scopes. Direct editing of role-based access control (RBAC) files is no longer supported.

• The ability to set a per-user Pluggable Authentication Module (PAM) policy (pam_policy) in a rights profile is available in this release. The pam_policy must be either an absolute path name to a pam_conf(4)-formatted file or the name of a pam.conf(4)-formatted file located in the /etc/security/pam_policy file. See pam_user_policy(5).

  In addition to setting PAM policy in a rights profile, you can also directly set the pam_policy in the user's user_attr entry by using either the useradd or usermod command. See Example 2-1.

• Users and roles who are assigned the User Security rights profile can create new user accounts, as well as delegate some of their rights to other accounts, without becoming the root role.

For more information, see Part III, Roles, Rights Profiles, and Privileges, in Oracle Solaris 11.1 Administration: Security Services.

Introducing the User Manager GUI

You can now set up and manage users, roles, and groups with the Oracle Solaris User Manager graphical user interface (GUI). The User Manager GUI is available in the desktop and is part of the Visual Panels project. The User Manager GUI replaces the Solaris Management Console GUI in this release. The tasks that you can perform with the User Manager GUI are essentially the same as those that can be performed by using the CLI, for example, the useradd, usermod, userdel, roleadd, rolemod, roledel commands.

For instructions on using the User Manager GUI, see Chapter 3, Managing User Accounts by Using the User Manager GUI (Tasks) and the online help.

Administrative Editor (pfedit)

An administrative editor (pfedit) can be used to edit system files in this release. If defined by the system administrator, the value of this editor is $EDITOR. If the editor is undefined, the editor defaults to the vi command.

Start the editor as follows:

$ pfedit system-filename

To edit system files by using the pfedit command, you or your role must have the solaris.admin.edit/system-filename authorization for the specific file that you are editing. Assigning this auth-sysfilename to an existing rights profile simplifies procedures that contain a mixture of Service Management Facility (SMF) commands and regular file edits. For example, if you are assigned the solaris.admin.edit/etc/security/audit_warn authorization, you can edit the audit_warn file.

The pfedit command can be used to edit most configuration files that are in the /etc directory, its subdirectories, and also application configuration files, for example, GNOME and Firefox files. The pfedit command cannot be used to edit system files that give a user power over a wide swath of a system, for example the ./etc/security/policy.conf file. You must have root access to edit such files. See the pfedit(1M) man page and Chapter 3, Controlling Access to Systems (Tasks), in Oracle Solaris 11.1 Administration: Security Services.

/var/user/$USER Subdirectory

Whenever a user logs in and successfully authenticates by using the pam_unix_cred module, a /var/user/$USER directory is explicitly created, if the directory does not already exist. This directory enables applications to store persistent data that is associated with a particular user on the host system. The /var/user/$USER directory is created upon initial credential establishment, as well during a secondary authentication when changing users by using the su, ssh, rlogin, and telnet commands. The /var/user/$USER directory does not require any administration. However, users should be aware of how the directory is created, its function, and that it is visible in the /var directory.

groupadd Command Changes

An administrator who has the solaris.group.manage authorization can create a group. At group creation, the system assigns the solaris.group.assign/groupname to the administrator, which gives the administrator complete control over that group. The administrator can then modify or delete that group, as needed. For more information, see the groupadd(1M) and groupmod(1M) man pages.

Failed Login Count Notification

The system now 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.