Tracking *ALLOBJ users

Confused by what do you mean "when that user needs *ALLOBJ special authority"?  

*ALLOBJ special authority is just that - a special authority that short-circuits security checking for a given user.  It basically says, "no need to check any further, this user is authorized to all objects on the system".

There is no explicit setting on an object that says "'*ALLOBJ special authority needed to access this object" (You can revoke all private and public authorities to an object, which implicitly limits access to the object to *ALLOBJ users).

Basically, the AS/400 security checking mechanism first looks to see if a user has *ALLOBJ authority, and if they do, access is granted to the object, and no further checking is done.

It is a common practice to audit the activities of *ALLOBJ users, since they have so much power.  Perhaps this is what you are referring to:

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzamv/rzamvauditsecofraction.htm

- Gary Patterson

I was at a user group conference and someone there mentioned that there is a 'report' that can be run that shows when a profile actually needed *ALLOBJ to perform a particular function.  Just because you have *ALLOBJ does not mean you use it all the time.


I will attempt to gather more info.

Barry,

I think you've got your wires crossed here somewhere.

If your profile has *ALLOBJ special authority, you use it (almost) all the time.

See the security Reference, Chapter 5 - Resource Security, Topic "How The System Checks Authority":

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/books/sc415302.pdf

p149:

p148:

Maybe you are thinking about adopted authority.  

Anyway, the "reports" you are talking about are audit reports, and they can indeed report the actions of *ALLOBJ users (if configured properly), and the use of adopted authority (which is what I think you may be confusing *ALLOBJ with).   The security reference (link above) is full of info on auditing.

- Gary Patterson

The invocation of "adopted authority" is as close as I can get to anything like this, but even that wouldn't necessarily provide "*ALLOBJ" special authority. It only needs to provide whatever authority is available to satisfy the need. It might, for example, provide owner's authority through the object's authority.

I won't make a flat statement that no such report exists, but I haven't heard of any even for i v7.1 -- until this question. I'll certainly be watching to see if I run across anything now that someone has asked. Every once in a while such things show to be valid.

Tom

I have also not heard of anything like this until today.  
I am not thinking of adopted authority. I am quite familiar with most apsects of scurity on the i.  
The reason this thought resonates with me is that there are sometimes application upgrades or installs and requests come in for *ALLOBJ or QSECOFR and this has been going on long before I joined this company.  In any event, I want to determine if in fact this level of authority and access is even needed.   I've turned on *CMD auditing for these users (QSECOFR is already set up) and this type of report (seeing if a user actually needed *ALLOBJ to perform the task) would aid me from going through each command that was issued and checking each object's authority so I can present my case that this authority is not needed.

I will let you know what info I find out.

Barry

Barry,

I understand why you'd like such a tool.  I can see how it would be handy, too.  

Anyway, if you discover a tool for analyzing the need for a given special authority, I'd be interested in learning about it.

In the meantime ...

I've worked for several AS/400 software houses, and I can tell you first-hand why upgrade and install processes specify a profile with *ALLOBJ:  To reduce the number of security-related problems (and related support calls) that occur during upgrade or install.  Is QSECOFR or *ALLOBJ always required?  No.  But since the developers cannot predict all of the possible security permutations implemented on every system in every shop, installation and upgrade instructions frequently specify a profile with a very high level of authority - generally QSECOFR, since it is an IBM-supplied profile that typically has a full complement of special authorities.

- Gary Patterson

I'm awaiting a reply from the sessoin speaker.  He briefly stated that the data is in the audit journal but he couldn't recall the entry type.

More to come.

all you really need is Query/400.  

DSPOBJD userprofile objects to an outfile

run query across the file to generate your reports.

do this monthly, in various formats and you can control your users very easily.

in otherwords, identify by object authority, user type (QPGMR; QUSER;SECOFR, ETC)

-Lurpdog

Lurpdog,

Take a look back at the original question.  

How is querying over a DSPOBJD going to help you track a user's activities, or determine when a user needed *ALLOBJ authority to perform a particular function?

- Gary

gary,

i agree about the tracking not being the exact answer i gave, what i was giving was an inexpensive method to monitor your users and authorities.

there are numerous products that will charge you to do this, but with a few simple Query/400 reports, you can monitor your users, their activity (of course this comes from DspLog) and others environmental data for the "whatever ibm calls the as/400 these days".

sometimes its a multi-tiered operation. first determine who has what authorities; reduce the authorities to the minimum required; track users who have certain special authorities.

even having QSECOFR password, does not mean that i sign on with it since i have another user id that has that authority. i dont use it either, unless installs require it.

even SECADMN is given overmuch in my opinion, in many of the shops where i consult.

-lurpdog.

Well it was too good to be true.  The session speaker had it completely wrong and this is why none of us had ever heard of such a thing.
In short, what had occurred was that a consultant was taking a client from security level 20 to security level 30 so while at level 20, they took away *ALLOBJ on some users, ran a mock application to simulate what might happen at level 30.


Barry

not all consultants are born equal :)

There really was no solution since information originally received was inaccurate.