AS400 System Value Settings Help?

AS/400 administration
AS/400 System Values
Audit and compliance
In our AS400 environment there are several individuals who has *SECADM and *ALLOBJ authority due to some reason, we are trying to investigate few incidents of system value settings which were changed but we don't who did it, any help or workaround which can lead us to the right path?

Software/Hardware used:

Answer Wiki

Thanks. We'll let you know when a new response is added.

If system auditing is set up correctly, you should be able to see system value changes by running the folowing command:


Discuss This Question: 6  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TomLiotta
    If you have auditing enabled and you have *SECCFG (or *SECURITY) set as one of the QAUDLVL values, then you can see details in your system's audit journal. An example command might be:
           JRNCDE((T)) ENTTYP(SV)
    The RCVRNG(*CURCHAIN) will include all audit journal receivers that are currently on your system and that are in an unbroken chain from the current receiver. You can say RCVRNG(*CURRENT) if you know that what you are looking for is in the currently attached receiver, or you can name a specific receiver or range of receivers. The FROMTIME(020811 0100) in the example says to start looking at Feb 08, 2011, and 01:00 AM. You can can enter specific starting and ending dates and times if you have an idea when the events happened. The JRNCDE((T)) ENTTYP(SV) says to look at security entries (code 'T') for system value change events (type 'SV'). But if you don't have auditing enabled, then you might be able to use DSPLOG to find CPF1806 messages. Those are not as reliable, though. Tom
    125,585 pointsBadges:
    You should probably think of some type of security reporting software, like Softlight Auditor, GFM Security Evaluator, or Power Lock. Then run the reports either daily or weekly and make sure someone looks at them.
    3,175 pointsBadges:
  • slack400
    I was going to draw out a long solution for you here... But you need to get those accounts locked down first. Any audit trail solution I give you here technically can be destroyed by a user with *ALLOBJ and *SECADMN rights. You can activate audit journaling and monitoring but if they're wise to what you're doing they can go back and delete the logs. If you have system event monitoring software like MPLUS you can activate a monitor that sends you an email or page when a system value is changed on the box. You need to escalate the issue and secure your system first, then design a proper security policy and implement it. Free resources from Powertech
    2,740 pointsBadges:
  • TomLiotta
    ..if they’re wise to what you’re doing they can go back and delete the logs. That is true and a valid point. But note that the audit log deletions will be logged in the current receiver, and there is always a current receiver when auditing is enabled. The audit level of the system would first need to be changed to turn auditing off, then at least all logs containing evidence would need to be deleted. Then, new versions of the QHST* physical files would need to be generated so that the versions that were active at the time changes were made could be deleted. If a person has *ALLOBJ, it's fairly easy to obtain any other special authority. It does take some effort to cover all of the tracks, though, and I haven't listed all of them. Tom
    125,585 pointsBadges:
  • TomLiotta
    It can take a lot of work to clean up excess authorities. It can be especially difficult when users who use special authorities are also knowledgeable. When they're not so knowledgeable, there are temporary ways to guide them into valid uses of authority while obstructing invalid uses. (These cannot be recommended for permanent implementation. They are too easily circumvented.) One such way is by creating a "group profile" that has the special authorities that you'd like to remove from the user. Then assign that as the group profile for the user when you remove the user's special authorities. The user will still have all of the abilities that were previously available. However, you can then apply some "private" authorities that remove the user's authority to specific objects. For example, if you wanted the user to stay out of file ABC in library XYZ, you could:
    Until the user manipulated things to get authority through a different route, that file would be restricted from the user even with *ALLOBJ available through group authority. That's because the system checks private authority before group authority, and authority checking is stopped as soon as a specific authority is encountered. The private *EXCLUDE authority will be the first one found, so the system stops searching. It's essentially guaranteed that you can't assign private *EXCLUDE authorities to enough objects, nor to all of the right objects, to make such a scheme practical for any length of time. But it can be a useful stop-gap method to give you a little extra time to get things more under control. It will also generate Authority Failure events in the audit journal (if enabled) so you might receive a little warning when the user is attempting access that ought to be monitored. Tom
    125,585 pointsBadges:
  • DanTheDane
    Have you considered the possibility that it might be a program issying a CHGSYSVAL cmmand? - just a thought ... DanF
    2,555 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: