Go to main content

Managing Auditing in Oracle® Solaris 11.3

Exit Print View

Updated: October 2017

Troubleshooting the Audit Service

This section covers various auditing error messages, preferences, and the auditing that is provided by other tools to help you debug audit problems.

Typically, different notices are sent to alert you of errors in the audit service. Review your email and the log files if you think that problems exist with the audit service.

  • Read the email sent to the audit_warn alias.

    The audit_warn script sends alert messages to the audit_warn email alias. In the absence of a correctly configured alias, the messages are sent to the root account.

  • Review the log files for the audit service.

    The output from the svcs -x auditd command lists the full path to the audit service log files.

  • Review the system log files.

    The audit_warn script writes daemon.alert messages to the /var/log/syslog file.

    The /var/adm/messages file might contain information.

After you locate and fix the problems, enable or restart the audit service.

# audit -s

The following sections describe possible problem cases and the steps to resolve them.

Note -  Before you perform any troubleshooting tasks, ensure that you have the proper authorization. For example, to configure auditing, you must become an administrator who is assigned the Audit Configuration rights profile. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.3.

Audit Records Are Not Being Logged

Auditing is enabled by default. If you believe that auditing has not been disabled, but no audit records are being sent to the active plugin, the causes might be one or a combination of the following factors discussed in this section. Note that to modify a system file, you must be assigned the solaris.admin.edit/path-to-system-file authorization. By default, the root role has this authorization.

Audit Service Not Running

To check whether auditing is running, use any of the following methods:

  • Verify the current audit condition.

    The following output indicates that auditing is not running:

    # auditconfig -getcond
    audit condition = noaudit

    The following output indicates that auditing is running:

    # auditconfig -getcond
    audit condition = auditing
  • Verify that the audit service is running.

    The following output indicates that auditing is not running:

    # svcs -x auditd
    svc:/system/auditd:default (Solaris audit daemon)
    State: disabled since Sun Oct 10 10:10:10 2010
    Reason: Disabled by an administrator.
    See: http://support.oracle.com/msg/SMF-8000-05
    See: auditd(1M)
    See: audit(1M)
    See: auditconfig(1M)
    See: audit_flags(5)
    See: audit_binfile(5)
    See: audit_syslog(5)
    See: audit_remote(5)
    See: /var/svc/log/system-auditd:default.log
    Impact: This service is not running.

    The following output indicates that the audit service is running:

    # svcs auditd
    STATE          STIME    FMRI
    online         10:10:10 svc:/system/auditd:default

If the audit service is not running, enable it. For the procedure, see Enabling and Disabling the Audit Service.

No Audit Plugin Active

Use the following command to check if any plugins are active. At least one plugin must be active for the audit service to work.

# audit -v
audit: no active plugin found

If no plugin is active, make one active.

# auditconfig -setplugin audit_binfile active
# audit -v
configuration ok

Audit Class Undefined

You might be attempting to use an audit class that has not been defined. For a description of creating the pf class, see How to Add an Audit Class.

For example, the following list of flags contains the pf class, which Oracle Solaris software did not deliver:

# auditconfig -getflags
active user default audit flags = pf,lo(0x0100000000000000,00x0100000000001000)
configured user default audit flags = pf,lo(0x0100000000000000,00x0100000000001000)

If you do not want to define the class, run the auditconfig -setflags command with valid values to reset the current flags. Otherwise, ensure the following when defining a class:

  • The audit class is defined in the audit_class file.

    # grep pf /etc/security/audit_class
    Verify class exists
  • The mask is unique. If it is not unique, replace the mask.

    # grep 0x0100000000000000 /etc/security/audit_class
    Ensure mask is unique

No Assigned Events to Audit Class

The customized class that you are using, although defined, might not have any events assigned to the class.

To verify whether events are assigned to the customized class, use one of the following methods:

# auditconfig -lsevent | egrep " pf|,pf|pf,"
AUE_PFEXEC      116 pf execve(2) with pfexec enabled
# auditrecord -c pf
List of audit events assigned to pf class

If events are not assigned to the class, assign the appropriate events to this class.

Volume of Audit Records Is Large

