Home > Articles > Operating Systems, Server > Solaris

  • Print
  • + Share This
Like this article? We recommend

Managing Accounts

Managing user and system accounts is an important aspect of Sun Linux security. Some system accounts might need to be deleted or modified. The time-based command execution system tools cron and at might need to be configured to restrict user access.

This section contains the following topics:

  • "Delete and Modify System Accounts"
  • "Restrict at, cron, and batch Command Access"
  • "Limit Root Access"
  • "Use the Pluggable Authentication Module (PAM)"

Delete and Modify System Accounts

A default Sun Linux installation contains several accounts that either need to be deleted or modified to strengthen security. Some accounts are not necessary for normal system operation. These accounts include games, gopher, and news and uucp. Some of these accounts exist to support software subsystems that are not used or are for backwards compatibility.

To Delete Accounts

  • To delete accounts in /etc/passwd and /etc/shadow entries, use the userdel command, similar to the following example:

    # /usr/sbin/userdel games

    This example removes the /etc/passwd and /etc/shadow entries for user games.

    Except for the root account, modify any remaining system accounts for added security by locking them, setting account expiration, or setting their login shells to a restricted value.

To Lock Accounts

  • To lock unused accounts that are not locked by default, use the passwd -1 option. For example, if the uucp account is not used, then lock it using the following command.

    # passwd -l <username>

    The password of the account is changed to a string that can never be a valid encrypted password.

To Expire an Account

  • To schedule a user account to expire, use the following command:

    # /usr/sbin/usermod -e YYYY-MM-DD <username>

An expired account has similar characteristics to those of an account where the password is locked. The account can still be accessed by root via superuser, daemons can be started, and files and directories can be owned by the account. As with locked accounts, expired accounts cannot be used to login to a system or to access any of the services where authentication is required, such as Telnet, FTP, or IMAP.

To disable interactive access to a user account, use the following command.

# usermod -s /bin/false <username>

An account with a disabled shell (one that is not listed in /etc/shells and does not permit access to the system) only impacts applications that check for valid shells, such as Telnet, FTP, and Secure Shell. This method does not impact other applications such as IMAP and POP that by default do not check this setting.

A better alternative to using /bin/false as a disabled shell is to use a program that not only prevents access to the system but also logs the attempted access. The following shell script could be used to implement such functionality. This example is based on the file /sbin/noshell program available from the Solaris™ Security Toolkit software. For more information on the Solaris Security Toolkit software, refer to http://www.sun.com/security/jass.

trap "" 1 2 3 4 5 6 7 8 9 10 12 15 19
export PATH
HNAME="'uname -n'"
UNAME="'id | awk '{ print $1 }''"
logger -i -p auth.crit "Unauthorized access attempt on ${HNAME} by ${UNAME}"


To change default account parameters used during new account creation (via useradd), change the following values in either the /etc/login.defs or the /etc/default/useradd file.

TABLE 1 describes the parameters in the /etc/login.defs file.

TABLE 1 /etc/login.defs File Parameters




Minimum days allowed between password changes


Minimum acceptable password length


Days warning given before a password expires


Maximum days a password may be used

TABLE 2 describes the parameters in the /etc/default/useradd file.

TABLE 2 /etc/default/useradd File Parameters




Default group


Default user home location


Expiration date of an account in the format YYYY-MM-DD


Maximum days after an unchanged and expired password that the account is locked out and can only be accessed by root


Default shell

Restrict at, cron, and batch Command Access

The at, cron, and batch commands execute processes (events) at a specified future time. Access control files are stored in the /etc directory.

  • The cron.deny and cron.allow files manage access to the cron command.

  • The at.deny and at.allow files manage the access to the at and batch commands.

The allow files are checked first to determine if an account is explicitly allowed to use these facilities.

Attackers can use these commands to implement logic bombs (triggered by a system condition, logic that causes damage to data processing systems) or other programmed attacks that begin in the future. Unless administrators examine every at, batch, and cron event, tracking usage and abuse can be difficult. Therefore, we recommend that you restrict access to the at, batch, and cron commands to prevent attacks and abuse.

By default, Sun Linux includes scheduled cron events for the root account. Do not include the root account in the deny files, because any scheduled jobs will be prevented from running.

Add to the deny files any additional system or software-specific accounts that do not require cron, batch, or at access.

You might want to restrict user access to these commands as well. List individual user accounts in the deny files. To restrict all user account access, create an empty allow file, then add only the accounts that need access.

Limit Root Access

The sudo program implements a form of role based access control (RBAC). It is a commonly used tool for limiting access to privileged commands and accounts. Using sudo has the following benefits:

  • sudo is configured by default to ask for a user's password

  • Fewer users need to log in as privileged users and know the password

  • Access to privileged commands is determined by a policy; users are given access only to the commands they need

  • Access to privileged commands can be logged

Common uses for sudo are allowing system operators to make backups and create user accounts without giving operators full root access.

To create a new account, an operator enters:

