Where Have All the Job Logs Gone?
Question: We are running V2R3. Users with QPGMR authority cannot view job logs from Work with Active Jobs (WRKACTJOB).
Any suggestions?
Answer: There are three possible reasons your users with QPGMR authority cannot view job logs:
• Viewing the spool files of another user requires *JOBCTL special authority. The QPGMR profile should have *JOBCTL authority unless someone has removed that authority. Does your QPGMR user profile have *JOBCTL authority?
• Can your QPGMR user profile view its own job log? If not, the problem may be that the Display Spooled File (DSPSPLF) command is restricted and you need to grant access.
• A user such as QPGMR without security officer authority cannot view the job log of a security officer (who has *ALLOBJ and *SECADM authority). This restriction was implemented on S/38 when the job log included the password on the Create User Profile (CRTUSRPRF) and Change User Profile (CHGUSRPRF) commands. On the AS/400, the password is omitted in the job log, but the restriction on the display of the spool files is retained.
You stated that you were on V2R3. If that is correct, you need to upgrade to V3R2 and apply some PTFs to be Y2K-compliant. IBM has dropped support for V2R3, so upgrading is extremely important.
Token-Ring Security
Question: At our shop, we are on an AS/400 150e box, V4R2, which we feel is secure. However, most of the connections to our AS/400 are made via a 16-MB Token-Ring network. Is all of our AS/400 security for naught if we haven’t placed any extra security on the Token-Ring network? How safe are our user IDs and passwords, which are being sent across this network from Client Access? Is the solution to this problem to purchase a third- party product to ensure the safety of this data, or would you recommend a different approach?
Answer: Security over the Token-Ring is important, but many AS/400 installations with an in-house Token-Ring do not secure the Token-Ring network. If your Token-Ring is installed on-site, your main form of protection is to lock up the wiring cabinets, making it more difficult to scan the network.
You were correct to be concerned about the user IDs and passwords. There are two times when you enter a user ID and password using Client Access. When you first connect to the AS/400, a user ID and password are transmitted, although not in clear text. The second time the user ID and password are transmitted occurs when you sign on to the AS/400. This time, the password is transmitted in clear text and is therefore subject to being discovered if someone is tracing the communication line.
If your Token-Ring is on-site, the cost of installing a third-party product to ensure protection of the data is probably not justified.
Adopted Authority for File Transfer
Question: I am using IBM’s Client Access V3R2 PC5250 and have display and password caching turned off. When I open my display session, it requests a user ID and password to connect to the AS/400. (I log on using profile XXX.) My AS/400 sign-on display now pops up, asking me to provide a user profile and password. (I sign on using my own user profile.) Then, I start an interactive application that adopts the rights of the user profile YYY, granting me access to the data. While in the application on my PC5250 display session, I minimize the session staying in that application.
Because my display session has adopted the access rights to that data, can I now get at the data by some other means, such as file transfer? If so, how can I stop this from happening?
Answer: Applications such as file transfer do not get adopted authority. The adopted access applies only to the interactive AS/400 session. The other sessions will run with the authority of the user profile that was used to connect to the AS/400 (in your case, user profile XXX). Client Access has drop-down menus on the top of the PC5250 session for file transfer, but selecting these will run the file transfer in a separate process, so you will not get adopted authority.
ODBC Access
Question: I have four ODBC-related security questions:
• How do I best protect my system from ODBC programmers?
• Are exit points the only way to restrict ODBC users?
• Do you have samples of exit points that work?
• Would it make more sense for me to have the programmers use FTP instead of ODBC?
Answer: The good thing about the AS/400 is that all access is controlled by AS/400 security, including ODBC access. The user profile used to connect to the AS/400 is the user profile that will determine the access for files using ODBC. You can restrict ODBC access using standard AS/400 security, and exit points are not the only way to limit user access.
A problem frequently faced by AS/400 installations is that users are given access to production files for interactive applications, so users are therefore authorized to run ODBC or file transfers to access files. Some installations solve this problem by writing exit programs to supplement object-level security. Exit points are often used to limit users from accessing the data via ODBC or file transfer. Exit programs are described in the IBM manual AS/400 Client Access Host Servers V4R2 (SC41-5740-01). IBM-provided servers allow you to supplement security using exit programs. Some third-party servers do not support exit programs, and your only control is through object-level security on files.
Writing exit programs can be a complicated task when you attempt to restrict specific files in the exit program. I recommend that you create a library to hold the files allowed for file transfer. The exit program can then reject any file transfer and ODBC requests other than access to the specific library. This approach allows you to determine what files can be transferred simply by determining what library is used for the file.
There is no security reason to use FTP over ODBC. Both FTP and ODBC are able to use exit programs to supplement object-level security, and for complete file transfer operations, FTP is much faster than ODBC.
The Tricky Nature of Adopted Authority
Question: My client has over 500 programs that adopt QSECOFR. What is the real risk behind programs adopting the authority QSECOFR? If programs are run by users with less authority, can they adopt the authority of the object owner (*ALLOBJ special authority), or are they still restricted?
Many programs need QSECOFR authority to run, so what should we recommend to our clients to ensure that excessive access is not granted to other users? Is it OK to allow programs to adopt this authority as long as the programs are fully supported and not “homegrown”?
Answer: Having a large number of programs that adopt QSECOFR is not uncommon in many AS/400 installations. I would prefer that applications not adopt such a powerful profile, but unfortunately, many third-party applications are written with programs that do adopt QSECOFR. When programs adopt any *ALLOBJ user, such as QSECOFR, the programs have access to all objects in the AS/400. Often, these application designers are taking a shortcut in their security design and are relying solely on application security, although it would be better if they allowed AS/400 object authority to control what the user could access.
A user with less authority running a program that adopts a user profile such as QSECOFR has the combined access of both the adopted user profile (*ALLOBJ special authority in the case of adopting QSECOFR) and the signed-on user. Design of programs that adopt is critical; the application must not allow the user to enter commands while running with adopted authority.
Preferably, applications should adopt a user profile that is the owner of production data files and is authorized to the production data but is not a user profile with *ALLOBJ authority. This way, installations can use AS/400 security to restrict access to sensitive data, such as payroll or human resource files. If the applications adopt a user profile with *ALLOBJ authority, such a restriction is not possible.
Using application packages rather than homegrown applications reduces the potential of a “back door” in the software through which sensitive data can be accessed.
X + Y = ?
Question: In an earlier edition of “Security Patrol,” you described adopted authority very well; however, there is one case about which I am uncertain.
Here’s the scenario. Program A uses adopted authority of *OWNER and has an owner of X. This program calls program B, which uses adopted authority of *OWNER and has an owner of Y. It also calls program C, which does not adopt authority. Which owners’ authority will program C adopt?
Answer: When multiple programs that adopt authority are called, the process runs the combined authority of all adopted user profiles and the signed-on user profile. In the case you describe, the process adopts both profile X and profile Y, while programs A and B are on the invocation stack.
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