Blog Host: Carol Woodbury - president, SkyView Partners Inc. READ ENTIRE BIO

If you have a set of users and they need the same set of authorities or capabilities (special authorities), then it makes a lot of sense to use a group profile. You simply specify the group profile name in the users' group profile parameter. Now, if you grant a group profile authority to an object (a file or library, for example) or give the group profile a special authority (such as *JOBCTL), then all of the users in the group get those authorities. Groups are often created by department or "role" (such as tellers, accounting clerks, payroll department, etc.).

Authorization lists can be used to simplify the security administration of objects that need the same authorities. Authorization lists are often created by application. For example, you have an accounts payable application and each month a new set of files is created, but the same users need to be granted the same authorities each month as the new files are created. You may want to consider creating an authorization list and securing both the existing and newly created files with the list. Then, you grant the users' authorities to the authorization list, not the files themselves. By virtue of having authority to the authorization list, the users have that authority to anything the authorization list secures.

Now to answer the question "Which is better -- the group profile approach or the authorization list approach?" The answer is: neither. It's not a matter of which is "better." It's a matter of which one makes more sense, given the problem you're trying to solve. In fact, many of my clients will grant a group profile authority to an authorization list, giving authority to every member of the group to all of the objects secured by the authorization list.

The moral to today's blog is this: Use the method that makes the most sense for the configuration you've got and the problem you're trying to solve. And don't be afraid to use them both!

What I'm thankful for
Today I'm stopping to enjoy and be thankful for my home. I'm not there all that often so I really enjoy it when I am!
Posted by Carol Woodbury Using IFS commands to manage i5/OS objects
03 MAY 2006 11:54 EDT (15:54, GMT)
The Integrated File System (IFS) may be a confusing part of the system to many of you, but just because it presents some interesting challenges doesn't mean that you shouldn't take advantage of some of its features. You can use the IFS commands even when working on i5/OS or OS/400 objects -- you just have to specify those objects using a pathname rather than using the traditional library/object *object_type structure. If you take a look at the CHGOWN figure below, you'll see that the objects in the PAYROLL library are named using a pathname.

To name an i5/OS object using a pathname, do the following:

• Specify the file system you're working in -- in this case, it's "/qsys.lib/."

• Name the library -- in this case, it's PAYROLL and you'll have to add the object type -- so it's payroll.lib.

• Stop there if you're working with the library, but to name the objects in the library, specify the name of the object or use a generic and add the object type at the end. In this case I want to change the owner of all of the objects in the PAYROLL library so I'm going to specify the objects using *.* to get all objects of all types.

Using this pathname, you can run the CHGOWN command to change the owner of all of the objects in the PAYROLL library.

What I'm thankful for
Today I pause to give thanks for my neighbors -- they take care of my house when I'm traveling, help me start my lawn mower in the spring and their teenagers provide endless times of laughter. They are the ones responsible for getting me hooked on various reality shows such as Survivor and The Amazing Race. I'm not sure I should be thankful for that fact or not, but without them, my life would be pretty dull. Thank you neighbors for everything you do for me!
Posted by Carol Woodbury A case of poor wording
02 MAY 2006 21:27 EDT (01:27, GMT)
I have to attribute this blog entry to the confusion caused by two program attributes being named very poorly. The attributes providing the confusion are the "User profile" and "Use adopted authority" parameters. See this DSPPGM figure:

Because of the way that it's worded, most people think that it is the Use adopted authority parameter that determines whether a program adopts. That's not actually the case. When set to *OWNER, it is the User profile parameter that causes the program to adopt its owner's authority. (By the way, the default for this parameter is*USER, which means that the program does not adopt authority.)

The Use adopted authority parameter determines whether the program will use the adopted authority being passed to it from a program that is higher in the call-stack. Adopted authority is call-stack based. When a program is called and it adopts authority, as long as the program remains in the call-stack, the adopted authority will be in effect. So if Pgm_A adopts authority and calls Pgm_B and Pgm_B calls Pgm_C, Pgm_C, will be able to use the adopted authority from Pgm_A. The default for this parameter is *YES which means that by default, programs always use the adopted authority available to it.

