Are Your Backups Complete?

By Rich Loeber

No security plan is complete without addressing the issue of safe and complete backups.  When the AS/400 was first announced, the process was fairly simple and straight forward.  All you needed to do was save all the libraries on your system, save OS/400 in a way it could be reloaded and then make arrangements to backup your security and configuration settings.

As the AS/400 has morphed into the IBM i, things have gotten more complex.  Additional items needed to be saved and new command structures needed to be learned.  With today’s systems, it is not as simple as the original plan, but the tools are all there.  If you haven’t reviewed your backup plan recently, it would be a good idea to dust it off to make sure that everything you need is being saved on your system.

A backup plan generally has two objectives.  First, to be able to recover the entire machine in the event of a catastrophic loss of your processor.  This recovery can be either on your own machine, following repair, or at an off-site location.  The second objective is to be able to recover an individual object in the event of accidental or purposeful object loss.  Your backup plan needs to support both of these objectives.

To get a complete backup of your system today, your backup plan has to provide for the following components of your system:

1. The IBM i operating system
2. Your machine configuration
3. Your systems security settings
4. All native IBM i libraries
5. All shared folder files
6. All files in your Integrated File System (IFS)

The more recent additions to this list are these last two and this is where I want to concentrate efforts for this article.  If you’ve been around the IBM i for a while, you’re probably already quite familiar with items 1 through 4.  If not, feel free to shoot me an Email and I can help you out off-line.

It could be argued that numbers 5 and 6 on this list are both part of the IFS, but the IBM i provides some commands specifically designed for the shared folder system, so you can consider it separately if you want to.

You can save just the Shared Folder files (also known as the QDLS file system in the IFS) using the IBM i command SAVDLO.  To save all files in the Shared Folder system, you can use the following command:


Note, this command will produce an audit report of what was saved which you can print and keep with the backup or just hold in an output queue.  This report tends to be quite lengthy on most systems.  When you run this command, all document library objects on your system will be saved along with all folders and files in the entire Shared Folder system.  The SAVACT(*YES) parameter helps to make sure that the backup is complete by saving objects that may be in use.  If you run your backup in a restricted state, this parameter will not be necessary.

To save the files in your Integrated File System, you will need to use the IBM i SAV command.  This command can actually be used to save your entire system, but its use for native IBM i objects can be confusing so most shops limit its use to the IFS objects.  To save all files in your IFS, use the following command:

OBJ((‘/*’) (‘/QSYS.LIB’ *OMIT) (‘/QDLS’ *OMIT))

Note that the output device naming method is quite different from standard IBM i command formats.  Also, if you are using the plan outlined above, you want to make sure that you don’t save objects again that have already been saved at points 1, 4 and 5.  The OBJ parameter controls this function.  In this SAV command, the OBJ parm contains three elements.  The first element specifies that everything is to be saved.  The next two sub parameters modify this by specifying that the QSYS file system and the QDLS file system be omitted from the backup.  By leaving these out, you will end up saving just the IFS objects you need.

If some of this appears strange to you, then it means you need to dust off your backup plan and bring it up to date.  Today would probably be a good day to do that.

If you have any questions about this topic, you can reach me at rich at  I’ll give it my best shot.  All email messages will be answered.

Security Incident Response

By Rich Loeber,

As the security officer for your IBM i shop, you’ve done all you can to lock down your systems and implement your organization’s security policy.  Once you’re all set up and configured, you think you’re looking good, but there may be a piece of the puzzle that is still missing.  One thing we know for certain with computers is that no system is perfect.  So, there is still the possibility that something will break down in the security design for your shop.  This tip will take a look at what you should do when something goes wrong.

Security incident response consists of several steps and processes that you should document for your organization.  There are all sorts of event types that you may be faced with and each one can have a number of responses or actions that you will need to consider.

A security incident is something that has, at its root cause, the action of a person or group of people.  Incidents can have varying degrees of severity and the first step in a response is to decide how serious the incident is for your organization.  Generally, incidents can fall into three categories:

  • Ordinary or Normal – these do not affect your organization’s operations nor do they require notification of management.  They can be contained and dealt with easily within the security group or help desk function in IT.
  • Elevated or Serious – these can affect operations and will require an implementation in order to deal with them.  Management will have to be notified and may have to be involved in the resolution.
  • Emergency – these can affect people’s health and well being, breach normal business controls on your operations, affect your financial performance or may even place your organization in violation of public law.  Management must be informed and others may also have to be drawn along with vendors, customers and public officials as needed.

Each type of incident will need a tailored response.  Ordinary incidents can be logged and dealt with during the normal course of business.  The logs should be reviewed periodically, but these should not end up taking a lot of time.

On the other hand, serious incidents and emergency incidents need to have a response plan in place.

The first thing you want to do is identify the specifics of the incident and determine if it is still on-going or if it was a one time event.  If it is on-going, your response should first attempt to identify the source and then stop the incident from continuing.  An example of this might be that you discover that someone has breached your system via the FTP server function.  If they are still logged on to your system and taking actions, you should first get as much identifying information as you can as to who is the behind the action, then cut them off by shutting down the FTP server function on your IBM i.  This may affect other users on your system, but the integrity of your system is at risk and you need to take action to protect your organization’s assets.

Once the event has been identified and suspended, you then need to analyze the event to determine how the incident was accomplished and what security safeguards can be put in place to prevent it from happening again.  If at all possible, the affected system should not be placed back into normal use until steps have been taken to prevent a repeat of the incident.

As soon as the severity of the incident has been determined, you will also have to notify management and even your organizations principals.  If the incident includes law violations, such as data theft of identity information, then public officials will also have to be notified.  During this process, it may also be important for you to contact and work with your organization’s public relations staff to make sure that the facts that are made public are correct and not overstated.

Each step along the way must be documented and permanent records kept for future reference.  This will demonstrate how the event was handled and it will provide a clear path towards showing how a repeat of the event will be prevented.

These days, it is not enough just to have a security policy in place, you need to be prepared for what might be needed when the security policy breaks down.

If you have any questions about this topic, you can reach me at rich at  I’ll give it my best shot.  All email messages will be answered.

Tracking Changes to User Profiles

By Rich Loeber

A blog reader recently contacted me and asked how they could track changes to user profiles.  They had an audit requirement to be able to prove that when a user was dismissed, their profile was disabled or removed from the system on their IBM i server.

When I got the call, I was up to my eyeballs in work and did not give them a good response.  I suggested that they code and test exit programs to attach to the system exit points for user profile maintenance.  While that solution might work, eventually, it is like wielding a sledge hammer to crack open an egg.

When I had more time to think about it, the easy solution came to mind.  Use the information in the system security audit journal!

When the security audit journal is active on your system (a topic for a different blog post), then whenever a user profile is created, updated or deleted, records are added to the journal to record the fact.

So, if you want to track the history for a user profile, it is entirely possible to get all of the significant changes to the profile using the audit journal.  There are two specific journal audit records that you will need to consider when reporting on these events.

Audit journals are identified by a Journal Code (a one character alpha code) and by an Entry Type (a two character alpha code).  For our purposes here, we are going to look at journal records for Journal Code T (Audit Trail records) and Entry Type CP (Create, change, restore user profiles).  If you also want to look at profile deletes, you can look at the T-DO records for objects with object type *USRPRF.  The rest of this tip shows you how to work with the T-CP records, but a similar approach can be used for the T-DO records.

To trace user profile history using the T-CP records in the system security audit journals, I simply extracted them to a database file and then ran a report on them, sorting them by user profile and time stamp.

To produce the database file, first create an empty database file on your system using a system provided shell file for the CP journal records.  There are several of these available depending on the level of detail that you want, I used the shell file named QASYCPJ4.  You will find this in the QSYS library.  You can create your shell file using the following command:


This will create the file in your QTEMP library, but you can place it anywhere that is convenient for you.

To populate this database file with the right information from the system audit journal, it is a simple matter of using the Display Journal command (DSPJRN) selecting the right filter information.  The following command should work for most systems:


Some things to note.  Using the *CURCHAIN parameter will pull all information from all journal receivers for the security journal that are currently available.  If you want to limit the extract to a specific period of time, there are additional filter parameters available on the DSPJRN command.  The output file format of *TYPE4 will format the data correctly for the shell file that we are using.  If you want more information, try a different format, but you will also have to use a different shell file.

Lastly, all you need now is to review the database file or list it.  Select the fields that you want to report on; there are a lot to choose from.  I’m old school and I created a query report using WRKQRY.  If you want a copy of it, just let me know and I’ll send it to you.

If you have any questions about this topic, you can reach me at rich at, I’ll give it my best shot.  All email messages will be answered.

Reporting A Break In – My Experience

By Rich Loeber

If you are a regular reader of this IBM i security blog, you’ll know that my company sells and supports an exit point solution for the IBM i called SafeNet/i.  To provide a constant testing environment for this software and to be able to say that it protects your system effectively, we have a test server sitting directly on the Internet and not hiding behind a firewall.

For the year 2013, we issued quarterly reports here about the results we were seeing of hacking attempts into our server.  You can read about that here.   We concluded those reports at the start of 2014, but we continue to monitor results of break in attempts on the server.

Recently, we identified a new phenomenon where a hacker (or hackers) are attempting to break into our system using Telnet.  The pattern is always the same.  Exactly twenty seven attempts are made to open a Telnet session on the server.  The attack lasts for 2-3 minutes and then stops.

Once we identified the attack pattern, we started researching what was going on.  For each attempt, our software captured the source IP address being used.  We then did a reverse lookup to see where it was coming from.  There are a lot of “Who Is” services available on the web and we just picked on that we were familiar with and had used before.  Before diving into a specific service, it is a good idea to test it by checking some IP addresses that you know and see if you get the right results returned to you.

What we found was a bit of a surprise.  I expected these repeating attacks to be coming from a single source because they were all so alike.  What I found was that they were coming from all over the place.  A lot of the IP addresses traced back to RIPE in The Netherlands.  Another significant group traced back to the APNIC in Brisbane, Australia.  Still others traced back to domestic ISPs like Time Warner and Comcast.  Obviously, this was not a single individual.  Since the attacks are being mounted from all over the globe, it is logical to conclude that multiple individuals are using the exact same method for probing possible targets.  The attacks are probably being mounted by software resources repeating 27 identical Telnet logon processes to try and identify a server that responds with access results.

After this kept up for a month, I was concerned that while our system was protecting itself, there might be many others that are not as well protected and maybe someone should know about this activity …. and maybe put a stop to it.  I thought about starting with our local, small town police department, but thought better of it and called the New York State Police.  I gave the desk sergeant who answered the phone a brief description of what was going on, including the fact that our system was successfully defending itself and that the attackers had not even gotten to the point of getting a sign on screen displayed.  He took my name and contact information and then after putting me on hold for a minute, came back and referred me to our local small town police department.  Sigh.

A few minutes later, I got a phone call from the desk sergeant at the local police station.  I gave him a description of what was going on.  He knew a little about Internet fraud schemes, but I got the idea that he decidedly did not really know what I was talking about.  When I told him that our system had not been compromised yet, he said that since no crime had really been committed, there was not much he could do.  If I insisted on making a formal report, he could start an intrusive process that would require me to turn over my server to them for a security audit that could take month.  That is not an option for us.

Not willing to give up just yet, I started to see what other options might be open to me.  I tracked down the FBI Cyber Crime website at  They provide some good descriptive information and reference you to the “Internet Crime Complaint Center”, also known as IC3.  IC3 gives you a place to report your incident in some detail, although it is clearly oriented towards consumer fraud issues.  I went ahead and submitted a report.  The site states that an analyst will review the report and decide what action to take.  As of this writing (about 2 weeks after initial submission), we have received an automatic confirmation that our submission was received, but nothing further.

Since submitting our report, the attacks have kept up on a daily basis.  We are logging a minimum of 5 attacks a day and on some days it has gone as high as 12 attacks.

I promise to continue to report on the process as things happen.

The response that nothing can be done because no crime has been committed does not ring true for me.  If I had called in a complaint about a stranger knocking on the front door of my house over and over again, I’m sure I would have gotten the response that I was looking for, but such was not the case for my cybercrime report.

The lesson you can take away from this is that you absolutely must have exit point controls in place on your IBM i server in order to provide adequate protection.  You must protect yourself from malicious incursions, law enforcement is not going to be able to help much, if at all.

Stay tuned!

If you have any questions about this topic, you can reach me at rich at, I’ll give it my best shot.  All email messages will be answered.

Configuring Telnet for SSL

By Rich Loeber

I was recently asked to secure remote access for 5250 terminal sessions for one of my customers.  I did not have any experience securing Telnet on the IBM i, but I located some good documentation from IBM and was able to get the Telnet connection secured fairly quickly and easily.  This tip will show you how.

Many IBM i shops still use the 5250 terminal interface for administration and operation of their systems.  For them, the interface is well known and comfortable.  The problem is that when used for remote access, the Telnet data stream is passed as open text and it is easy for someone with malicious intent to snoop in on the data stream and capture user profile and password information.

Fortunately, there is a way on the IBM i to encrypt your 5250 terminal sessions by implementing SSL (Secure Sockets Layer) for your Telnet connections.  The IBM i uses a Telnet connection to support your 5250 terminal sessions.

There are two steps that you need to complete in order to set up SSL for Telnet.  Part one involves configuration work on your IBM i server.  Part two is what is needed on your client (your PC) in order to use the SSL connection.

The server configuration will require that you have option #34 (Digital Certificate Manager or DCM) of the base OS installed along with the HTTP server functions.  On our 6.1 test box, the HTTP Server is 5761DG1.  Before plunging into the project, I strongly recommend that you make sure that you have the latest HTTP server PTFs installed.  When we first tried to use DCM after upgrading our OS, it would not work and we needed the PTFs.

To do the configuration work on your host, we found the following article with step by step instructions from IBM and I recommend that you use this procedure:

This process will require you to set up a self-issued digital certificate on your system and then assign it to several applications, including Telnet.  If you have never used the Digital Certificate Manager on your system, be prepared to take some time to get used to it.  The instructions from IBM are actually quite good.

After you get this configuration work done, make sure that you update the Telnet Attributes on your system using the CHGTELNA (Change Telnet Attributes) command.  When starting, make sure that the Allow Secure Socket Layer (ALWSSL) parameter is set to *YES.  This will allow both SSL and non-SSL Telnet connections.  Once you are satisfied with the way the SSL connection is working, you can consider changing this setting to *ONLY which will then refuse non-SSL connection attempts.

Once the server configuration work is done, you can move on to the client configuration work.  Again, I found a good set of instructions from IBM on this that you can access here:

This process may require that you install additional Client Access components on your PC, so access to your Client Access install CD may be required.  The process will call for your to import the certificate you created into your PC and then reconfigure your terminal session to use SSL.  When importing the certificate, there is a standard password to use.  That instruction is easily missed, so watch out for it.

In addition to setting this up for my customer, I also took the long delayed step of setting this up for my own server.  It is something I should have done long ago and I encourage all IBM i shops to adopt this standard for remote access Telnet session.

After initially posting this tip, a friend contacted me to suggest that implementing SSL on Telnet also helps customers with their PCI compliance requirements.  PCI requires 2 factor authentication.  He reported that one of his customers was able to meet this requirement using SSL.  The two factors involved are the password and the digital certificate.  Two factor authentication calls for something you know and something you have.  SSL for Telnet does just that.  (They also require use of VPN for any remote access.)

If you have any questions about this topic, you can reach me at rich at, I’ll give it my best shot.  All email messages will be answered.

Tracking Remote Access Users On Your IBM i

By Rich Loeber

In the IBM i world, it has always been possible to track access to the system by user profile.  It is just a simple matter of activating and configuring the system audit journal and sitting back to wait for some information to be accumulated.  Then, using the DSPJRN judiciously, you can get a list of who signed on to your system and when they did so.

This was all well and good when your normal method of system access was through a green screen terminal, either hard wired or using a terminal emulator like IBM i Access.  But, in this day of network connections through TCP/IP server functions in the OS, the model doesn’t work well.  Users can log into your system using FTP or IBM i Access with little or no trace left in your security journal that they were even there.

In certain cases, an audit journal record for “Process user profile swap” is left (a type PS record in the journal).  I have seen this happen on a logon from IBM i Access using the TCP Signon Server.  Apparently, after a successful logon, IBM i Access does a user profile swap to the QUSER profile and this gets logged in the journal.  So, you could scan the journal for PS records and get some information about which user profiles are establishing network connections using this method.

You can also see some indication about remote users connecting to your system using IBM i Access (and similar clients) from the System History Log.  If you run the DSPLOG command, you can scan for the CPIAD09 message.  You can do this using the following command form:


This will show you some evidence of remote logon activity too.

But these are just a drop in the bucket compared to everything that can go on within your system “under the covers”.  For example, if someone attempts to sign on to your system via FTP using a user profile that doesn’t even exist on your system, you will never even know about it even though you are journaling all security events.  Since this is a popular method that hackers use to try and break into your system, it would be nice to know when such attempts are being made.

When IBM opened up the system to TCP/IP connectivity, their solution to this issue was, and still is, to provide exit points in the OS.  For each of these servers (such as FTP, Telnet, SQL, TCP Signon and many more), the OS lets you create your own program to monitor network activity and even control access to it.

The problem with this approach is that it is entirely passive.  The OS is shipped with no exit program in place and the fact that exit points even exist is still not widely known.  In the mean time, all sorts of nefarious system connection activity can be going on and you, as security officer would never know it.  My company sells an exit point solution for the IBM i called SafeNet/i and the most common comment that we get from new customers who are just starting to use our product is that they had no idea so much activity was going on via network server connections.

Another problem with this approach is that coding and maintaining your own exit point solution is a daunting task.  Over the life of these exit points (they’ve been around for more than a dozen years now), some of the exit point data streams have changed significantly.  To IBM’s credit, they have left the old data stream in place and created a new exit point for the enhanced version, but you have to re-code your application to take advantage of the improvements when they are made.

The best solution is for you to lay out some money and purchase a good exit point solution.  There are a lot to choose from in the System i marketplace today including our SafeNet/i.  The maintenance problem then becomes your software vendor’s headache, not yours.  And, most solutions cover all of the exit points available so that you’re fully protected.  These exit point solutions give you control over which user profiles can access your system, in many cases, what objects they can work with and what source IP addresses they can connect from.  And, all network activity can be logged so that you can finally see everything that is going on “under the covers”.

If you have any questions about this topic, you can reach me at rich at, I’ll give it my best shot.  All email messages will be answered.

Securing Programmers On Your IBM i

By Rich Loeber

When planning out the security policies for your trusted IBM i installation, security officers can often overlook the special requirements that programmers will have.  This tip will try to provide some ideas of how to best deal with this situation.

The programming staff for your IBM i, whether they are in-house staff employees or outside consultants, provide unique challenges to security.  On one hand, they are almost always an expensive resource so the fewer hoops they have to jump over to get their work done, the more efficiently (and cost effectively) they can get their work done.  On the other hand, giving them full access to your system is a huge security risk and one that you would not grant to anyone else in your organization.

Programmers will always take the position that they need full access to your system in order to work effectively.  In some cases, that may even be true; especially in small to medium sized shops where there is only a single programmer or a small programming staff.  When problems arise during the day with normal production, someone needs to be in the position to jump in and address the issue, regardless of the system or systems affected.  In order to be able to do that effectively, full system access may be required.

But, for development projects and for programmers who are working on specific task assignments, full access is never going to be required.  Library and object controls can be kept in place and the assignment of all object authority (*ALLOBJ) should be avoided at all costs.  The fewer user profiles you have with *ALLOBJ authority, the better.  Each user profile with this high level of access authority represents a significant security risk.

So, how do you best deal with your programmers?

One good approach is to segregate your programmers on a separate system so that they can work in an unrestricted environment, but not work with live data.  Many shops that I’ve worked in or worked with have maintained a separate system just for the use of programmers.  In this day of the logical partitioning (LPAR), many organizations just carve out a test partition for their programmers.  New code can be created, compiled and tested in a test environment without exposure to live data.  If you can afford this, it is a great compromise.  You do have to create a strong change control turnover policy so that new programs and data files get the right security configuration when making the transition from test to production, but that should be easy to control.

For your programmers who support daily production, a lot of what they do will not require all object authority.  For those situations where it is an absolute necessity, consider setting up a super user profile that can be activated by your security officer as needed.  Then, when the situation is found where more than normal access rights are called for, your security officer can activate the super user profile for use by the programmer in question.  As soon as the fire is out, the security officer can then deactivate the super user profile and all will be well.

As a last resort, if you can’t pry all object authority away from a user profile, then you should at least be journaling activity for each programmer user profile that has this authority granted.  While this will provide after-the-fact reporting, at least you will have a track record of events.  To set this up, security journaling must be active.  Then you can use the “Change User Auditing” (CHGUSRAUD) command to configure what you want to track for the user profile in question.  For more information on how to set this up, see my previous security tip titled Watching Your Super Users.  Even if you are able to remove all object authority for most of your programming staff, I’d recommend taking this approach for every user profile on your system that has full access to the system.

If you have any questions about this topic, you can reach me at rich @, I’ll give it my best shot.  All email messages will be answered.

Controlling Remote Access to your IBM i

By Rich Loeber

These days, there is almost nowhere you can go on the planet where it is technically difficult to establish and internet connection and get beyond your current location.  We’ve all experienced this, especially with demands made on us during vacation trips and other travel requirements.  It seems like we’re always expected to be on call and available to react to issues back in the office.

While this sounds intrusive of our time, there are other situations where it is a huge benefit.  It allows people who are spread out all over the world to easily collaborate on projects just like they are in adjoining rooms.  It also lets you telecommute from home or even telecommute from a home office that is a long way from your physical office.  This gives you new options in choosing where to live, and it doesn’t always have to be near where you’re working.  It is just this kind of global connectivity that lets me live in a remote location in the Adirondack Mountains of northern New York and still be able to reach out to any potential customers on a worldwide basis.

The thing that makes all this possible is the Internet and remote access technology.  But, as you think about it, while you have access remotely to off site computing resources, so does anyone else who is connected to the Internet.  That is a huge security exposure to your IBM System i.  Even the much touted security on this exceptional system will have exposures.

Certainly, there are loads of infrastructure solutions that you can turn to.  There are no end of VPN (Virtual Private Network) solutions that you can implement that will create tunnels through the Internet to authenticate a connection, limit access and encrypt your data.  There are also firewalls you can implement that will limit traffic connections to your system.

But, these are all external to your IBM i.  What can you do, on your system, to protect yourself.  You need to be able to permit external access from users with legitimate needs but keep all others from doing the same.  There are so many different methods to establish remote access that you have to have a plan for each of them.  From simple FTP to Telnet, ODBC connections, IBM i Access connections, remote command submissions, file uploads and downloads, windows share drive connections and on and on.  The list is long and each one represents an exposure.

IBM has provided a good solution for this issue for more than 15 years now, system exit points.  The OS on your IBM i services each of these remote access requests through something called a Server Function.  FTP works through an FTP Server, Telnet through a Telnet Server, ODBC on most systems works through an SQL Server and so on.  Within the OS, IBM has implemented exit points in each of these server functions.

An exit point is a place in the OS where you can register a user written program to add processing that is not included in the OS.  The exit point passes a data stream that varies depending on the exit point, and your program sets a return code for the exit point in the OS to interpret.  The return code is typically a pass/fail code that lets the exit in the OS know whether or not to continue processing the remote access request.  Your program then examines the information in the data stream to determine if you want to allow or disallow the remote request.

A typical exit point program application might attach, for example, to the FTP server logon exit point and check the remote IP address of the FTP requester.  You can then easily compare this to a list of legitimate addresses that you have set up and then disallow remote access from any IP address that is not on your list.  Continuing with the FTP example, you can also create an exit program application for the FTP server point and then check the data stream to see which objects the FTP session is attempting to access on your system.  Again, you can compare these to a list of objects that the requesting user is trying access and the either accept for deny the request based on what you find.  You can even authenticate the user signed on to make sure that you have authorized them to even use FTP.

A word of caution is due at this point.  Programming for the exit point data stream is not for the faint of heart.  The documentation on certain exit points can be sketchy and testing can be problematic as it can easily interfere with normal operations on your system.  Fortunately, there are quite a few third party solutions available on the market today that are very good.  All that testing and figuring out of the data streams is done for you by programmers who have been wrestling with the issues for years.  I obviously recommend my company’s SafeNet/i as the best of the third party solutions currently available.

To give your IBM i the extra measure of control over remote access via network connections, the best solution is implementation of the exit point controls in the OS.

If you have any questions about this topic, you can reach me at rich at, I’ll give it my best shot.  All email messages will be answered.

Check Your Authorization Lists

By Rich Loeber,

A reader contacted me not too long ago after reading a tip I wrote that urged IBM i shops to implement object level security using Authorization Lists.  This user had been doing just this for years, but was concerned because, “in the heat of the moment”, objects might get created without a thought to making sure that the necessary Authorization List is attached.  I could not give the reader any quick answer, but I started mulling it over.  This tip will give you one way to check to see if all of the objects in a library are secured by your authorization list.

There are two commands in the IBM i operating system that you can use to create database lists of objects for this audit check.  The Display Authorization List Obj (DSPAUTLOBJ) command can be used to create a database list of all objects secured by your Authorization List.  The list will include all objects currently on your system, regardless of library used, that are secured by the list.  For this audit check, the following command format would work well:


Just substitute the name of your Authorization List where you see “myautl”.

The second command you will need is the Display Object Description (DSPOBJD) command.  This command can be used to create a database of all objects in a library.  The command can be used for all objects in the library or a subset of objects in the library.  You can also run it several times to add objects from other libraries to your database.  To create the database for all objects in a given library, the following command format can be used:


If you then want to add more objects from another library, use the following command format:


Once you have both databases created (note, these examples create the databases in the QTEMP library, but any library can be used), then all you need to do is use your favorite ad-hoc query reporting tool to match the two databases and generate a control report.

My favorite tool is WRKQRY.  On my system, I created a report to just list the library name, object name, object type and object text description.  The primary file in the query is the list of objects in the library.  I then used the list of objects from the Authorization List as a secondary file.  For the key matching, I selected the library name, object name and object type as that should be unique.  For the type of match, I selected the 3rd option that shows as “Unmatched records with primary file”.  This will end up only printing those objects that are in the library but are not secured by the Authorization List.

From start to end, this took me about 15 minutes and, in the end, I created a report that surprised me a little with the number of objects that were not properly secured the way I thought they should be.  To be able to recreate the process easily, I went ahead and created a CL program with a command which took another 10 minutes or so.  I now have this available and if you’d like to get a copy of the library that contains this utility, just drop me an email message and I’ll send it out to you.

If you find a lot of exceptions or surprises, like I did, you will also want to review your procedures to find out how this is happening and tighten things up.

If you don’t want to create your own monitoring tool, take a look at Kisco’s new iSecMap Security Monitoring tool.  It will implement this and many other processes that will monitor security on your system and help you keep your security policy enforced correctly.

If you have any questions about this topic or you would like a copy of the matching utility I created, you can reach me at rich at, I’ll give it my best shot.  All email messages will be answered.

Securing Your IBM i Production Files

By Rich Loeber

You will find a lot written about advanced topics in security for your IBM i, but if you don’t have basic object level security in place, all the advanced topics in the world may be a complete waste of time.  This tip will explore the basics of how to best secure native objects, including your data files, on your IBM i.

Before you attempt to secure your system at the object level, you have to check a system setting.  Using the Display System Value (DSPSYSVAL) command, check the following system value on your system:


If it is set to a level lower than 30, then you cannot implement object level security on your system.  In this case, the first thing you need to do is increase the security level setting for your system.  If this is your situation, I recommend moving to a minimum level of 40.  If you are at level 30, you should also consider a move to level 40 as it will help with an extra level of protection for the integrity of your system.

When you have finished this task, there are two more tasks that you need to check before moving on to the meat of object security.  If a lot of users on your system have special authority on their user profile set to include the all object (*ALLOBJ) authority, then these need to also be changed.  On a secure system, only a limited number of profiles should have all object authority to your system.  Typically, this is limited to the system security profile (QSECOFR) and any other security officers that are defined to your system.  All such profiles should have a documented business reason for having this special privilege assigned.  You can identify the profiles that are set this way by running the Display User Profile (DSPUSRPRF) command for *BASIC information to an *OUTFILE.  Scan the database file created for the *ALLOBJ string; this will show you how many profiles have this setting and which profiles they are.

Lastly, before you implement access rules on your system, you will need to determine an access policy.  This policy will define how you grant or restrict access.  The policy should be defined along application lines and have the support and approval of your organization’s management.

Now that we have these basics out of the way, it is time to implement security at the object level.  If you are really doing this for the first time, you have a choice of implementing security with private authorities on each object or by using an authorization list.  I recommend the latter.  When you have to make changes to security settings on the fly, having your security set in authorization lists lets you make changes at any time.  If your security access is stored with each object, then the object has to be available (ie: not in use) to make changes to it.

Security is specified at the object level and at the library level.  You also define public authority for general access controls and then you can grant specific greater access at the individual user profile or group profile level.  Public authority is best enforced at the library level, but it can vary also at the object level.  If, for example, you do not want just anyone accessing objects in a library, set the public authority for the library to exclude (*EXCLUDE).  As a first step, I recommend that you identify all user libraries on your system and get the public and private authorities set up for them.  Implementing security at the library level will take you a long way to having your system properly locked down.

Once your libraries have been configured for access rules, you can then go on to secure individual objects in the libraries.  You can customize access rules using system default settings as follows:

  • *EXCLUDE – the object cannot be used by anyone
  • *USE – the object can be read by anyone but cannot be changed
  • *CHANGE – the object can be read and updated by anyone, but not managed
  • *ALL – the object can be read, updated and managed by anyone
  • *AUTL – the object access definition of the authorization list is used

If you have very customized requirements, you can also carry this down to a more granular level by using specific settings available on the system.

This tip just scratches the surface.  If you have any questions about this topic, you can reach me at rich at, I’ll give it my best shot.  All email messages will be answered.