# sudo useradd newuser

It is very important to ensure that mail to root is checked or forwarded. Unauthorized use of sudo generates an email to the root user and creates an entry in the system log /var/log/messages file.

May 4 18:25:14 scl1 sudo(pam_unix)[28769]: authentication failure; logname=attackerid
uid=0 euid=0 tty=pts/2 ruser= rhost= user=attackerid

To review valid uses of sudo, refer to /var/log/secure. In the following example, the sudo command was used by the user joe to access the /bin/bash command as root.

May 4 18:25:28 scl1 sudo: sudoerid: TTY=pts/2 ; PWD=/home/sudoerid/joe ;
USER=root ; COMMAND=/bin/bash

The sudo command consults the /etc/sudoers configuration file to determine if a command is allowed. This configuration file contains access control lists (ACLs) as in the following example.

<user>  <hostname> = '(' <account> ')' <command> [',' <command>]

A rule of this form allows user logged in to hostname to run command as user account. By including the hostname in the rule, it is possible to share a single /etc/sudoers file between multiple machines. For more information about the format of these ACLs, refer to the sudoers manual page.

Use the visudo command to edit the /etc/sudoers file. This command checks the syntax of edited contents before overwriting /etc/sudoers. If the /etc/sudoers syntax is incorrect, sudo does not work.

To keep the description concise, you can define aliases for sets of users, hostnames, and commands. You can use the alias ALL in any field. In the following example, we allow a group of operators to make backups and restore them.

# provide access to dump and restore for backup operators
User_Alias   OPERATORS = tom, dick, harriet
Cmnd_Alias   BACKUPCMD = /sbin/dump, /sbin/restore


Be aware that with a little creativity, any user who can make backups and restore them can gain root access, so this example is not a completely secure setup. In general, we advise that you create scripts or programs that wrap commands executed with privilege to limit the options available to its users. In addition, these scripts can sanitize the execution environment by checking or resetting variables such as a user's path to help ensure sane settings. This way, the use of privileged commands can be better controlled.

You can configure sudo to allow only certain parameters to be passed to privileged commands. Verify that operators cannot pass any arguments to privileged commands that have unintended consequences. The following rule allows operators to change passwords for all users except for root.

# User alias specification
User_Alias   OPERATORS = tom, dick, harriet

# Cmnd alias specification
Cmnd_Alias   PASSWDCMD = /usr/bin/passwd, !/usr/bin/passwd root
# Defaults specification

The previous example prevents execution of the sudo passwd root command. However, it does allow execution of the sudo passwd --stdin root command. In this case, you can fix the problem by changing the definition of PASSWDCMD slightly, as in the next example.

The following example allows two classes of users (web masters and operators) to manage a system. Web masters can stop and start a web server. Operators can change forgotten user passwords (except for root passwords), start system backups, and perform web master duties.

# User alias specification
User_Alias   OPERATORS = tom, dick, harriet
User_Alias   WEBMASTERS = josephine, OPERATORS

# Cmnd alias specification
Cmnd_Alias   PASSWDCMD = /usr/bin/passwd [!-]*, !/usr/bin/passwd root
Cmnd_Alias   BACKUPCMD = /usr/sbin/backup_script
Cmnd_Alias   HTTPDCTL = /etc/rc.d/init.d/httpd

# Defaults specification

Defaults    authenticate, timestamp_timeout = 60

# User privilege specification


Use the Pluggable Authentication Module (PAM)

The Pluggable Authentication Module (PAM) architecture allows administrators to control and replace the methods used for authentication. In concept, while this is similar to the PAM functionality that is available in the Solaris OE, note that there are differences.

For more information on the Solaris OE implementation of PAM, refer to the Sun BluePrints OnLine two-part article titled "Extending Authentication in the Solaris 9 OE Using Pluggable Authentication Modules (PAM)."

Although PAM makes authentication operations more robust, it requires that system authentication information be maintained in more places than just /etc/passwd and /etc/shadow. PAM can be expanded to support Kerberos, LDAP, OPIE, S/Key, RSA SecureID, RADIUS, TACACS+, and others. Understanding how the PAM system functions is essential for maintaining the security of a system.

All primary applications such as login, su, ssh, and sudo are PAM aware. Each application that uses PAM does so through a common API that references the general configuration file /etc/pam.conf or the application-specific file in the directory /etc/pam.d/, if it exists.


If the directory /etc/pam.d/ exists, the file /etc/pam.conf is ignored. The directory /etc/pam.d/ is part of the standard Sun Linux installation.


Before editing PAM configuration files, make a backup of the files. Errors made in configuration files can prevent PAM or the service you modified from operating correctly, and might prevent privileged users from logging in. Also, you could inadvertently disable authentication and expose the system. Do not change the default ownership or file permissions of the /etc/pam.d/ directory or its contents.

Within the PAM configuration file, define methods for authentication. Enter one line per method using the following format.

[service] [type] [control] <module-path> <module-arguments>

