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???)