When would you ever want to specify Use adopted authority set to *NO? When you are calling a program, such as one that puts up a command line and you don't want the user to have the additional authority. Using the example above, if Pgm_C called Pgm_D and Pgm_D was configured as Use adopted authority *NO, none of the adopted authority from the previous programs would be available and the only authority in effect would be the user's. If Pgm_D adopted authority (User profile parameter set to *OWNER) then the authority in effect would be the user's as well as Pgm_D's owner.

Another misconception with adopted authority is with level 40. I've seen cases where shops haven't gone to security level 40 because they think that adopted authority will no longer work. This is simply not the case. If adopted authority didn't work at security level 40 or 50, then neither would the operating system because a significant amount of OS/400 and i5/OS programs adopt authority!

What I'm thankful for
Today I'm enjoying springtime. OK, I'd enjoy it a little more without the pollen flying through the air! But what beautiful colors are produced -- pinks, yellows, every shade of green -- wow! If you haven't enjoyed any part of this spring, then you're working too hard! Get out of your office and take a walk at lunch -- undoubtedly there's some beauty that you've been missing. Go -- enjoy!
Posted by Carol Woodbury Where, oh where, do these values come from?
01 MAY 2006 00:35 EDT (04:35, GMT)
A couple different values can show up on the Display and Edit Object Authority (DSPOBJTAUT and EDTOBJAUT) commands. If you are signed on as a user with a group profile and that group profile has been given a private authority to an object, you will see the value "*GROUP" in the User column of Display or Edit Object Authority. The group's name is listed in the Group column. That is not meant to imply that other profiles listed are not group profiles. They might be, but if *GROUP is not shown, the profile is not one of your groups.

The other special value that can be displayed is *ADOPTED. If a program that adopts is in the call stack and you run the Display or Edit Object Authority command, *ADOPTED indicates the authority you have to the object through adopted authority. See the EDTOBJAUT figure for an example of both *GROUP and *ADOPTED values.

What I'm thankful for
Today I pause to be thankful for my nieces and nephews. Having never been able to have children of my own, I have taken great joy in seeing my nieces and nephews grow into young adults. Two of them have even given me great-nieces and a great-nephew. What fun to spoil them rotten and then hand them back to their parents! Each niece or nephew is very special to me in their own way and I'm very proud of each of them. Today I pause to give thanks for the best nieces and nephews an aunt could ever have.
Posted by Carol Woodbury I'm a user class -- and I'm SO misunderstood!
29 APR 2006 00:54 EDT (04:54, GMT)
Most people seem to think that the user class is checked during the OS/400 and i5/OS security checking algorithm. It's not. If you don't believe me, look back a couple of days where the algorithm was explained in detail. Because of this misconception administrators will look to see if a user is in a particular user class -- such as security officer (*SECOFR) and assume that they have the special authorities associated with that user class. The fact is that a user can be in one user class -- say the *SECOFR user class -- and have no special authorities. (Normally if a user is in the *SECOFR user class they have all special authorities.) When examining a user's capabilities, you need to look at the special authorities they have been assigned -- not the user class the user is in.

If you do alter the user's special authorities so that they don't match the "normal" special authority assignments the message, CPI2224 -- user class and special authorities do not match system supplied values -- is issued. It really doesn't matter whether the special authorities assigned to the user match the default values for that user class or not, so just ignore this message.

What I'm thankful for
Today I'd like to give thanks for red wine and dark chocolate -- 'nuf said!
Posted by Carol Woodbury i5/OS and OS/400 authority checking
27 APR 2006 19:28 EDT (23:28, GMT)
One of the things that will aid you in knowing how to set the appropriate access controls on a file is to first understand how i5/OS checks authority. Please refer to the Authority Search Order figure:

Now let's consider an example where John is trying to open a database file for update. That means that to open the file successfully, John needs to have *CHANGE authority to the file -- from somewhere. Here are the steps that OS/400 and i5/OS go through to see if John has sufficient authority:

• If John has *ALLOBJ special authority, then processing stops and he can do the file update.

• If John does not have *ALLOBJ, the system looks to see if John has a private authority to the file.
  • If John has a private authority of *CHANGE or greater, the processing stops and he can do the file update.

  • If John has *USE authority, that is not sufficient. Processing stops, but John is prevented from updating the file.

  • If no private authorities are found, processing continues.

• If no authority is found so far, the system looks to see if the file is secured with an authorization list.
  • If it is and John has *CHANGE authority or greater to the authorization list, the processing stops and he can update the file.

  • If John has *USE authority to the authorization list, that is not sufficient. Processing stops, but John is prevented from updating the file.

  • If no private authorities to the authorization list are found or the object is not secured by an authorization list, processing continues.

• If no authority is found so far and John is a member of a group profile and his group profile has *ALLOBJ processing stops and John can update the file.

• If John's group does not have *ALLOBJ, the system looks to see if the object has a primary group. If it does, it looks to see if John's group is the primary group for the object.
  • If John's group has primary group authority of *CHANGE or greater, the processing stops and he can update the file.

  • If John's group has primary group authority of *USE, that is not sufficient. Processing stops, but John is prevented from updating the file.

  • If no primary group authority is found or John's group is not the group that has the primary group authority, processing continues.

• If John's group does not have primary group authority, the system looks to see if John's group has a private authority to the file.
  • If John's group has a private authority of *CHANGE or greater, the processing stops and he can do the file update.

  • If John's group has *USE authority, that is not sufficient. Processing stops, but John is prevented from updating the file.

  • If no private authorities are found, processing continues.

• If no authority is found so far, the system looks to see if the file is secured with an authorization list.
  • If it is and John's group has *CHANGE authority or greater to the authorization list, the processing stops and he can do the file update.

  • If John's group has *USE authority to the authorization list, that is not sufficient. Processing stops, but John is prevented from updating the file.

  • If no private authorities to the authorization list are found or the object is not secured by an authorization list, processing continues.

• If no other authority is found, the object's *PUBLIC authority is used.
  • If *PUBLIC authority is *CHANGE or greater, the processing stops and John can do the file update.

  • If *PUBLIC authority has *USE authority, that is not sufficient. Processing stops, but John is prevented from updating the file.

• If *PUBLIC authority is *AUTL, the system looks at the authorization list securing the object.
  • If *PUBLIC authority for the authorization list is *CHANGE or greater, the processing stops and John can do the file update.

  • If *PUBLIC authority for the authorization list is *USE, that is not sufficient. Processing stops, but John is prevented from updating the file.

My recommendation is to turn auditing on for the following (in other words, set QAUDLVL to):

• *AUTFAIL
• *CREATE
• *DELETE
• *SAVRST
• *SECURITY (or *SECCFG and *SECRUN in V5R3 and later)
• *SERVICE

i5/OS has a model outfile in QSYS for each audit journal entry type. The naming convention is QASYxxJy where:

• xx = the two-letter audit journal entry type
• y = the file format

CRTDUPOBJ OBJ(QASYAFJ5) FROMLIB(QSYS) OBJTYPE(*FILE)  TOLIB(QTEMP) 

DSPJRN JRN(QSYS/QAUDJRN) RCVRNG(*CURCHAIN) 
FROMTIME('04/18/2006' '08:00:00') JRNCDE((T)) ENTTYP(AF)
 OUTPUT(*OUTFILE) OUTFILFMT(*TYPE5) + OUTFILE(QTEMP/QASYAFJ5)

Good news: In V5R4 a new command, Copy Audit Journal Entry (CPYAUDJRNE), is available that performs the CRTDUPOBJ under the covers and provides a simplified DSPJRN user interface.

For more information about the i5/OS auditing features, check out Chapter 9 in the iSeries Security Reference manual for a more thorough explanation of the built-in auditing features. Also take a look at Appendix E and F for details on audit journal entry layouts and the actions that cause the use or change of an object to be audited.

