DanF

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:

GRTOBJAUT  OBJ( XYZ/ABC ) OBJTYPE( *FILE ) USER( USER ) AUT( *EXCLUDE )

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

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

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

DSPJRN JRN(QAUDJRN) RCVRNG(*CURCHAIN) FROMTIME(020811 0100) +
       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