User Audit Fields in the audit_user
File

If it is desirable to audit some users differently from others, the administrator
may edit the audit_user file to add audit flags for individual users.
If specified, these flags are combined with the system-wide flags specified in the audit
control file to determine which classes of events to audit for that user. The flags the
administrator adds to the user's entry in the audit_user file modify
the defaults from the audit_control file in two ways: by specifying
a set of event classes that are never to be audited for this user or by specifying a set
of event classes that are always to be audited.

In the audit_user file entry for each user, there are three
fields. The first field is the username, the second field is
the always-audit field, and the third is the never-audit field. The two auditing fields are processed in sequence, so auditing is
enabled by the first field and turned off by the second.

Note -

Avoid the common mistake of leaving the all set in the never-audit field. This causes all auditing to be turned off for that user,
overriding the flags set in the always-audit field.

Using the never-audit flags for a user is not the same
as removing classes from the always-audit set. For example,
suppose (as shown in the examples below), you have a user fred for whom
you want to audit everything except successful reads of file system objects. (This is a
good way to audit almost everything for a user while generating only about three-quarters
of the audit data that would be produced if all data reads were also audited.) You also
want to apply the system defaults to fred. Here are two possible audit_user entries.

The correct entry:

fred:all,^+fr:

The incorrect entry:

fred:all:+fr

The first example says, "always audit everything except successful file-reads."
The second example says "always audit everything, but never audit successful file-reads."
The second example is incorrect because it overrides the system default. The first example
achieves the desired effect: any earlier default applies, as well as what's specified in
the audit_user entry.

Note -

Successful events and failed events are treated separately, so a process can (for
example) generate more audit records when an error occurs than when the event is successful.