About admin

Founder of Kisco Information Systems

Hiding Places for Malicious Code

By Rich Loeber

The last time I wrote, it was about tracking down hidden programs on your system that you might not know about (see article).  That time, it was trigger programs that could be sitting on your system just waiting for a specific event.  But, as I’ve thought about this issue since then, there are other places where someone could “hide” a call to a malicious program and easily get overlooked.

This time, we’ll look at two other areas for concern.  These are the system job scheduler and exit programs.  Both are ways that someone intent on doing harm to your system could hide some malicious program waiting for something to happen so it can jump out and cause problems.  In each case, the IBM i OS contains a way to review the programs that are sitting there and you should take a look periodically to see how each is being used on your system.

The IBM i OS has had a nice, easy to use job scheduler built into it for a long time now.  Most shops where I’ve done consulting work seem to know about it and use it for regularly scheduled jobs.  But, that also means that the programming staff is aware of it and could misuse or abuse it.

To review the current contents of the system job scheduler, use the i/OS command Work with Job Schedule Entries (WRKJOBSCDE).  This command will display information about every job in the system job scheduler.  It will tell you what the job is, how it is invoked and when it is next scheduled to run.  You should review each entry to make sure that you know what it is doing and when it is next scheduled to run.  A suspicious job, to me, would be one that is not set to run for quite a while in the future.  Most scheduled jobs happen frequently, either on a daily, weekly or monthly basis.  If you see something on a different schedule than one of these, I’d pay particular attention.

Another place you need to periodically review are the registered exit point programs on your system.  Exit points are hooks into i/OS processes.  These are provided in the i/OS so customers can add their own customized processing called from the OS during normal operations.  For example, many of the third party network security products now available on the market (including our own SafeNet/i) use exit points to add security checking to the various network operations in i/OS.  The potential problem is that a rogue program could get registered to an exit point just waiting for a specific OS event to occur before it jumps up and gets noticed.

To review exit programs registered on your system, use the i/OS command Work with Registration Information (WRKREGINF).  This will display a list of the i/OS exit points on your system, and remember that they are different for every level of the OS.  For each exit point, use the option ‘8′ to see if there is a registered exit program for the exit point.  If you find any, make sure that you know what they are there for.  Don’t be surprised to find some exit programs already registered.  If you are using a network security system, you should find many programs registered.  Also, some come registered with i/OS.  For example, you will find that the IBM product Service Director, uses some of the exit points as does the i/OS Mail Server Framework (MSF).  Just make sure that you can identify each program that shows up as a result of your review.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Can You Trust All Those Trigger Programs?

By Rich Loeber

If you’ve seen the movie “Troy”, or if you were paying attention in history when you were in school, you know that the Greeks brought down the city of Troy with the gift of a large wooden horse.  Of course, unbeknownst to the Trojans, the horse was filled with soldiers and as soon as things settled down in Troy, the soldiers broke out of the horse and took the city.

These days of rampant computer viruses, worms and other malicious programs moving their way around the Internet, the concept of the Trojan Horse is alive and well.  But, you say, I’m sitting here working on my completely safe and secure IBM i system running the most secure operating system in town!  These things can’t affect me.

Think again.  A malicious program can still get written and installed on your system, hidden away waiting for the right event to come out and strike.  How, you ask?  As a trigger program.

When I heard about this, I was much like most of you thinking that this just didn’t apply to me.  But then I ran the audit report that IBM is included in IBM i OS.  Boy, was I surprised at the number of trigger programs that are installed on our closed development system.  I thought that the report would come out empty.  Lo and behold, I got an eleven page report with information on more than 110 trigger programs in place that I had no idea were there.  Granted, most of them appear to be parts of the IBM i OS, but I did find some application triggers that I did not know were there.  Fortunately, I found that none of these were malicious, but I had my doubts for a while since one of them was written by a programmer who left our employee under somewhat of a cloud.

The IBM i OS includes a command that lets you keep track of the trigger programs that are installed on your system.  The command lets you run a master list of all trigger programs and then, periodically, just list the trigger programs that are new or have changed.

To get started on understanding the trigger programs on your system, run the following command:

PRTTRGPGM LIB(*ALL) CHGRPTONLY(*NO)

