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
  
  0x0100000000000000:pf:profile
  

• The mask is unique. If it is not unique, replace the mask.

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

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.