How to limit a user profile to one particular subsystem or limiting the user to submit his job to a particular subsystem?

Hi Readers,

You must be thinking why it is required to limit a user profile to access a particular subsystem or submit job to one particular subsystem. Why and how is it beneficial?

Well we can do this by creating a private subsystem or a separate subsystem or by assigning the user profile to access only that subsystem. Now, when is it required. In scenario's where you want a user to access the system resource during a particular time period. For example, in most of the IT scenario's the admin department accesses the system in OOH(Out of office hours). It is not required by other user's to access the system during this time. You might need only the admin team to carry on with their processes during backups or when system is in restricted state. For this, if you set up a separate subsystem and assign the team members of Admin team to it, then you can bring down QINTER subsystem ( default subsystem for all interactive users) thus restricting all users except Admin to access the system.

Lets now, see how you can create a private or separate interactive subsystem and segregate user profiles to access them.

1- Create new subsystem for interactive processing.
2- Create a job queue that feeds interactive jobs to that subsystem and assigns that job queue to the subsystem.
3- Change your subsystem attributes to allow specific workstation names or workstation type to enter this subsystem.
4- Change QINTER attributes to not allow the devices and jobs which are intended to run in private subsystem.

Note :- This process allocates the devices ( that is workstation by name or type) to the particular subsystem and does not restrict the user profile. When a user profile signs on the the particular device, it automatically redirects to this subsystem.

1 - Create Subsystem :- 

Let us now create a new interactive subsystem named QINTER1.

We can use CRTSBSD or CRTDUPOBJ to create this subsystem.

CRTDUPOBJ OBJ(QINTER) FROMLIB(QSYS) OBJTYPE(*SBSD) TOLIB(QGPL) NEWOBJ(QINTER1)

2- Create Job queue to feed new subsystem :- 

Use CRTJOBQ to create a new JOBQ.

CRTJOBQ JOBQ(QGPL/QINTER1) TEXT ( NEW JOB QUEUE FOR INTERACTIVE WORK)

3- Add Job Queue to new subsystem to accept the jobs from the Job queue.

Use command ADDJOBQE

ADDJOBQE SBSD(QGPL/QINTER1) JOBQ(QGPL/QINTER1) MAXACT(*NOMAX) SEQNBR(30)

4- Since, QINTER1 is a duplicate of QINTER, it inherits QINTER Job Queue. Need to remove this QINTER job queue from QINTER1 subsystem, so that jobs that should run under QINTER will go there and not be diverted to QINTER1.

Use RMVJOBQE
RMVJOBQE SBSD(QGPL/QINTER1) JOBQ(QSYS/QINTER)

Check, which all JOBQ was added to QINTER subsystem and remove them from QINTER1 as it is a copy of QINTER subsystem. To do this, DSPSBSD SBSD(QINTER)

TAKE OPTION 6 :- JOB QUEUE ENTRIES
Seq  Job                       Max   ---------Max by Priority----------
Nbr  Queue       Library     Active   1   2   3   4   5   6   7   8   9
 10  QINTER      QGPL        *NOMAX   *   *   *   *   *   *   *   *   *
 20  QS36MRT     QGPL        *NOMAX   *   *   *   *   *   *   *   *   *

This means, QINTER subsystem, feeds QINTER and QS36MRT job queues to it. So, now remove QS36MRT from QINTER1 subsystem job queue enteries.

RMVJOBQE SBSD(QGPL/QINTER1) JOBQ(QS36MRT)

5- Limit the workstation types that can enter subsystem QINTER1.

To authorize workstation whose name start with letter AD* (exa -AD001, AD002)

ADDWSE SBSD(QINTER1) WRKSTN(AD*)


You can view which all workstation are added for this subsystem QINTER1 by DSPSBSD SBSD(QINTER1)

Take option:-

4. Work station name entries
5. Work station type entries

You could see AD* in option 4 and *CONS and *ALL in option 5. You can remove *CONS and *ALL and thus it will limit access only to AD* workstation.

To remove,

RMVWSE SBSD(QGPL/QINTER1) WRKSTNTYPE(*CONS)

RMCWSE SBSD(QGPL/QINTER1) WRKSTNTYPE(*ALL)

How to limit user profile to access command line?

This is a very common interview question, if you have already read the post http://isliverlake.blogspot.com/2013/06/lets-get-started-with-user-profile-in.html
you know the answer. LMTCPB(Limit Capability) is the parameter that is responsible to provide access and restrict access to command line. 

