I may be the security officer, but you are the judge. Hopefully, you'll find me worthy of the position to which I've been appointed. So here we go. This month, I'll respond to readers' security questions.
*ALLOBJ Authority
Q: Because of the requirements of the application my company is running, I'm forced to give everyone in the HR department *ALLOBJ special authority. I didn't think this would be too much of a problem since, for the rest of the files on the system that I didn't want them to access, I could just grant private authority *EXCLUDE to the HRGroup group profile. However, I have found out that the HRGroup can still access every file on the system. What's going on?
A: This requires a basic understanding of how OS/400 checks authority. The first thing that OS/400 checks is to see if the user has *ALLOBJ special authority. If he does, the user gets access to the file. No further authorities are checked. That's why it's so dangerous to assign users *ALLOBJ. They cannot be prevented from accessing objects. You may have excluded the user's group from a file, but OS/400 will never look that far.
Private Authority *EXCLUDE
Q: I have re-architected our authority scheme to use group profiles, creating a group profile for the users of each application on our system. I thought they were supposed to be a great management tool. I granted each group private authority *USE to each of their respective application files. However, none of the users can access their files, and I've had to give them *ALLOBJ so they can get their work done. Help!
A: Do a Display Object Authority (DSPOBJAUT) or Edit Object Authority (EDTOBJAUT) on one of the files that a user can't access. Does the user happen to have a private authority of *EXCLUDE? You said you re-architected your security scheme. But perhaps you didn't clean up your system from the old scheme. I'm guessing that the users on your system were granted a private authority of *EXCLUDE to these files and that private authority was never cleaned up. Here's another OS/400 authority checking lesson...
As explained in the first question, OS/400 first checks to see if the user has *ALLOBJ. If she doesn't, OS/400 goes on to check to see if the user has a private authority. If that private authority is not sufficient--for example, the user needs *CHANGE authority to perform the OS/400 function, but she only has *USE--then the user will be prevented from accessing the object. In this case, if the user has *EXCLUDE authority, she will not be able to access the files, regardless of whether her group has authority to the files. OS/400 checks the user's authority after *ALLOBJ. When the user has some authority and it's not sufficient, OS/400 will not check further.
Here's another hint: When displaying the authority to the file, make sure you have signed on with sufficient authority. To see all of an object's authorities, you must have object management (*OBJMGT) authority. If you don't, you only see the authority you have to the object. Figure 1 shows what JOE_USER saw when he signed on and displayed the authority of PGM_B.
Figure 1: Unless you have *OBJMGT authority, you will see only the authority you have to the object.
Once he was given *OBJMGT authority, he saw the screen shown in Figure 2.
Figure 2 : With *OBJMGT authority, you can see all of the object's authorities.
Application-Only Access
Q: Our inventory management application uses application-only access for its security scheme. We recently installed a new version of the application, and now users are getting authority violations when trying to perform certain functions like updating inventory levels. Can you help me figure out why?
A: Application-only access typically means that the public access for all objects--especially files--is set to *EXCLUDE. Then, the programs are configured to adopt their owner's authority. The program owner then either owns the data files or has sufficient authority to the data files to do all application functions.
The first thing I'd do to discover why the application is now failing is to make sure the updated application programs are owned by the correct user profile. Check with your application provider if you are unsure of which profile should own the application. Hint: There may be different profiles that own different parts of the application. For example, one profile may own the programs, while another profile may own the data files. If the programs are already owned by the correct profile, I would check to see if the files are owned by the correct user. (Again, verify with your application provider which profile is supposed to own these files.) If the same profile owns both the programs and the files, the next place to look is to see if the programs are still configured to adopt authority. To check that, do a Display Program (DSPPGM). Look at the User profile parameter (not the Use adopted authority parameter.) The User profile parameter must be set to *OWNER to have the program adopt. If the programs and data files are owned by two different profiles, check the program owner's authority to the data files. Perhaps that profile's authority to these files has been removed.
Vendor-Shipped Authority
Q: We are overhauling our application vendor's security scheme. (It was shipped with all objects set to *PUBLIC(*ALL)! Can you believe that?) Anyway, we want to change to implement a variation of application-only access. (We will probably set public access to *USE rather than *EXCLUDE.) To still allow updating the files through the application, we will have to change them to adopt authority. Is there anything I should watch out for before we start down this road?
A: The first thing to look for is whether the application programs were shipped with observability. If they are not, you cannot change the program. In other words, when you do a Change Program (CHGPGM) command and change the User profile attribute from *USER to *OWNER, OS/400 re-translates the program. If observability has been removed, OS/400 can't re-translate and you can't change this attribute. If this is the case, you are going to have to ask your vendor to work with you to meet your security requirements.
Second, whether the programs are shipped with observability or not, you should contact your vendor. First, they may already have a documented procedure to secure their application (why they don't then just ship the application configured securely is beyond me, but I digress). Next, they may be able to tell you things to watch out for or authority requirements for various parts of the application. Finally, some vendors are real schmucks and will tell you that if you change the attributes or configuration of their application, you will void any agreements, obligations, or contracts. You will have to then make a business choice if you want to go ahead with your planned changes.
*SPLCTL Authority
Q: I have an output queue that was created with AUTCHK(*OWNER), yet one of my operators can still work with its spooled files. I thought only the owner of the spooled files could access these, given the AUTCHK setting. What am I missing?
A: It sounds like the user has Spool control (*SPLCTL) special authority. If she does not have the special authority and she is a member of one or more group profiles, check the group profiles for *SPLCTL special authority. *SPLCTL is like *ALLOBJ special authority, only for spooled files. There is no way to prevent a user with *SPLCTL from accessing spooled files--no matter how the output queue they are in was created. For more information on how to secure your spooled files, see Chapter 6 in iSeries Security Reference (SC41-5302) or Chapter 6 in my book, Implementing AS/400 Security.
Authority Checking with Multiple Groups
Q: How does authority checking work with multiple groups?
A: If OS/400 does not find any authorities at the user level, it goes on to check a user's group profiles' authority to the object. When a user is a member of only one group, the check is just like at the user level. If the group profile has some authority to the object being accessed and it is sufficient for the function being performed, the user gets access to the object. If the user doesn't have sufficient authority, OS/400 stops the authority checking and the user does not get access to the object.
When a user has more than one group profile, the authority the groups have to the object being accessed is accumulated (sounds strange, I know, but hang in there with me). OS/400 accumulates authority until either it finds sufficient authority to access the object or there are no more groups to check. Say a user, Abby, is responsible for adding new employees to the HR database. To do that, she needs *CHANGE to the file. Abby is a member of five group profiles. GRP_1 has *OBJOPR; GRP_2 has *READ and *ADD; and GRP_5 has *UPDATE, *DELETE, and *EXECUTE. Once the authority checking algorithm adds in GRP_5's authority, the user will have sufficient authority (*CHANGE) to access the file. I didn't mention Abby's groups GRP_3 or GRP_4. GRP_3 has no authority to the HR database. GRP_4 actually has *EXCLUDE authority to the database. What's up with that, you ask? How can Abby still get access to the database when this group is excluded from it? Well, OS/400 basically treats this instance as a "no-op" and keeps processing. If GRP_4 were Abby's only group, she would have been excluded from the HR database.
If you're confused, don't worry about it. This is the way it's worked for many years now, and I've never heard of anyone having any difficulties implementing multiple groups and their accumulating authorities.
Backup and Recovery
Q: Severe damage to our building after an earthquake required that we move locations without warning. We didn't even have the opportunity to make a current backup. However, we have a backup strategy in place, so we only lost one day's orders. We went to our backup location and restored our most recent backup. Everything was going well until we realized that all of our objects are owned by QDFTOWN. What went wrong, and how do we fix our objects' ownership?
A: For disaster recovery, you must carefully follow the instructions IBM gives you in the Backup and Recovery manual (SC41-5304), but obviously you don't need those words of advice at this point in time!
I am guessing that your system's recovery was performed in the wrong sequence. First, you must install OS/400, then restore your user profiles, then restore your user objects. It appears that, in this case, user objects were restored before user profiles. If you think that re-restoring all the user objects will fix this problem, it won't. OS/400 "preserves" the ownership of all objects currently on the system. This means that programs that are currently owned by QDFTOWN on your iSeries, but are owned by REAL_USER on media, will remain owned by QDFTOWN even if you restore them again. You will either have to change the ownership of each object individually, remembering which profile was really supposed to own the objects, or, more realistically, start your disaster recovery process all over. As onerous as this sounds, this is probably the solution that will be the most "foolproof."
If you would like to submit a question for possible inclusion in a future Security Patrol, please send it to
Carol Woodbury is co-author of the book Implementing AS/400 Security as well as co-founder of SkyView Partners, a firm specializing in security consulting and services. Carol has over 12 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology.
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