TABLE 3 lists the values for entering authentication methods.

TABLE 3 PAM Configuration Values




This field exists only if the /etc/pam.conf file is used and is the name of the service defined, such as login or su. If the file is in /etc/pam.d/ and is specific to the application, then it is not used.


This field is the management group and can be one of the following:

  • account - Verify that the account is valid. For example: has the account expired?

  • authentication - Verify the user's identity by using a password, smart card, or biometric device.

  • password - Maintain the authentication method. For example: if the password has expired, prompt for a new one.

  • session - Provide methods that are performed before the session is started and after the session is ended, such as setting up and reclaiming resources the user requires.


This field specifies what to do when a module fails its task:

  • requisite - Immediate termination of the authentication process; do not call additional modules.

  • required - If this module fails, then allow other modules to be called, but ultimately fail the authentication attempt. Each required module must succeed for the authentication to succeed.

  • sufficient - Success of the module is enough to succeed in authentication.

  • optional - Success or failure of this module is important if it is the only module in the stack associated with this service and type.

  • More complex control syntax can be used; refer to the pam(8) manual page.


This path is the full file name of the authentication module called with the default location /lib/security/. A special module used by many configuration files is pam_stack. This module lets you call a service from inside the stack. This feature allows multiple services to include a system-wide configuration, so that it only needs to be maintained in one place. The most common use for this feature is the configuration file /etc/pam.d/system-auth.


Valid arguments are space-separated lists of tokens that modify behavior of the module called. They are module specific.

For additional information on PAM, refer to the Linux PAM site at http://www.kernel.org/pub/linux/libs/pam/, the pam(8) manual pages, and the PAM documentation in /usr/share/doc/pam.

After editing the configuration file, test the changes and make any necessary adjustments.


If you lock yourself out of a system, reboot into single-user mode, then restore the configuration file from the backup.

Disabling Null Passwords

A null password allows users to log onto a system without having to first supply a valid password string. When users have null passwords, they can press the Enter key when prompted for a password and gain access to systems without a password. Obviously, this poses a significant security risk to the system and to the accountability of actions performed by users.

To Disable Null Passwords

  • Make a backup of the /etc/pam.d/system-auth file, then modify the original by removing nullok from the line, resulting in the following:

auth sufficient /lib/security/pam_unix.so likeauth

Checking Passwords Against a Dictionary

Sun Linux can be configured to verify that passwords cannot be guessed easily. On Sun Linux, this check is performed by the module /lib/security/pam_cracklib.so. It checks to ensure that passwords are a minimum length and verifies that a password does not occur in a dictionary.

The dictionary used by this module is located in /usr/lib and is in cracklib format. By default, each of the dictionary files is prefixed with the file name cracklib_dict. For more information on cracklib including how to add new words to the dictionary, refer to http://www.crypticide.org/users/alecm/.

This module has a number of parameters, the most useful of which are as follows.

TABLE 4 pam_cracklib Parameters




Specifies the minimum password length allowed for an account


Specifies the minimum number of characters that have to differ from the previous password

To Check Passwords

  • Add the following parameters to an entry in /etc/pam.d/system-auth, resulting in the following single line:

    password required /lib/security/pam_cracklib.so retry=3 type= minlen=8 difok=3

Preventing Reuse of Old Passwords

The PAM module pam_unix.so can be configured to maintain a list of old passwords for every user, to prohibit the reuse of old passwords. The list /etc/security/opasswd is not maintained as plain text, but should be protected the same as shadow password files. This capability is often referred to as password history.

To Retain a List of Passwords

  • To remember the last 15 passwords, add the following line in /etc/pam.d/system-auth file:

    password  sufficient  /lib/security/pam_unix.so use_authtok md5 shadow remember=15

Preventing Password Guessing

The module pam_tally keeps track of unsuccessful login attempts, and disables user accounts (not user IDs) when a preset limit is reached. This capability is often referred to as account lockout.

To Prevent Password Guessing

  • Add two entries in the /etc/pam.d/system-auth file:

    auth    required   /lib/security/pam_tally.so onerr=fail no_magic_root
    account   required   /lib/security/pam_tally.so deny=5 no_magic_root reset

    Because the order of the lines in /etc/pam.d/system-auth is important, we list the complete file contents.

    auth    required   /lib/security/pam_env.so
    auth    required   /lib/security/pam_tally.so onerr=fail
    auth    sufficient  /lib/security/pam_unix.so likeauth
    auth    required   /lib/security/pam_deny.so
    account   required   /lib/security/pam_unix.so
    account   required   /lib/security/pam_tally.so deny=5
      no_magic_root reset
    password  required   /lib/security/pam_cracklib.so retry=3
      type= minlen=8 difok=3
    password  sufficient  /lib/security/pam_unix.so use_authtok
      md5 shadow remember=15
    password  required   /lib/security/pam_deny.so
    session   required   /lib/security/pam_limits.so
    session   required   /lib/security/pam_unix.so
  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020