This will produce a baseline report of all the trigger programs on your system.  Review the listing closely and make sure that you know what each of these programs does.  If you see a program that you suspect, track down the source code and make sure you know what it is about.  If it is from a third party software provider, get a statement from the software vendor that describes what the program is doing.  Since trigger programs react to events, they are good candidates for malicious actions just waiting for the right action to happen on your system.  Be prepared that the command may take a long time to run and you might want to consider running it in batch.

Once you have your baseline report, you can then periodically run the same command just changing the CHGRPTONLY parameter to *YES.  This version of the report will list changes and new trigger programs on your system.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Password Levels

By Rich Loeber

Ever since the introduction of IBM i/OS V5R1, a system value for “Password Level” has been available (QPWDLVL).  This value lets you have control over the kinds of passwords you use on your system and how the system treats them.  Using the features provided through this value, you can implement passwords of up to 128 characters in length.

Why would anyone ever want to have a password that long?  I asked myself that very question, but when I started looking into the issue, some things jumped out at me that make perfect sense.  With a long password, you can implement a “pass phrase” rather than a password.  The implementation of the long passwords allows for case sensitive passwords and will accept embedded blanks and every character on the keyboard.  This complexity in your password can easily increase the difficulty for people trying to break into your system.

The system value that controls this is QPWDLVL and it can have the following settings:

“0″ – the default setting which sets up 10 character passwords and is what you are probably used to now if you’ve been working with the IBM i system for some time.

“1″ – uses the same 10 character passwords, but the IBM i/OS NetServer passwords for Windows Network Neighborhood access are not kept on the system.  If your system does not communicate with any Win-X machines using Network Neighborhood, you might want to consider this.

“2″ – allows you to have passwords of up to 128 characters that are comprised of any character on the keyboard, are case sensitive and may contain blanks (but not all blanks).

“3″ – implements the same level “2″ passwords but adds the restriction on Windows Network Neighborhood that level “1″ includes.

If I were implementing a new system, I’d seriously consider adopting level “2″ as a standard right from the get go.  But, most of you out there in IBMiLand have an embedded culture of 10 character passwords with specific rules in place that you have your users well trained for.  The good news is that you can move to a new password level as long as you do a little planning in advance.

Moving from level “0″ to level “1″ is pretty simple and does not require much planning.  This will simply eliminate the storage of another set of encrypted passwords on your system.  Moving from level “0″ or “1″ to a higher level should take some planning before you take the plunge.

One of the nice things is that whenever you create a new profile, the IBM i/OS creates the associated level “2″ and level “3″ passwords just in case you want to move to the higher password level.  So, the codes are already there on your system.  The possible downside is that embedded code and certain client software may not get along with the longer passwords.  Consequently, if you decide to make this change, you really should get a full backup of your current security profiles and passwords using the SAVSECDTA command.  This way, if things go south on you, you can recover back to where you are now quite easily.  You can use the DSPAUTUSR command to check your profiles for users with passwords that will not work at the higher levels.  There is a good, comprehensive discussion on how to move to a higher password level in the IBM i/OS manuals “Planning and setting up system security” or “Security Reference” that you should also take a close look at.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Testing Resource Security

By Rich Loeber

Last month, I talked about the need to test your security setup on a regular periodic basis.  That article focused in on testing user profiles.  Today, I want to take a look at how you can go about testing your resource security setup.

There are two things that you need to test and evaluate on your system.  First, you have to make sure that users have sufficient authority to get all of their work done without a problem.  Once that has been established, you then need to go back and make sure that users don’t have too much authority, thereby compromising the confidentiality issues that prompted you to secure specific resources in the first place.

After publishing my previous tip about testing user profiles, I heard from one reader who offered an excellent suggestion.  In their shop, for user profile testing, they maintain a special user profile for each group on the system that is used just for testing purposes.  If you don’t have this set up on your system, I strongly recommend this approach.  Before testing, you can enable your test profile and then, as soon as your done with your testing, you can disable it again.  This idea applies when testing profiles and when testing resources on your system.

To test a user profile to make sure they have sufficient authority, you will have to log on with that profile or your test profile for the group.  Make sure the right menu comes up and then try exercising various menu options.  Remember, resource security does not get checked until a file is opened, so just displaying menus is not going to get the testing done.  Keep track of the operations that you perform, as some of them may have to be reversed within the application files before you end your session.  Make sure that the person who owns the application knows about your testing so they can be on the lookout for any unusual transactions that come up in their system.  Your testing should verify that the user can add records where they need to create new data and delete records where they should be able to remove data.  If you come up with any security problems, note them, make adjustments to your resource security setup and then repeat the testing until it comes up clean.

If a user has access to batch processes, those will need to be tested as well.  Great care must be taken in this area as some batch processes are not easily undone in a production environment.  You might consider setting up a test environment for these purposes.  When running batch testing, review the system operator message queue and the system history log for security error messages.  These messages will be in the 2200 and 4A00 ranges for CPF, CPI, CPC and CPD errors.

Testing for too much authority is also very important and probably a little more fun in the process.  After all, you have to have a little fun while you’re working and pretending to be a hacker is great.

While you are signed on under the profile being tested, check some of the following items:

  • Can you use menu options to gain access to a menu where you don’t belong?
  • Do you have access to the command line?
  • Are you able to key in and run CL commands?
  • Can you use the CPYF command to create a printout of a data file that you are not authorized for?
  • Are you able to run a query tool on your system to get to files that you are not authorized for?

If you are checking resource security for a specific application, you should also log on with a typical profile that should NOT have access to that application and then repeat the above checks.  You should specifically be looking to make sure that access to critical and confidential files is denied to users who should not have access.  This is particularly important as it applies to query tools since they can, by virtue of adopted program authority, thwart your resource security arrangements.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Testing User Profiles

By Rich Loeber

If you’re reading this, you’re probably either a Security Officer or working in the security group in your IBM i shop.  I’ll bet, however, that you didn’t start your career in the security area, but worked your way into your current position, starting as a programmer or a database administrator or some other related field.  In your earlier positions, I’m sure you learned a lot of principals about testing.  Don’t let this fall by the wayside in your current position.  Security testing is just as important as application testing.

Today, we’ll take a look at testing your user profiles.  In future articles, I’ll also be taking a look at other testing regimens for your security setup.

The best time to test a user profile is when you initially create it.  If, however, you have never tested your user profiles, you may want to tackle a project to get the profiles on your system tested on a periodic basis to make sure that they conform to your security objectives.  This article will assume that you have your user profiles organized into groups with group profiles active.

As with all testing, the objective is to check and make sure that the security setup for a user profile (or group) is meeting the objectives you designed.  To do this with a new profile, make sure that you set the password to a temporary code and that the PWDEXP parameter for the profile is set to *YES.  Using this method, the system will allow a single signon with the temporary password and then prompt you during signon to change your password immediately.  When you signon to test the profile, you can then change the password to the user’s final password or to another temporary code.  If you do assign a new temporary code, you’ll have to set the PWDEXP back to *YES when you’re all done.

The first thing to check on any new profile is to make sure that the signon completes successfully.  If it fails, look in the special QEZJOBLOG output queue for a joblog for the failed logon session.  It is amazing what a joblog can tell you about failures on your system and a close examination of the joblog starting from the top should reveal any problems that have happened to cause the logon process to fail.  Typical problems you will encounter include missing or misspelled library names, incorrect initial menu names and incorrect initial program references.

Once you’ve signed on correctly, then you should exercise the profile to make sure that it meets your objectives.  Ask yourself the following questions as you work with the new profile:

  • Is the right menu displayed?
  • Does the user have access to the command line?  If yes, should they?
  • If an initial program was called for, did it execute correctly?
  • What happens when you press the Attention key function?  Is it what you want the user to see?
  • Where is printed output going for the session?  Is this where you wanted it to go?
  • What happens when you attempt to run the application or applications that this user should be using?
  • Are there any system tasks that the user should be able to run?  Can they?
  • Are there specific functions that the user should be barred from?  Can you access them?
  • Can the user access their printed output spool file?  Do they have access to view other user’s spool files?  Should they?
  • Check the user’s desktop environment for remote access tools.  Using the user profile, can the user access data on your system that they are not authorized for?

Make notes for yourself on any issues uncovered, then go back and make any changes that need to be done to bring the profile or group into compliance with your security objectives.  If you detect any problems, be sure to repeat the test until everything is OK.  At that point, you can turn the profile over to the user.

