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?

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your response...

Discuss This Question: 6 &nbspReplies

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

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

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

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.

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

..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

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

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your reply...

Ask a Question

Free Guide: Managing storage for virtual environments

Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!

To follow this tag...

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy