Rob / Charles
I found out why most installs fail if not run as QSECOFR, and how to fix them.
If the original install was done as QSECOFR, then you probably need QSECOFR or equivalent for the next upgrade etc, (delete objects, etc)
However, If you do a new clean install as another user, and use a group profile as the owner, I have successfully installed and ran 3rd party software not as QSECOFR.
I wasn't allowed to put this into production.
I created a copy of QSECOFR, ran the job as ISECOFR, everything ran fine for months, but I got caught, "Why is that job not running as QSECOFR"
If something would fail for an authority issue, I'll get "I told you so" "You must listen to how they tell you do install, don't question and try to do it your way"
They never give a detailed explanation of why it must be QSECOFR.
Another issue with QSECOFR, only allowed in basic job scheduler, AJS does not allow it.
Below is one example.
Create a Job Scheduler entry (ADDJOBSCDE).
The following is a more specific example you could use if your IPL happened nightly:
ADDJOBSCDE CMD(CALL PGM(NIXXXXPGMS/NIMLISTNCL) PARM('3786' QGPL NIM8XJOBD))
FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*ALL) SCDTIME('hh:mm:ss') JOBD(QGPL/
NIM8XJOBD)
JOBQ(QGPL/QINTER) USER(QSECOFR) TEXT('NIM TCPIP C/S Dispatcher')
While it is recommended to use the QSECOFR user ID, it is not necessary to set the USER
parameter to QSECOFR as above, but the user parameter you supply must have the following
authorities:
*ALLOBJ authority. It is responsible for validating AS/400 user profiles and passwords when
client connection requests are received.
*USE authority for objects QSYS/QSYGETPH and QSYS/QSYRLSPH.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, May 01, 2014 2:25 PM
To: Midrange Systems Technical Discussion
Subject: RE: i5 Security info and training
Only one of our developers has a second account that has a high level of security. And he pretty much reserves it only for helping us run Mimix.
I kept hearing this whining "but what about that emergency middle of the night call that needs it?". Situation is, it hasn't happened in over 10 years. Sure, there have been late calls, but none, zippo, that just had to have qsecofr type access.
Honestly, it used to frustrate me to no end that vendors required qsecofr to install their product. I guess it just works.
OTOH, keep your guard up. We had a vendor that had a program with qsecofr adopted authority. One line: CALL QCMD. Apparently it was their back door to talk users through some stuff remotely without having to file a
100 page exception report with the customers security officer on why they needed qsecofr.
We no longer do business with them.
I sincerely believe that many vendors really tried to get their installs working as other than QSECOFR, but after this failure, and that failure, just gave up.
Some of their installs I wonder how they ever get through them.
Hopefully in this age of virtualization they will try their installs on clean lpars. And not the same old lpar where their owning profile already existed or whatever.
If your developers keep needing qsecofr access they're doing it wrong.
That's like having first aid equipment down at the bottom of the ski slope not "just in case" but "we're going to use it at the end of every run".
I realize it get's trickier when you have interfaces between disparate vendor applications. Heck we got through this and we used to have ERP by one vendor and accounting by another.
You know what really helps? A good change management package. One that knows, and can be configured to set up things like: programs that need to adopt authority, programs and data that have special authorization lists and stuff set up on them.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 05/01/2014 01:31 PM
Subject: RE: i5 Security info and training
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Thanks everyone for all the links, keep um coming.
Define security - all of what Rob mentioned, plus much more.
The sad thing is some of the things I need to change and fix are denied.
3rd party vendor claims their job(s) must run as QSECOFR, I tested and
made it work in R&D without QSECOFR.
All programmers and all of one of our 3rd party support accounts (100+)
are QSECOFR equivalent and *ALLOBJ.
We have done a lot in the last 2 years.
Convert as many FTP to SFTP via SSH.
Eliminate shared accounts, setup individual service accounts.
Much more to do.
Now that I have my guest LPAR playground setup, I can make and test
security changes, hopefully without breaking anything.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Thursday, May 01, 2014 12:10 PM
To: Midrange Systems Technical Discussion
Subject: RE: i5 Security info and training
What is the definition of security?
- User security?
- Object security?
- Proper security setup of your Domino environment?
- How to implement kerberos?
- Proper http configuration?
- Proper WAS administration?
- How to implement Tivoli Identity Manager?
- How to roll out RCAC in your 7.2 environment (Row and Column Access)?
- Little obscure stuff to set up in TCP/IP?
80% of that would blow away our BOFH.
Basically, what is the OP targeting on?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
