Re: CHGSMTPA auditing

Sanjivji wrote:

I have Object auditing *change defined for CHGSMTPA

Someone changed firewall parm in it. How can I find as who did
it?

Even with auditing on CHGSMTPA I cannot see any journal entries
specific to it

Auditing *CHANGE for the *CMD object CHGSMTPA will not track
usage [i.e. invocation] of the command, only if the *CMD object were
changed. Only by using CHGOBJAUD QSYS/CHGSMTPA *CMD OBJAUD(*ALL)
would logging of T-ZR entries logged for the use of the change SMTP
attributes command. Thus why, probably, testing CHGSMTPA effected
no logging. Of course be sure also that *OBJAUD is active in
QAUDCTL, else no effects from CHGOBJAUD would be manifest in the
auditing irrespective of chosen level of auditing for the object.

However, it may not be by that command interface from which
changes were made. The iNav interface is more likely, and it
probably does not use the *CMD object to effect the changes; rather
an API or SPI is more likely. There is also the less likely case
whereby a restore effected reverting to a prior level. And even
less likely would be a[n improper\in error] conversion; e.g. on v6r1
the data in that member is converted to a new format, and in some
odd instances either a conversion might be effected in error or a
conversion might have an error in carrying the old value to its
newer form.

The configuration data for SMTP is stored in a member CONFIG of
the file QATMSMTP in QUSRSYS. DSPFD QUSRSYS/QATMSMTP will give
information about restore or change activity to the member & data,
and DSPOBJD QUSRSYS/QATMSMTP *FILE *FULL [and perhaps *SERVICE too]
will record information more generally of the *FILE [not the
member\data. However since the CHGSMTPA has already been used to
change the data since the prior suspect change, the timestamp for
when data had changed as displayed by the DSPFD member details,
would no longer show the suspect change. But of course next time,
collecting the OUTPUT(*PRINT) of the above command invocations
before effecting any "correction" would leave a record of the
timestamp for prior change activity.

If the file QATMSMTP is journaled [see the DSPFD & DSPOBJD] then
DSPJRN of that journal to see what job at what time had changed the
data; i.e. what\who\when the configuration was changed. If the file
is not journaled, then either CHGOBJAUD QUSRSYS/QATMSMTP *FILE *ALL
or STRJRNPF QUSRSYS/QATMSMTP to a journal to be reviewed after a
suspect configuration change.

Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.