On 10-Sep-2015 12:45 -0600, Justin Taylor wrote:
We're getting a large number of these show up in our audit logs. I'm
trying to track down what's causing them. <<SNIP>>
If none of the following assists, then additionally consider use of a
Job Trace (STRJOBTRC) to track-down the error\condition within the job
for which the T-AF is logged; likely visible with an INTXHINV and, IIRC,
followed by an EVENT for which a program then performs the insert of the
journal entry] within the [spooled file] data that gets produced.
From the following web search:
The following were located:
The origin of the T-AF Violation Type=K:
iSeries Memorandum To Users (MTU)
Version 5 Release 3 (May 2008 update)
New security auditing for special authority violations
A new violation type of ″K″ has been defined for the Authority Failure
(AF) audit record. The ″K″ violation type indicates that a special
authority violation was detected. As a result of this new violation
type, the CPF2220, CPF4AAE and CPF2246 messages will no longer be sent
to the history log (QHST); instead, look for violation type ″K″ AF audit
records to determine if a special authority violation has
occurred. Some violation type ″A″ AF audit records, which were generated
for special authority violations, will be changed to the new violation
type ″K″ AF audit records.
An addition to the T-AF Violation-Type=K:
SI13520 - OSP Special authority violation auditing
Software version: V5R3M0
Reference #: SI13520
DESCRIPTION OF PROBLEM FIXED FOR APAR SE15239 :
When a caller of an internal trace function does not have
*SERVICE special authority, then an authority failure audit
record should be recorded.
CORRECTION FOR APAR SE15239 :
Special authority violations will be recorded in the security
auditing journal (QAUDJRN) as a new violation type (K) of the
authority failure (AF) audit record.
Some documentation of the layout of the Authority Failure (AF)
journal entries; including mention of Violation Type of K as "Special
As an Amazon Associate we earn from qualifying purchases.