If you have never tested or audited your current profiles, you can use this same method but you will have to warn the users that you are doing a review.  You can use the PWDEXP parameter on the user profile to help with this testing.  Change the user’s password to a temporary code for your testing logon.  Once you’ve completed your test, change the PWDEXP parameter to *YES and set a temporary code that you’ve already told your user about.  Then, the next time they log on to your system, the IBM i OS will ask them for a new password and they’re back in business with little interruption to their daily job tasks.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Controlling Adopted Authority

By Rich Loeber

IBM i programs have a setting when compiled that controls the user profile that will be used for security reasons when that program runs.  You may think that your security configuration is all set and that you’ve made a final determination as to which users are allowed to have access to what objects on your system.  But, if a program on your system is compiled with the USRPRF attribute set to *OWNER, then all your preparation work may be out the window.

The USRPRF parameters for most program compilation commands is set to a default value of *USER on most systems.  This is the way it comes from the factory although it is easy for the default setting to be changed.  When programs are compiled with the *USER setting, then you can count on your object security setup to provide the proper control over access to objects on your system.  When this gets changed, however, then the access controls are based on the owner of the compiled *PGM object and not on the user profile of the person that is running the *PGM object.  (Note: This also applies to *SQLPKG and *SRVPGM objects, but for the purposes of this article, I’m just referring to all of these generically as “programs”.)

This situation is called adopted authority.  There are lots of good reasons why you would want to do this.  For example, you may have a CL program that creates backups of your system that is run by your night operator.  You may not want your night operator’s user profile to have all object authority, so you compile the CL program under a user profile that does have all object authority with the USRPRF parameter set to *OWNER.  Then, when the night operator runs the backup, it goes off without a hitch.  While the backup is running, it has access to the objects needed to complete the backup but the night operator profile is still restricted.  A lot of third party software developers use this technique to make sure that their programs can run without authority problems.

To make sure that your security is not being compromised by adopted authority issues, you should do a periodic review of programs that use this technique.

The first step is to identify the user profiles in your system that have all object authority.  This step alone might produce some interesting results that will surprise you.  One quick way you can do this is by running the following command:

DSPUSRPRF USRPRF(*ALL) OUTPUT(*OUTFILE) OUTFILE(QTEMP/USRPRF)

This will create a temporary physical file named USRPRF in your QTEMP library.  Once created, you can scan this file for the value *ALLOBJ in the first 7 positions of the field designated as UPSPAU.  Any query tool that you like should give you a quick report on what you’re looking for.  Check each profile listed to make sure there are no surprises.

Then, to see if there are any programs that adopt any of the profiles on your list, use the DSPPGMADP command for each profile.  This command supports on-screen display, print and *OUTFILE output.  Use the form that best suits your needs.  At a minimum, you should check for programs that adopt the QSECOFR user profile.  The command to review this looks like:

DSPPGMADP USRPRF(QSECOFR)

Once you have identified programs that run under a user profile that has all object authority, you should then determine if the requirement for adopted authority is absolutely necessary.  In some shops where I’ve worked, I have identified programs adopting the QSECOFR profile because it corrected a problem during testing and was just left that way in production.  One obvious problem would be if the program in question has an option to present the user with an IBM i command line.  In this situation, the user then has full access to your system that goes right around your careful security setup plans.

For third party software, contact your software provider and ask about the adoption situation.  A good software provider should have a ready answer for this question.

When you’ve identified a program that needs to be changed, you don’t need to recompile to make the change.  A simple Change Program command will work in most instances.  Use the following command to change from adopted authority to user authority:

CHGPGM PGM(MYLIB/MYPGM) USRPRF(*USER)

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Checking System Integrity

By Rich Loeber

Much has been made over the years about the robust security features of the IBM i OS.  Those of us who have been working with the system since day one, along with all those who have jumped on the bandwagon since 1988, have experience with the depth of security features that are available to us.  IBM continues to proudly tout the IBM i as a highly secure environment and one that has been very resistant to virus and tampering.

So, it was with some surprise when I found the CHKOBJITG (Check Object Integrity) command on my system.  If the IBM i OS is so secure, what’s the deal with this command?

The stated purpose of the command it to check objects on your system for “integrity violations”.  Thinking that my system should be in pristine condition, I ran a quick analysis.  Running the analysis is simple; it creates an *OUTFILE with the results of the analysis that you can then either view or run a Query report against.  I was surprised to find several items on the report listed under my user profile name.  Looking closer, however, I found that they were listed simply because they had never been converted for RISC use (showing the age of objects on my system).  Whew, I’m off the hook!

The CHKOBJITG command scans your system for the following situations:

  • Commands that have been tampered with
  • Objects with invalid digital signatures
  • Objects with an incorrect domain setting for the object’s type
  • Programs and/or modules that have been tampered with
  • Library attributes that have been tampered with
  • Objects that failed a file system scan

If any of these situations are identified, a record is logged to the output file.  A violation code is posted in the record and you can use the HELP key on the command to get a list of these codes and their meanings.  Keep in mind that if no violations are found, the outfile is not created.  Also, your user profile must have *AUDIT special authority in order to be able to use the command.

Additional items can also be logged to the output file, such as those found on my system.  These additional categories are not integrity violations per se, but can be taken as warnings.  These include:

  • Objects that do not have a digital signature, but could
  • Objects that could not be checked
  • Objects that cannot be run on this system without format changes

Those items on my system fall into this last category.  Objects that cannot be checked would include *PGM objects that are in debug mode, items that were saved with the storage freed option, compressed objects and damaged objects.

The current implementation of the command has the ability to scan objects in any directory or path, which may be helpful for locating problem objects in the IFS.  Earlier implementations only checked the QSYS file structure for problems.

I would love to hear from anyone who has used this command on their system and discovered any surprises.  Years ago, I knew of one IBM i programmer who was able to get user programs to run in system state so that he could “do things” at the system level, but I know he’s retired now.  It would be interesting to me to know if there are objects on user systems that get reported and the stories that lie behind those objects.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Limiting When A User Profile Can Be Used

By Rich Loeber

Each user profile on your system is a window, of sorts, into the computing environment for your business.  Some profiles have a very narrow and limited view while others have a panoramic scene before them.  Some profiles can only look while others are allowed to look, pick things up, move them around, make changes and even throw them away.  Some only have access to a single library while others, perhaps even you, have the keys to the Kingdom.

As a security officer, you’ve probably given this a lot of thought already and you already have your profiles set up with the exact permissions necessary.  Users are allowed enough access to fulfill their job descriptions but not so much that they can wreak havoc for your organization either accidentally or intentionally.  And, to a large extent, your trust of the person behind the profile plays a large roll in how much access you give them to your system.

Problems come up, however, when a profile is compromised and is used by someone other than the assigned person.  When this happens to a profile that has the panoramic view of your system, real trouble can ensue.

The IBM i OS on your IBM i system has a nice little feature that can give you improved control in the event of a compromised profile.  This feature, the Activation Schedule, lets you specifically tell the system what days and what hours in the day that a profile can be used.  If a user profile is compromised, the chances are very good that the incorrect use will be attempted during off hours.  If the profile in question has been posted to the system Activation Schedule, the profile will not be available for use during the off-hours time frame.  This extends not only to terminal session signon but to all server activity, such as FTP, the system file server, etc.

There are two commands that you use to maintain the system Activation Schedule.  The “Change activation schedule entry” command (CHGACTSCDE) is the main command for maintaining the schedule.  This lets you add a user profile to the list or change a profile that is already on the list.  Once a profile is on the list, a message will be sent to the user profile that established the entry each time the profile is activated and deactivated.  When you create the entry, you specify the time of day when you want the profile available for use.  The system will activate the profile at the given time and then automatically deactivate it at the closing time that you enter.  You can specify this time for all days of the week or for given days of the week.

The other command that can help you with this is the “Display activation schedule” command (DSPACTSCD).  This command lets you review how your Activation Schedule is set up.  You can look at it interactively or create a report of the schedule.

When you first set this up, nothing will happen right away, so be prepared for that.  The system will post jobs into the IBM i system job scheduler to do the actual activation and deactivation.  The next time one of the time of day thresholds is passed, the activity to activate and/or deactivate users will start and you will begin to receive status messages from the system.

Using this feature of the IBM i OS, you can close the window of opportunity when a compromised profile can be used and make it more difficult for mischief makers to do their thing on your system.  One thing to keep in mind, if you adopt this process, is that you may need to make special arrangements when your users work a different schedule than normal, such as overtime work.  During these times, you may have to update the Activation Schedule to accommodate different work hours.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Standardize Security Across Multiple Systems

By Rich Loeber

Nothing supports the popularity of the IBM i as much as the number of customers with multiple systems installed.  These can be either multiple partitions on a single box or separate boxes.  For security officers, this can easily mean a lot of extra work keeping each system setup and configured for company security policies.

