Information Systems:IBM i User and Object Security
User Security
A user profile needs to be set up before they can sign on to the System i; this includes green screens (or Mocha), ASW GUI, RF guns and InfoNet.
We do not delete profiles; when they are no longer used (when a uniPHARM employee leaves, or an Adecco employee has not signed on within the last twelve months), they are disabled.
There are several types of users –
Warehouse (Adecco) – These can be identified by ‘AD ‘ in the first three characters of the user name. They usually can only use the RF guns; not terminals. This is controlled by having the initial program RFOSIGNON (Signon Program for RF ONLY) in library UWDQSYS. Some users need to be able to use a terminal – for instance if they are working in Returns – so they will have RFSIGNON. They have no special authorities, and user class is *USER.
Warehouse (uniPHARM staff) – They have an initial program of RFSIGNON so they can use both RF guns and terminals. They have no special authorities, and user class is *USER.
Warehouse Test User – This is a single user (SHEILAUSER), who has an initial program of RFSIGNONPL. This will connect the user to the test libraries (PL) instead of production (VA). This has no special authorities, and user class is *USER.
Regular Office Staff – These people have an initial program of UNITY; which allows them to go into ASW or the Extensions. They have no special authorities; except for Nancy, John, and Stephen. User class is *USER.
ASW Power Users – FINADMIN – This has the group profile ASW4ADM. This gives it access to sensitive tables that regular user don’t have, and allows it to post batches that are out of balance. This profile also owns all the finance spool files (from end of day, and end of month. DISADMIN – This user can change unit of measure conversion factors for items with activity, get into a sales order that is locked by another user (carefully – only when it really isn’t), change an existing sales order line, and change contract billing records. User class is *USER.
IT Staff (Including Consultants) – These do not have an initial program to call, and are user class *SECOFR (uniPHARM) or *PGMR (consultants). They also have some special authorities
Profiles for Scheduled Jobs – Each job that is submitted by the scheduler runs under its own profile. This allows us to set up environments, and to keep spool files separate. They have high authorities, but cannot sign on as their passwords are set to *NONE. The exception is EODJOB, which we need to be able to sign on as. The text for all these jobs starts with ‘To run’, then describes what they are to run; ie ‘To run EDI monitor’.
Profiles for Servers – Services that run on Windows servers, and that need to share data with the System i, need a user ID on it. This user ID and password will be in the servers, so cannot be changed on the i. (And cannot be set to *NONE.) These profiles are CATPULTADM, GAUSSADMIN, JETFORMS, and OMSAGENT. Some profiles that I am unsure of, but may be like this are CIBCEDI, PRTACCT, and SSHUSER – so I’m leaving them as is.
IBM Profiles – These all start with the letter ‘Q’, and are set to password equal *NONE as they are never used to sign on.
Group Profiles – These are not used to sign on (so the password is *NONE), but to create authorities once, and then assign to multiple users.
Object Owners – When an application is installed, it is best done by a specific user ID (for example ASW4OWN), instead of a random programmer. These are not used to sign on (so the password is *NONE).
If you are worried about the security of these, you can look at the date these profiles last signed on, (which is not updated when a Window server connects with the profile), and monitor for use. To do this, key in, for example, DSPUSRPRF GAUSSADMIN and press enter.
Display User Profile - Basic
User profile . . . . . . . . . . . . . . . : GAUSSADMIN
Previous sign-on . . . . . . . . . . . . . : 04/28/06 14:29:47
Password verifications not valid . . . . . : 0
Status . . . . . . . . . . . . . . . . . . : *ENABLED
Date password last changed . . . . . . . . : 06/17/03 10:38:37
Password is *NONE . . . . . . . . . . . . : *NO
Password expiration interval . . . . . . . : *SYSVAL
Password set expired by command . . . . . : *NO
Block password change . . . . . . . . . . : *SYSVAL
Local password management . . . . . . . . : *YES
User class . . . . . . . . . . . . . . . . : *USER
Creation date/time . . . . . . . . . . . . : 06/17/03 10:38:37
Change date/time . . . . . . . . . . . . . : 11/11/11 10:27:39
Last used date . . . . . . . . . . . . . . :
Restore date/time . . . . . . . . . . . . : 11/10/07 08:48:22
Special authority . . . . . . . . . . . . : *SPLCTL
Press Enter to continue.
F3=Exit F12=Cancel
Currently, the last used dates are -
CATPULTADM 21 Jan 2015 GAUSSADMIN 28 Apr 2006 JETFORMS never OMSAGENT 3 Mar 2004 CIBCEDI 14 Jun 2006 PRTACCT 17 Dec 2013 SSHUSER 16 May 2008
CATPULTADM has a last used date of 21Jan 2015 because I changed the password to *NONE, then had to change it back when the Catapult service failed.
Object Security
Unless a user has all object authority (only power users do), the operating system controls what users can do with objects.
Files for example.
Edit Object Authority
Object . . . . . . . : SRONAM Owner . . . . . . . : UWDPROGRAM
Library . . . . . : UP1480BFVA Primary group . . . : *NONE
Object type . . . . : *FILE ASP device . . . . . : *SYSBAS
Type changes to current authorities, press Enter.
Object secured by authorization list . . . . . . . . . . . . *NONE
Object
User Group Authority
*PUBLIC *CHANGE
UWDPROGRAM *ALL
ASW4DEV *ALL
ASW4OWN *ALL
ASW4SEC *ALL
F3=Exit F5=Refresh F6=Add new users F10=Grant with reference object
F11=Display detail object authorities F12=Cancel F17=Top F18=Bottom
Regular users (*PUBLIC) can look at a file, and add/change/delete individual records. They cannot copy files (what else???)