Go to main content

Managing Auditing in Oracle® Solaris 11.4

Exit Print View

Updated: February 2019

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.

  • The audit service provides error information to its corresponding SMF log file, /var/svc/log/system-auditd:default.log. Review this log for possible issues related to the SMF processes.

  • 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 logs messages to the daemon facility at the alert level.

    Note -  Administrators configure how the syslog daemon handles daemon.alert activity on their systems. See the system log service configuration to identify where such messages are recorded.

After you locate and fix the problems, restart by using one of the following options.

  • If the audit service is in maintenance mode due to SMF-related issues, run the following command to start the audit service:

    # svcadm clear auditd

    For more information, see the svcadm(8) man page.

  • 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.4.

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 Tues Jan 5 10:10:10 2016
    Reason: Disabled by an administrator.
    See: http://support.oracle.com/msg/SMF-8000-05
    See: auditd(8)
    See: audit(8)
    See: auditconfig(8)
    See: audit_warn(8)
    See: ars(7)
    See: audit_flags(7)
    See: audit_binfile(7)
    See: audit_syslog(7)
    See: audit_remote(7)
    See: audit_sstore(7)
    See: http://www.oracle.com/pls/topic/lookup?ctx=solaris&id=OSMAA
    See: /var/svc/log/system-auditd:default.log
    See: /var/adm/messages
    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.


    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 24, Specifying Audit Classes for syslog Output and the usermod(8) 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.4.
  • 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(7) man page.

    For an example, see Example 20, 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(8) 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 Managing Secure Shell Access in Oracle Solaris 11.4.
Example 45  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)

crontab File Editing Fails With Audit Context Error

The following error indicates that you are not permitted to edit another user's crontab file:

not-sys# crontab -e sys
crontab: The audit context for your shell has not been set.

Even if audit logs are not being collected and the crontab process is not being audited, crontab only permits the crontab file owner, sys in the preceding command, to edit the file.

To verify that you are permitted to edit another user's crontab file, check the output of the following command, where PID is the process ID of your login shell. If this shell does not report a valid audit context, then crontab denies edits to the file.

auditconfig -getpinfo PID

To edit a crontab file that you do not own requires the solaris.jobs.admin authorization.