What I'm thankful for
Today I give thanks for my brother and sister. Since my parents died when I was young, they are the ones that got me through my teen years. Can you imagine having a teenager living with you when you were first married? Yet that's what they did. My brother and late sister-in-law along with my sister and brother-in-law should get medals for patience as they saw me through my teenage years. Without their love, prayers and support, I wouldn't be where I am today. They've laughed with me, cried with me and loved me unconditionally. Yes, today I am thankful for my brother and sister. What are you thankful for?
Posted by Carol Woodbury Why does everyone keep droning on and on about security policies?
25 APR 2006 17:05 EDT (21:05, GMT)
I would be remiss if I started my blog without a discussion about security policies. You see, a security policy is an indication that the business understands that security is a business function. It understands that electronic data is a vital business asset and that it needs to be secured and handled appropriately. Without a security policy, security administrators can only guess at the access controls that should be placed on database files and hope they meet the organization's requirements. If your organization doesn't have a formal security policy, I encourage you to approach your management with the issue.

Hint for the day: Two security-related system values, QSECURITY and QPWDLVL, require an IPL to take affect. But when you look at the system value, it reflects the "pending" value, which is not necessary the "current" value. To see both, use the Display Security Attribute (DSPSECA) command.

What I'm thankful for
Today I pause to be thankful for my business partner. My job and career wouldn't be the same without him. Our skills compliment one another -- he runs the business side of our business, and I run the technical side. We respect each others' skills, learn from each other, but don't tread in each others' turf. But he's more than a business partner, he's a great friend. He's also a great cook and so is his wife (an invitation to dinner is NOT to be turned down!). Today, I'm thankful for my business partner.
Posted by Carol Woodbury Secure...or not?
24 APR 2006 05:04 EDT (09:04, GMT)
"Would the person with the secure AS/400 or iSeries (or whatever the current name of the system is) please stand up?" Wait a minute! Some of you may want to check your system's security configuration before you jump up so quickly. Had I said "secure-able" then, yes, all of you should be standing. But it's my experience that many of the iSeries systems out there have not been configured to be secure. IBM marketers have, for years, done the iSeries user community a huge disservice by incorrectly characterizing the system as the "most secure" on the market, implying that, by default, the system is in a secure state. While I was still at IBM, we were constantly trying to fight and correct these marketing messages. You see, the iSeries really and truly is one of -- if not the most -- "secure-able" systems available today. But, as it is shipped from IBM, it is not in a secure state. (It does ship in a state that provides operating system integrity, which is more than I can say for any other operating system available.)

Unfortunately, because of that misleading marketing message, many in IT incorrectly assume that the data on their systems is secure -- without additional action on their parts. However, if you want secure data, you must use the plethora of security features that come integrated into OS/400 and i5/OS. Using those features provides rock-solid security. Once you've used these features, you can rise to your feet, bursting with pride, the next time I ask, "Would the person with the secure iSeries please stand up?"

Over the next few days I hope to provide you with some hints and tips for making use of those security features, so that you, too, can boast that your data is secured with rock-solid security. And, along the way, I hope to dispel a few additional myths about i5/OS security.

What I'm thankful for
Now, because this is my blog and I can write pretty much anything that I want to, :-), I'm going to challenge all of you to find the good in something or think of something that you're thankful for. Sometimes I get so caught up in day-to-day living that I forget that I am blessed. So I'm going to be pausing for a few minutes in each blog and share with you what I'm thankful for.

Today I'm pausing to be thankful for my career. I had many good years at IBM -- I learned and gained incredible experience and made tremendous friends during those years. I am thankful that I left IBM appreciating my management and enjoying my job. Now I am thankful for my current position -- co-owning my business, SkyView Partners. I have a job that I love. It's allowed me to build on my experience in working with various customers throughout my IBM years and in a field that I truly enjoy -- information security. I'm able to meet new people, make new friends and see many parts of the world because of my business. Many people don't even have a job or else have a job that they don't enjoy. While it's not always perfect, I wouldn't trade my current position for anything. Today, I'm thankful for my career.
Posted by Carol Woodbury