Limit Capability :- LMTCPB parameter tells the OS400 two things. First, it tells the OS400, if the user can make changes to ITLPGM, ITLMNU and current library values. Secondly, it says the OS400 if the user has access to command line.

When it is set to *NO, the user can make changes to ITLPGM, ITLMNU , current library and ATTN key values and also it can use the command line to run AS400 commands.

When it is set to *PARTIAL, the USER cannot make any changes to ITLPGM, ITLMNU, current library and ATTN key value but it has access to command line and can run AS400 commands.

When it is set to *YES, the user has neither access to make any changes to ITLPGM, ITLMNU and current library nor it can access command line.

These three parameters ITLPGM, ITLMNU and LMTCPB have ability to restrict users. For example, for the server users who do not require to access the green screen 5250 emulator, can have ITLPGM as *NONE, ITLMNU as *SIGNOFF and LMTCPB as *YES. They can still access AS400 from other server which are connected to AS400. However, if the same user tries to access the AS400 from 5250 emulator, it will immediately bring the user to signoff screen thus restricting access to AS400 and command line.

Deleting User Profile's in AS400

I am conclude User Profile topic with this topic until, I come across something that is interesting and important piece of  fact that I am missing to describe.

Deleting user profile's in AS400 is simple but it needs to have a look at many important piece of objects and items before we actually delete a user profile.

Why we need to analyze before deleting a User Profile?

An user can create objects and have access to many files and objects that could be affected the moment we decide to delete an user profile.

What all things we need to consider before deleting User Profile?

As per industry best practices, it is required to meet the audit compliance with SOX (Sarbanese -Oxley) and HIPAA(Health Insurance Portability and Accountability Act). 

If your company follows these standard and needs to meet audit compliance for SOX and HIPAA, then you might need to have proof of when the user left the organization and when the request was raised to remove the user profile. You might need to maintain a document based on the organizational practice. 

Sometimes, you might be required to immediately disable the User Profile after the person left the organization. This can be done by CHGUSRPRF.

CHGUSRPRF USRPRF(user_name) STATUS(*DISABLED)

Before, deleting a user profile it is needed to transfer all the objects that the user profile owns to another user. This is so because AS400 OS will not allow you to delete an User Profile if it has objects that it owns.

You can identify whom to assign the objects after checking with the group to whom this user belongs and then transfer all the objects that is owned by the user profile.

To identify the objects that the user profile owns, you can do

WRKOBJOWN USRPRF(user_name)

This can also be done by i Series - navigator.

You also need to identify how critical the user profile is, before you think of deleting it. There could be many user profiles which can not be deleted at all. Some basic example would be of the programmer or the programming manager who have designed almost all the programs and have setup all the interfaces. The administrator who have setup most of the batch jobs and the operator or user who have been for so long that it is difficult to figure out, which all jobs, objects and interfaces will be affected when the profile is deleted.

Such, user profile just reside in the system forever. 

If the user profile is not critical then get approval to delete the user profile from the departments required and  remember to document it before you proceed to delete the user profile. 

Deleting user profile :- 

WRKUSRPRF USRPRF(user_name)

Option 4 next to the user profile to delete the same. 

If the user profile will not delete that means there must be some objects that the User profile owns. Now, to change the ownership of the objects, use below command.

WRKUSRPRF USRPRF(user_name)

Take  option 12 to find the objects owned.

Take option 9 to change the owner.

Or you could also change the ownership of objects owned at the time of deletion by using the below command.

WRKUSRPRF USRPRF(user_name)

Take option 4 and prompt ( f4)

owned objects value => *CHGOWN

user profile name is *CHGOWN => OBJOWNER (this user will own the objects after deleting the user profile)

This can also be done by iSeries- navigator .Select the user profile and right click and select delete user profile. The below screen will appear where you can change the ownership of objects owned and then delete the user.

AS400 Group Profiles and some points to keep in mind

OS/400 group profiles are a boon to system administrators as they allow them to centralize object authority administration for several users in one place. A Group profile can be created in similar way as an user profile. While creating other user profile that are member of this group profile, mention the group profile name in group profile parameter(*GRPPRF).

Group profiles also have their downside and needs proper administration. Here are few industry best practices that we need to follow to avoid any loop-hole that can be a threat in security of the system.

1- Group profiles should not be allowed to sign-on to the system :- When a user is a member of a particular Group profile it inherits all the level of access that the Group profile has.  Since, group profile provides authority access to all the member user profiles, it has object authority that is fixed for all the member profiles.By changing authority at group level it affects all the member profiles.

 According industry best practices, it is not advisable to provide any user with group profile access. Therefore, the password of Group profile is set to *NONE. This restricts users to access the system using group profile.

CHGUSRPRF USRPRF(group profile name) PASSWORD(*NONE)

If you have a large number of group profiles in your system and you want to check which of them have any password, then use the below command.

DSPAUTUSR SEQ(*GRPPRF) OUTPUT(*PRINT)

2- Group Profiles should not own production objects :- Object owners are super users for all the objects they own. They can change, delete and move objects. Therefore, Group profiles should not own production objects as that would give access to all the member profiles.

This problem is compounded when software package specifies that all authorized users must belong to the group profile that owns the application objects.

3- Group profile should not have ALLOBJ authority :- User profiles like QSECOFR must not be a group profile. Administration profiles that have *ALLOBJ authority when made a group profile will give *ALLOBJ authority to all its users thus enabling them to do anything with all the objects. And this itself violets the purpose of having Group profile to secure objects.

4- Supplemental group profiles :- One user can have more than one group profile. While creating user profile you can specify one name in *GRPPRF parameter and you can specify upto 15 other group profiles in supplemental group profile parameter. *SGRPPRF. This is required when one person can have access to more than one department and would need to have different object authority based on different departments.

How to remove member user profiles from a group profile?

At times, you would be required to remove the group profile from many member user profiles. To perform this when the number of user profiles is more, it is easier to do via Ops navigator than modifying each one through emulator.

Go to iSeries Navigator and expand User ->Group->Group node

Now expand the group profile and highlight the users for which you want to remove the group profile name. Right click and select remove group profile.

Delete Group Profile :-

If you want to delete a group profile , then first you have to remove all the user profiles that are member of this group profile and also check if the group profile owns any object. Once these are cleared you can remove the group profile from the system via 5250 or Ops Navigator.

Adding user profiles to authorization list

After, you create an user profile in AS400, it is required for Admin to ensure this user profile has been added to relevant authorization list.

What is Authorization list and how is it useful?
An Authorization list is a special system level object that resides in QSYS library with object type *AUTL. It simply defines user authority for objects belong to the list. Instead of providing individual private authority to an object when it is created, it is better to associate an object with appropriate Authorization list. The list will control individual and *PUBLIC authority of the object in the list.

It is beneficial in following way:-

1- Individual size of user profile is kept much lower by using Authorization list.
2- System performance is improved when running SAVSYS backup and saving security information by using SAVSECDTA.
3- Security changes can be made to object when the list are open and active. Only objects with private authority needs to be used when not in use.

How to create Authorization list?

Use command CRTAUTL  to create a new Authorization list.
Set *PUBLIC authority level using AUT parameter.

Once this is created you can work on it using EDTAUTL command.

You can grant object authority by GRTOBJAUT command or by adding objects to the list by ADDAUTLE.

Steps to create authorization list and add users is listed below.

1- Create authorization list, example

CRTAUTL AUTL(JOBSC) TEXT('job scheduler job')

When you do this the *PUBLIC authority will get the authority that you have selected, I have selected *CHANGE

Your ID will be added to this authorization list as you are the owner.


2- Add the objects that you want to secure using this AUTL.

The objects that you want to secure needs to be added to this AUTL. This can be done by EDTAUTL command. Here I want to secure CRTAUTL command access. So, I did the following

You can check the objects by taking F15 after entering the AUTL list.

3- Add other users that you want to secure via this authorization list.

ADDAUTLE command would do this

You can check the users added to this AUTL by taking option 5 next to the AUTL.

You can delete the authorization list by DLTAUTL command.

Now lets explore more on User profile security and audit

There are many common scenario's that needs to be taken care of while auditing and ensuring security of the system. Now, lets explore some of the basic one's.

1- Finding user profile's with default password :- While auditing IBM i, the common thing that the auditor would like to check is the list of user profile's that have default password. 

What is default password? When the user profile name and password are same, it is called default password. As you already know, the system defaults to *USRPRF while creating a new user profile and if unless changed would generate the user profile with same password as the user id, it is called default password.

As a responsible administrator, it is required to check periodically if any user profile has default password and the same report needs to be provided while auditing. So, how to generate a report with user profile's that have default password .

AS400 command ANZDFTPWD would do that.

Command is

ANZDFTPWD ACTION(*NONE)

This would generate a spool file QPSECPWD for the user. You can use iSeries navigator to download this report. 

If you want to disable the user profiles with default password , use the following

ANZDFTPWD ACTION(*DISABLE)

You can also expire the password of all the user profiles having default password, 

ANZDFTPWD ACTION(*PWDEXP)

ANZDFTPWD is that it produces a physical file containing all the information from its QPSECPWD listing. Whenever you run ANZDFTPWD, a complete list of all user profiles with default passwords is copied in the QASECPWD file in the QUSRSYS library. This file can be read in other programs or in an SQL query to gather more information.

2-  Password Configuration details :- Sometimes it would be required to check and provide the password configuration parameters for auditing. You can easily achieve this by iSeries Navigator.

Expand the system name under Management Central. Expand the security tab. Click on Password policy.

You can copy these details in General tab, validation tab and Expiration tab and provide it to auditors.

3- Querying User Profile to extract specific details :-  As a system administrator, it would be required to periodically check for users who no longer use the system for more than 6 months. Sometimes, to provide a list of users having a specific special authority. 

In order to do this, first create a physical file of the user profile in your system.  This can be done by

DSPUSRPRF USRPRF(*ALL) TYPE(*BASIC) OUTPUT(*OUTFILE) 

OUTFILE(LIBRARY NAME/FILE NAME) 

Now, this file is the physical file upon which you can query according to the requirement and provide the desired output. 

For generating report of all admin user profile,

SELECT  UPUPRF,  UPUSCL,  UPSPAU,  UPGRPF,  UPTEXT,  UPSTAT,  UPPSOD  FROM LIBNAME.FILENAME DSPUSRPRF  WHERE UPUSCL = '*SECADM' OR UPUSCL = '*SECOFR' OR UPUSCL = '*SYSOPR'   ORDER BY  2 

For user profile that have not used for last 6 months,

SELECT  UPUPRF,  UPGRPF,  UPTEXT,  UPSTAT,  UPPSOD,  UPPWCD,  UPPWEX,  UPLTCP,  UPSPAU,  UPOTQU  FROM LIBNAME.FILENAME SOXUSRPRF  WHERE UPPSOD < 'MMDDYYYY' AND UPSTAT <> '*ENABLED'   ORDER BY  2 

Run this statement to get all user profiles with a user class equal to *SECOFR or *PGMR.

SELECT * FROM LIBNAME.FILENAME WHERE UPUSCL = '*SECOFR' OR UPUSCL = '*PGMR'

To retrieve all user profile records that contain *ALLOBJ or *SECADM authority 
in their profiles, run this SQL statement.
SELECT * FROM LIB/FILENAME WHERE              
UPSPAU LIKE '%ALLOBJ%' OR UPSPAU LIKE '%SECADM%'





To capture all the user records that have command line authority on the system, 
run this SQL statement.
SELECT * FROM LIB/FILENAME WHERE UPLTCP = '*NO'



The hardest part is to determine the field name in this spool file. For that you can use


DSPFFD FILE(LIB/FILENAME) OUTPUT(*PRINT)



Since, these files could be way too big, it is better to use Help systems's  Showcase query as this enables the admin to generate the query output in excel sheet.  Showcase uses normal SQL to query the files.


3- Authority for running commands :-  The Auditors would also like to see the authority to run specific commands, for example SBMJOB, CHGJOB and ADDJOBSCDE command allows the user to make changes to jobs and change the job scheduler. To retrieve the authority information to run these commands, use the following.


DSPOBJAUTH OBJ(lib name/obj name) Objtype(*CMD)


I will discuss the rest security and auditing related parameters in my next post.


Thank you.

Lets get started with User profile in AS400 - Create AS400 User profile(CRTUSRPRF)

Since, we need to have a user profile to get access to AS400, lets now discuss AS400 user profile and all its feature.

Create AS400 User profile :-

The administrator with *SECADM, *CHANGE and *USE  authority has rights to create a new AS400 user profile.

User profiles can be created through two interfaces. You can use the green-screen Create User Profile command (CRTUSRPRF) or you can use iSeries Operations Navigator's (OpsNav) user profile function. For this, I'll use the traditional CRTUSRPRF interface but all of these options are also configurable through the OpsNav interface.

This is how the screen would look when you type in the command CRTUSRPRF and press prompt,

Parameters that are essential :-

1- User profile name :- Provide user profile name this takes up 10 character long user name.

2- User Password :- This is by default set to same as the user profile and can be set to a different one.

3- Set Password to Expire :- This enables Admin to compel the user to change the password after first log in when set to *YES.

