Single Sign on can be used without having the application needing it, so you
could put the profiles for the outsourcing outfit in the LDAP (eliminating a
password directly on the system) and control the access there. So while
your LDAP would not manage the application, it could manage access.
Without *SECADM rights, the *ALLOBJ user cannot change a user profile. It
cannot delete one or create one.
How big is this application? (numbers of objects) It occurs to me that
you might be able to accomplish the goal with a couple of authorization
lists. Put an authorization list on all the programs and other executables,
and another one on the data objects. Authorize who you need to get to the
application/data but put the admin profiles in *EXCLUDE. Then go to the
couple of dozen (at most) commands that an admin would really need on a
daily basis and authorize those commands to the admins.
I like the new features in IBM i for this purpose much better, but I've done
this other technique in the past too. It's not perfect by any stretch, but
it might get the 95% of the cases where *ALLOBJ is needed reduced to nearly
no additional authority needed. I'm guessing someone with the requisite
skills could build this in a couple maybe three days.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Laurence Chiu
Sent: Sunday, June 28, 2020 10:01 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Recommendation for IBMi privileges for an outsourcer to support
an IBMi environment
On Sat, Jun 27, 2020 at 4:15 AM <midrangel@xxxxxxxxxxxxxxxxx> wrote:
Laurence:
If they are truly a system administrator, without adding some of the
newer security features that IBM gave us in the more recent Technology
Refreshes and/or V7R4, there is next to no way to stop them from
seeing production data. If they want to, they will. The moment they
have access to a QSECOFR type profile, that door is open and you will
have a real hard time shutting it.
DO NOT let them use QSECOFR, in either IBM i or SST. Keep that profile
for
your organization. Create a new profile specifically for them that has
*ALLOBJ and *SECADM in addition to the list you provided. Do not put
*AUDIT in the list.
Create a profile in SST that has the authority you wish to give them,
but frankly to do the administrators job, they will need everything there.
Note: giving someone *JOBCTL also includes *SPLCTL so that's redundant.
No problem with it, just redundant.
Your list of special authorities below with allow them to do 90% of
what they need to do.
Who is going to manage user profiles? That list will not allow user
profile maintenance ( a good thing given your questions premise ). To
maintain user profiles you would need authority to the profile itself,
and *SECADM.
--
Jim Oberholtzer
Agile Technology Architects
That's really useful information. Thanks. Security profiles are going to be
managed by our internal security operations team. Would love to have LDAP
integration but this is a legacy application and nobody wants to invest in
the platform, So our security operations team take requests from a portal
and enable them manually. That means the oursourcer won't need *SECADM
presumably either. But won't *ALLOBJ mean they can see the data unless we
implement some of the suggestions discussed elsewhere in this thread?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
