| | | | |

Object Statistics: Last_used_object Field – Object Authorities

Note Be careful when you’re evaluating *DIR objects. The last-used date isn’t updated. In other words, you must evaluate the objects in the directory to discover the correct last-used date. In fact, this is where the field last_used_object recently added to both QSYS2.OBJECT_STATISTICS and QSYS2.IFS_OBJECT_STATISTICS table functions is handy. It provides an indication of whether…

|

Authority Collection in New Nav – Using Authority Collection to Reduce Users’ Authority

New Nav provides visibility into Authority Collection and, if you’re not comfortable with using SQL, may prove an easier interface for your analysis. To access Authority Collection in New Nav, click on the padlock icon > Authority Collection. From there, you’ll have to choose whether you want the Authority Collection for Users or Objects. In…

| |

User Profiles and the Audit Journal – User Profiles

It’s one thing to analyze profiles at a point in time (which is what I’ve been describing so far), but many organizations need to understand user profile configurations over time. For example, some organizations have a requirement to track all profiles created so an auditor can look at a report and determine if the appropriate…

| |

Group Profiles Without Members – User Profiles

Note that I’ve used group_id_number <> 0 to find the group profiles. When a profile is made a group (that is, it’s listed as a user’s group profile or one of its supplemental groups), it’s assigned a group ID (GID). Even after all of the members are removed from a group, it retains its GID,…

| | |

Limited Capabilities – User Profiles

You may also want to look at attributes such as the limited capability setting. Your review would be to make sure that any profile set to limited *PARTIAL or *NO really has a job requirement to use a command line. Inactive Profiles Finally, inactive profiles need to be managed so they can’t be used as…

| | | |

Analyzing User Profiles – User Profiles

It’s always good to begin at the beginning, so let’s do that. Basic Information Let’s start with the basics: SQL that mimics DSPUSRPRF *ALL to an outfile. Launch Access Client Solutions (ACS) and then click on Run SQL Scripts. When the window opens, type this: This Select statement provides information about all of the user…

| | | | |

QPWDLVL 4 – Moving to a Higher Password Level

A new password level, 4, was introduced in IBM i 7.5. This password level implements an even stronger method of encrypting the password. To facilitate the move to QPWDLVL 4, as of IBM i 7.5, IBM now generates passwords at QPWDLVL 2 and 3 that will work when the system is IPLed to QPWDLVL 4….

|

Determine the Users’ Source of Authority to Application Data after IPLing – Moving to a Higher Security Level

The next step is to determine how users are going to have sufficient authority to run the application once their *ALLOBJ authority has been removed. You must first decide what your security posture is going to be after the IPL. Do you want to have a secure posture so data can only be accessed by…

| |

Domain Failures- Moving to a Higher Security Level

The entries I typically find at my clients are D (domain failures) and more often, J (job description use). If you have any domain failures, the program name and library in the D audit journal entry identify the program running at the time of the failure. The object name is the object being accessed, and…

| | | | |

Moving from QSECURITY Level 30 to 40- Moving to a Higher Security Level

At security level 40, the operating system prevents certain actions from being taken. Examples include calling an operating system program directly, accessing an internal control block, and using a job description that names a user profile in which the caller doesn’t have authority to the named profile. The good news is that, while not prevented…