Q:We are planning to conduct an RPG training class for students. We are concerned about limiting access of our student programmers. How would we go about giving our students authority with access to their own files and programs and yet no access to the programs of other students?
A:Limiting programmer access either in the classroom or on a production system presents a real challenge. Programmers are a difficult group to control because they have system knowledge and command line access. The simplest strategy, library security, involves placing objects in libraries which the programmers do not have access to. While you can limit a student programmer's access to objects with the following recommendations, you can also adapt the strategy to a nonacademic environment.
To use library security, set system value QSECURITY to level 30 or 40. Each student owns a library (S1, S2,...) which contains source file QRPGSRC. (1 illustrates the recommended design.) Owner-ship of the objects allows the programmer to access his data. A *PUBLIC authority of *EXCLUDE prevents access by other students.
To use library security, set system value QSECURITY to level 30 or 40. Each student owns a library (S1, S2,...) which contains source file QRPGSRC. (Figure 1 illustrates the recommended design.) Owner-ship of the objects allows the programmer to access his data. A *PUBLIC authority of *EXCLUDE prevents access by other students.
Each student should have his own user profile. I recommend creating the profiles with a user class of *USER rather than *PGMR. IBM designed the *PGMR user class for system programmers who need to manage other user jobs and possibly back up the system. Consequently, the default special authority for USRCLS(*PGMR) includes the special authorities of *SAVSYS and *JOBCTL. Application programmers and student programmers do not require these special authorities, which represent the following potential security exposures:
o *SAVSYS authority allows the user to save and restore objects even when the user is not authorized to the object. A clever student programmer could abuse *SAVSYS by saving another student's work and restoring the saved data into his own library.
o *JOBCTL authority grants the user access to the jobs of other users in the system. Without *JOBCTL authority, the user can access only his own jobs, and he is unable to power down the system or start and stop subsystems and print writers. By restricting *JOBCTL, you do not need to secure many powerful commands.
The step-by-step procedure I recommend to limit the access of student programmers is:
1. Create a group profile, GRPSTD, to authorize any common objects for the students.
CRTUSRPRF USRPRF(GRPSTD) + PASSWORD(*NONE) USRCLS(*USER) + SPCAUT(*NONE) TEXT('Group + profile for programming class') 2. Create a user profile (S1, S2,...) for each student.
CRTUSRPRF USRPRF(S1) + PWDEXP(*YES) USRCLS(*USER) + CURLIB(S1) GRPPRF(GRPSTD) + OWNER(*USRPRF) GRPAUT(*NONE) + TEXT(student_name)
Set the password to "expired" so that students can assign their own passwords.
Make the student profiles a member of the group profile GRPSTD.
OWNER(*USRPRF) specifies that objects created by the student are owned by the user profile-not the group profile. In industry, objects created by programmers are often owned by the group profile. This allows any programmer to make changes to another programmer's objects when he is unavailable.
GRPAUT(*NONE) indicates no specific authority to any member of the group. These two values (OWNER and GRPAUT) relating to group profiles represent the only differences between implementation in the classroom and in the commercial environment.
Specify the individual student's library as the current library (CURLIB). This causes objects created by the student to be stored in the individual student's library by default.
3. Create a library and source file for each student. The public access should be *EXCLUDE so that access to the library is limited to the individual student. Transfer ownership of the library to the student's profile. Naming the student as the owner gives him access to his library and source file.
CRTLIB LIB(S1) AUT(*EXCLUDE) CHGOBJOWN OBJ(S1) OBJTYPE(*LIB) + NEWOWN(S1) CRTSRCPF FILE(S1/QRPGSRC) + AUT(*EXCLUDE) CHGOBJOWN OBJ(S1/QRPGSRC) + OBJTYPE(*FILE) NEWOWN(S1)
Q: How is the user profile marked after the user incorrectly enters his password? How can I find all profiles that are disabled in the system?
A: When a user's attempts to enter a password exceeds the number of tries allowed by the QMAXSIGN system value, the user profile is marked disabled by the operating system. The user profile parameter STATUS records the status of the user profile as either *ENABLED or *DISABLED.
To find the user profiles that are disabled, use the Display User Profile (DSPUSRPRF) command. It can produce a database file with all of the user profile parameters, including STATUS. The following command stores information for all users in the database file SAMPLE.
DSPUSRPRF USRPRF(*ALL) + TYPE(*BASIC) OUTPUT(*OUTFILE) + OUTFILE(SAMPLE)
The UPSTAT field in the outfile contains the STATUS information. A query can be used to select profiles that have a *DISABLED status.
Q: We are considering using a PC file transfer program on our AS/400. What kinds of security problems do we need to plan for? Where can we get information on PC Support security?
A:You should be aware of one common problem with PC file transfer programs. Users who were once limited by application security can use file transfer to transfer data between the AS/400 and PCs. If you are using level 20 security, you can hide the file transfer operation from the novice user by providing menu options to perform the file transfer. Restricting an experienced PC user on a level 20 system is a challenge.
To protect your data files from experienced PC users, I recommend you implement resource security. Resource security requires security level 30 or higher. For each object, you can determine specific authority or public authority:
o Specific authority describes the authority for individual users.
o Public authority describes the authority for all users who do not have specific authority.
To simplify security management, you may want to place files in restricted access libraries. A user must have *USE access to the library and file to download data. If a user has *CHANGE authority to a file, the user can also upload data from the PC.
You'll find several PC file transfer utilities on the market. Most products depend upon standard AS/400 security to determine which files a user can access. The security of the IBM product PC Support/400 is described in the Installation and Administration Guide (SC41-0006). The PC Support product has other functions such as submission of remote commands and folder access, both of which introduce additional security considerations. Look for an upcoming article in Midrange Computing on this topic.
Q:We are re-enrolling several of our users who had user profiles with an underscore in the user ID. We are creating the profiles without underscores and transferring objects to the new user ID. The new user ID needs to be reinstalled on distribution and authorization lists.
After locating the distribution list information in the QUSRSYS file QAOKP03A, I wrote a query to extract the names from the distribution lists. I have not been able to find a comparable file for the authorization lists. Can you point me to the system file that contains authorization list information?
A:I will first answer your question, but I also want to recommend an alternate method that is simpler than extracting the data from each authorization list. The authorization list information is not stored in a file like the distribution list information.
The Display Authorization List (DSPAUTL) command has an OUTFILE option that will create a file of all users on an authorization list. You need to repeat the DSPAUTL command for all of the authorization lists in the system and store the output in the same file. The collected data can be organized by user profile using Query/400. Although this method solves your problem, I think the following solution is simpler.
The Grant User Authority (GRTUSRAUT) command is a simpler method for transferring the users on an authorization list than writing a query. The users are actually authorized to the authorization list object. (See "Authorization List Internals," MC, November 1993.)
GRTUSRAUT grants authority to a profile by copying the authority of another user profile. If the security officer enters this command, the user specified in the USER parameter is granted the same authority for each object as the user profile being referred to (the REFUSER parameter), including authorization lists.
Ownership of an object or authorities held by the referred-to user cannot be changed by this command. Authorities to objects granted to a user profile are added to any authorities that the target user profile already has.
GRTUSRAUT USER(USRA) + REFUSER(USR_A)
This command grants the user profile USRA the same authorities that USR_A has for all objects, including authorization lists.
Security Patrol: Security Questions & Answers
Figure 1 Student Security Design
UNABLE TO REPRODUCE GRAPHICS
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online