After you have determined which events must be audited at your site, use the following suggestions to create audit files with just the information that you require. Note that to assign flags to users, roles, and rights profiles, you must assume the root role.

  • Specifically, avoid adding events and audit tokens to the audit trail. The following policies increase the size of the audit trail.


    Adds environment variables to execv audit events. Although auditing execv events can be costly, adding variables to the audit record is not.


    Adds command parameters to execv audit events. Adding command parameters to the audit record is not costly.


    Adds a group token to audit events that include an optional newgroups token.


    Adds a path token to audit events that include an optional path token.


    If file events are being audited, adds an event to the audit trail every time an auditable event happens to a public object. File classes include fa, fc, fd, fm, fr, fw, and cl. For the definition of a public file, see Audit Terminology and Concepts.


    Adds a sequence token to every audit event.


    Adds a trailer token to every audit event.


    On a system that is configured with Trusted Extensions, adds events when information in a labeled window is downgraded.


    On a system that is configured with Trusted Extensions, adds events when information in a labeled window is upgraded.


    Adds the zone name to every audit event. If the global zone is the only configured zone, adds the string zone, global to every audit event.

    The following audit record shows the use of the ls command. The ex class is being audited and the default policy is in use:

    header,129,2,AUE_EXECVE,,mach1,2010-10-14 11:39:22.480 -07:00
    subject,jdoe,root,root,root,root,2404,50036632,82 0 mach1

    The following is the same record when all policies are turned on:

    header,1578,2,AUE_EXECVE,,mach1,2010-10-14 11:45:46.658 -07:00
    HOME=/home/jdoe,LOGNAME=jdoe,G_FILENAME_ENCODING=@locale,UTF-8, PRINTER=example-dbl,
    subject,jdoe,root,root,root,root,2424,50036632,82 0 mach1
  • Use the audit_syslog plugin to send some audit events to syslog.

    Do not send those audit events to the audit_binfile or audit_remote plugin. This strategy works only if you are not required to keep binary records of the audit events that you send to the syslog logs.

  • Set fewer system-wide audit flags and audit individual users.

    Reduce the amount of auditing for all users by reducing the number of audit classes that are audited system-wide.

    Use the audit_flags keyword to the roleadd, rolemod, useradd, and usermod commands to audit events for specific users and roles. For examples, see Example 29, Specifying Audit Classes for syslog Output and the usermod(1M) man page.

    Use the always_audit and never_audit properties of the profiles command to audit events for specific rights profiles. For information, see the profiles(1) man page.

    Note -  Like other security attributes, audit flags are affected by search order. For more information, see Order of Search for Assigned Rights in Securing Users and Processes in Oracle Solaris 11.3.
  • Create your own customized audit class.

    You can create audit classes at your site. Into these classes, put only those audit events that you need to monitor. For the procedure, see How to Add an Audit Class.

    Note -  For information about the effects of modifying an audit configuration file, see Audit Configuration Files and Packaging.

Binary Audit File Sizes Grow Without Limit

As an administrator who is assigned the Audit Review rights profile, you can limit the size of binary files to facilitate archiving and searching. You can also create smaller binary files from the original file by using one of the options described in this section.

  • Use the p_fsize attribute to limit the size of individual binary audit files.

    For a description of the p_fsize attribute, see the OBJECT ATTRIBUTES section of the audit_binfile(5) man page.

    For an example, see Example 21, Limiting File Size for the audit_binfile Plugin.

  • Use the auditreduce command to select records and write those records to a smaller file for further analysis.

    The auditreduce -lowercase options find specific records.

    The auditreduce -Uppercase options write your selections to a file. For more information, see the auditreduce(1M) man page. See also Displaying Audit Trail Data.

Logins From Other Operating Systems Not Being Audited

The Oracle Solaris OS can audit all logins independent of source. If logins are not being audited, then the lo class for both attributable and non-attributable events is probably not set, This class audits logins, logouts, and screen locks. These classes are audited by default.

Note -  To audit ssh logins, your system must be running the ssh daemon from Oracle Solaris. This daemon is modified for the audit service on an Oracle Solaris system. For more information, see SunSSH Implementation of Secure Shell in Managing Secure Shell Access in Oracle Solaris 11.3.
Example 47  Ensuring That Logins Are Audited

In this example, the output of the first two commands shows that the lo class for attributable and non-attributable events is not set. Then, the last two commands set the lo class to enable auditing of login events.

# auditconfig -getflags
active user default audit flags = as,st(0x20800,0x20800)
configured user default audit flags = as,st(0x20800,0x20800)

# auditconfig -getnaflags
active non-attributable audit flags = na(0x400,0x400)
configured non-attributable audit flags = na(0x400,0x400)

# auditconfig -setflags lo,as,st
user default audit flags = as,lo,st(0x21800,0x21800)

# auditconfig -setnaflags lo,na
non-attributable audit flags = lo,na(0x1400,0x1400)