Who’s Got the Keys to the IBM i Kingdom?
Come with me on a hunt for *ALLOBJ Profiles
Picture this: you’re the sheriff of your IBM i system, tasked with guarding the kingdom from rogue profiles wielding the ultimate power… that super *ALLOBJ special authority. This is the kind of power that lets someone rearrange the furniture in every room of the castle, whether they meant to or not.
Maybe someone got a little too click-happy and created a profile with more authority than a caffeinated sysadmin on a Monday morning. Or perhaps a profile was given *ALLOBJ for a “temporary” task… six months ago. Yikes! Regularly checking who’s got these skeleton keys is critical to keeping your system from turning into a wild west show.
Lassoing Those *ALLOBJ Profiles: Two Ways to Wrangle ‘Em
There are a couple of trusty steeds you can ride to round up profiles with special authorities. First up, we’ve got the Print User Profile command, or as I like to call it, the “Spool File Avalanche Starter Kit.” Just fire up PRTUSRPRF TYPE(*AUTINFO), and BOOM – a spooled file listing every profile on your system, complete with their group profiles and any special authorities they’re packing.
PRTUSRPRF TYPE(*AUTINFO)
It’s like getting a phonebook dumped on your desk when you just wanted to know who’s got the keys to the executive washroom.
This method works fine if your system has fewer profiles than a small-town book club. But let’s be real: scrolling through a spooled file to spot *ALLOBJ is like trying to find a needle in a haystack… while wearing oven mitts.
Visual verification? More like visual desperation.
Now, if you want to trade in your magnifying glass for a lightsaber, I’ve got a better way: the QSYS2.USER_INFO SQL view. This is where the IBM i wizards at IBM have sprinkled some serious magic dust. They’ve even gift-wrapped an example for us to track down those *ALLOBJ culprits. Here’s how to channel your inner SQL Jedi:
- Fire up Access Client Solutions (ACS) and mosey on over to Run SQL Scripts.
- Click Edit > Examples > Insert from Examples.
- In the dropdown, select IBM i Services, then scroll down to the Security section. Look for the golden ticket: *Security – Review ALLOBJ Users.
- Preview the SQL (because who doesn’t love a sneak peek?), then hit Insert to make it yours.
And look at these beautiful, easy to read results:
Want to jazz it up? Toss in some extra fields like Last Used Date to see if that *ALLOBJ profile has been collecting dust since the last Y2K scare.
Here is the sample SQL statement if you want to copy/paste/play:
-- category: IBM i Services
-- description: Security - Review *ALLOBJ users
--
-- Which users have *ALLOBJ authority either directly
-- or via a Group or Supplemental profile?
--
select AUTHORIZATION_NAME,
STATUS,
NO_PASSWORD_INDICATOR,
PREVIOUS_SIGNON,
TEXT_DESCRIPTION
from QSYS2.USER_INFO
where SPECIAL_AUTHORITIES like '%*ALLOBJ%' or
AUTHORIZATION_NAME in (
select USER_PROFILE_NAME
from QSYS2.GROUP_PROFILE_ENTRIES
where GROUP_PROFILE_NAME in (
select AUTHORIZATION_NAME
from QSYS2.USER_INFO
where SPECIAL_AUTHORITIES like '%*ALLOBJ%'
))
order by AUTHORIZATION_NAME;Add the special authority and group profile fields to figure out if the profile is strutting its *ALLOBJ stuff solo or inheriting it from a group profile like some kind of trust-fund superpower.
It’s like doing a background check on your profiles to make sure they’re not secretly living the high life.
Why This Matters (No, Really!)
Checking for *ALLOBJ profiles isn’t just a fun way to spend your afternoon, it’s your ticket to keeping your IBM i kingdom safe from accidental (or not-so-accidental) chaos! With the SQL method, you’re not just wrangling profiles; you’re doing it with style, precision, and a touch modernity.
So, saddle up, sheriff, and go hunt those overpowered profiles before they turn your system into a free-for-all rodeo!