4- User Class :- The user class you choose will determine whether the user has normal system authorities or whether they can perform additional tasks normally reserved for higher-level users. Your choices for user class are the following:

• User (*USER) - An ordinary user with no special system authorities.
• System Operator (*SYSOPR) - The user has the ability to perform system backups (*SAVSYS authority) and control system jobs (*JOBCTL authority).
• Programmer - The user has no special system authorities beyond that of a normal user.
• Security Administrator (*SECADM) - The user can create, change, or delete other user profiles.
• Security (*SECOFR) - The user possesses all system authorities, and he can perform any task on the system. But beware. Many shops are too loose with *SECOFR authority. In general, it should be reserved for one or two trusted people in the IT department and that's it. 

5- Intial Program to Call, Intial Menu - Both of these parameters determine which program will be called when the user log in. By providing different INLPGM & INLMNU options users could be restricted to enter the Main menu.

6- Limit Capability :- LMTCPB parameter tells the OS400 two things. First, it tells the OS400, if the user can make changes to ITLPGM, ITLMNU and current library values. Secondly, it says the OS400 if the user has access to command line.

When it is set to *NO, the user can make changes to ITLPGM, ITLMNU , current library and ATTN key values and also it can use the command line to run AS400 commands.

When it is set to *PARTIAL, the USER cannot make any changes to ITLPGM, ITLMNU, current library and ATTN key value but it has access to command line and can run AS400 commands.

When it is set to *YES, the user has neither access to make any changes to ITLPGM, ITLMNU and current library nor it can access command line.

These three parameters ITLPGM, ITLMNU and LMTCPB have ability to restrict users. For example, for the server users who do not require to access the green screen 5250 emulator, can have ITLPGM as *NONE, ITLMNU as *SIGNOFF and LMTCPB as *YES. They can still access AS400 from other server which are connected to AS400. However, if the same user tries to access the AS400 from 5250 emulator, it will immediately bring the user to signoff screen thus restricting access to AS400 and command line.

7- Special Authorities :- SPCAUT - Special authorities work hand-in-hand with the profile's user class. User profiles with a user class of System Operator (*SYSOPR) are automatically assigned the special authority to save and restore system objects and to control system jobs. Users who are designated as Security Officers (*SECOFR) can perform any and all restricted functions on the system. For all other users, you can assign one or more of the following special authorities to a user profile: 

• All object (*ALLOBJ) authority allows the user to access any system resource, regardless of whether or not they are explicitly authorized to use that object. Because *ALLOBJ basically gives users to update any item on the system, this special authority should be given out only on a need-to-have basis.
• Audit (*AUDIT) allows the user to perform all auditing functions on the system, including turning on and turning off auditing.
• Job Control (*JOBCTL) allows the user to perform any function (change, hold, delete, release, etc) on any jobs that are currently running on the system or for jobs that are sitting in a system job queue. In addition, the user has the ability to start OS/400 writers and remote output queues, and to stop active subsystems. Like *ALLOBJ, you may want to restrict access to *JOBCTL authority.
• Save system (*SAVSYS) authority allows the user to save, restore, or free storage for all objects on the system, regardless of whether or not the user has object management authority to those objects.
• Input/output (I/O) system configuration authority (*IOSYSCFG) gives the user the ability to change system I/O configurations.
• Security Administrator authority (*SECADM) allows a user to add, change, or delete user profiles on the system. The user must be authorized to the user profile commands (CRTUSRPRF, DLTUSRPRF, and CHGUSRPRF) to use this authority. The catch here is that a security administrator user cannot assign any special authorities to another user that it does not itself already have.
• Spool control authority (*SPLCTL) allows a user to work with printers and writers.

8- Password expiration interval parameter - (PWDEXPITV) tells OS/400 how often (in days) the user should be forced to change their password. If the user has not changed his password by the end of the PWDEXPITV interval, the user profile password will automatically expire.

• Any number between 1-366 days. If password expiration is set for a user, OS/400 will not allow passwords to remain active for more than one year.
• No expiration date (*NOMAX) tells OS/400 that the password will remain active forever unless the user voluntarily changes it or the system administrator changes it.
• Use the Password Expiration Interval system value (*SYSVAL). This setting tells OS/400 to use the value for password expiration days found in the Password expiration interval system value (QPWDEXPITV). This is the default value for the PWDEXPITV parameter. If you decide to use *SYSVAL, check what value QPWDEXPITV is set to, because OS/400 sets the password expiration interval system value to a default value of *NOMAX.