While this can be a complex task, IBM has provided an little known capability in the IBM i OS for quite a while now that can help you to enforce standard security configuration setup rules across separate systems.  This is through the use of the CFGSYSSEC (Configure System Security) command.  This command, which has no parameters, calls a CL program named QSECCFGS in the QSYS library.  This program sets the security related system values to standard settings recommended by IBM.

The good news for the security officer with multiple systems to control is that this CL program can be changed to meet your unique setup requirements.  The base program as shipped with IBM i can be retrieved and then modified for your unique needs (not unlike the way the system startup program QSTRUPPGM works).

To retrieve the CL program, just run the following command on your system:

RTVCLSRC PGM(QSYS/QSECCFGS) SRCFILE(mylib/QCLSRC)

This will place a source member in your QCLSRC source physical file named QSECCFGS.  To be on the safe side, you should probably rename this and, when you recompile it, place the new compiled program into QUSRSYS.  Once this is done, just change the IBM i CFGSYSSEC command to run the your modified program from QUSRSYS with the following command:

CHGCMD CMD(QSYS/CFGSYSSEC) PGM(QUSRSYS/myseccfgs)

When you review the CL program source that has been retrieved, there is some housekeeping that takes place early in the program.  You can review the settings imposed by the program after the housekeeping to see how IBM recommends your security setup and make changes that will implement standard security settings for your own requirements.

To implement the standard security setup across your multiple system environment, simply install your custom setup program on each system in your network and modify the CFGSYSSEC command on each system to call your modified program in place of the IBM default program.  To guard against possible changes being made to the setup, you can even add this to your automatic schedule to run on a weekly or even daily basis to keep these setting enforced.

The retrieve CL program is a little tough to read, but perseverance will prevail.  If you need help with it, let me know what you need specifically and I’ll see if I can help.  If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Using Authorization Lists

By Rich Loeber

When designing security for your IBM i system, there are lots of things you can do to simplify the task and keep maintenance of security settings to a minimum.  Some of these include implementing group profiles and supplemental group profiles.  Another important one is using Authorization Lists.

An Authorization List is a special system-level object that resides in the QSYS library with object type *AUTL.  Your system can contain multiple Authorization Lists and it is recommended that they be created along application boundaries.  So, one list could be used for Payroll while another list can be used for Inventory, and so on.

An Authorization List simply defines user authority for objects that belong to the list.  When an object is created, rather than creating individual private authorities to the object, just associate it with the appropriate Authorization List.  The List, in turn, will control individual and *PUBLIC authority to all of the objects in the list.

Using an Authorization List will simplify setting up new users and maintaining object authority on your system.  It also has some nice side benefits.  The individual size of user profiles is kept much lower using Authorization Lists.  Also, system performance is improved when running SAVSYS backups and when saving security information on your system with the SAVSECDTA command.  But, one of the most significant advantages is that security changes can be made to a list even when objects in the list are open and active on your system.  This means that you can make security adjustments on your system even when the applications are active and running.  Conversely, when using private object authorities, you can only make security changes when the file is not in use.  This alone can save you loads of headaches and late night sessions on your system.

To get started with an Authorization List, you first need to create the list using the Create Authorization List (CRTAUTL) command.  Be sure to set the *PUBLIC authority level using the AUT parameter.  Once it is created, you can work with it using the Edit Authorization List (EDTAUTL) command.   Using this command, you can add individual users who will need more authority than is allowed by the *PUBLIC authority setting.

Once you have the list configured, it is time to use the list on the objects you want it to control.  You can grant authority via the list using the Grant Object Authority (GRTOBJAUT) command.  Remember that only one authorization list can be used to secure a specific object.  If you are implementing Authorization Lists on a system where private authorities were previously used, you might want to also use the Edit Object Authority (EDTOBJAUT) command so that you can also remove any private authorities that are now taken care of by the Authorization List.   You can also add new users to the list by a simple Add Authorization List Entry (ADDAUTLE) command.  Each individual entry in the list will control the level of authority that user is given to the object.

Remember that a private authority to an object will override the authority provided by the Authorization List.  If you are converting your security setup over to use Authorization Lists, this will be an important consideration.  A private authority will also override a group profile setup, so this is something that will be important to review and check as well.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.