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.

IBM i Password Rules

By Rich Loeber

The first line of defense for most systems is the combination of user profile and password.  For most IBM i shops that I’ve worked in, once you know one user profile, you can usually guess most of the rest of the user profiles.  Different shops use different approaches, but they all seem to key off the user’s name or initials.  Some shops may use a more obscure method, but that only tends to make support more difficult when you need to quickly identify the user based only on their profile name.

Given that guessing a user profile can be pretty easy, it makes it very important that passwords not fall into the category of being easy to guess.  For many years, the IBM i OS has provided tools to let you implement a variety of measures to help you with this goal.  This tip will look at some of these and point you in the direction where you can find even more.

The keys to knowing how to enforce password rules are found in the system values that are included in the IBM i OS.  The OS includes a whole set of system values that start with QPWDxxxxx.  Each of these can be used to do things like set the password expiration time period, limit specific characters in a password, limit adjacent characters and digits, enforce password length minimums and maximums, control how often a password can be reused and more.  My personal favorites in this of rules is to disallow any vowels in a password, disallow repeating characters and require at least one digit.  These simple rules go a very long way in forcing users to create passwords that are hard to guess.

With more recent releases of the IBM i OS, there are a wealth of new password options open to you.  These are all available under the system value of QPWDRULES (Password Rules).  This single system value can be set with a maximum of 23 different rules.  You can enforce all of the earlier rules that were available in earlier OS releases plus you can implement new rules.

If you like the way you’ve had things set up before, then you need to make sure that the QPWDRULES parameter is set to the value *PWDSYSVAL.  This will tell the OS to use the individual settings.

A word of warning at this point.  If you are planning on using any of the new values available to you, then you need to first document how each of the old QPWDxxxx system values is currently set.  Once you change the QPWDRULES to any value other than *PWDSYSVAL, then the older system values will all be ignored (with the exception of QPWDLVL which is always in force).  You must first make sure that the current settings you are using are duplicated within the new  QPWDRULES that you set up.

Some of the newer possibilities that I’ve seen that appeal to me include:

•    *LMTPRFNAME – when this is set, the user profile cannot appear as a string anywhere within the password.  For example, user profile JOHN cannot have a password of DOEJOHN.

•    *MIXCASEn – allows you to require that a password contain at least n upper case characters and n lower case characters.  This is only valid on systems running with a QPWDLVL setting of 2 or higher.  For example, if you specify *MIXCASE2, then the password A12bC45 is not valid because it is missing one lower case character.

•    *REQANY3 – requires that a password must contain at least one character from the four character types of uppercase letters, lowercase letters, digits and special characters.  For example, the password of ABCabcd is rejected since it does not contain any numbers or special characters.

For a complete list of all of the QPWDRULES options, go to the IBM i Information Center at the following link:  Select the IBMi OS version option and then enter the value QPWDRULES in the search box.  Look at the first article that comes up called “Password Rules” and you’ll find a complete list of the options.  Keep in mind that this is only available if you are running a currently supported OS level (6.1or higher).

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 in the IFS

By Rich Loeber

The IBM i OS is rightly known for good built-in security features.  For those of us who grew up with it since the early AS/400 days, security requirements for the “native” library file system are pretty easy to understand and administer.  When it comes to the Integrated File System (IFS), however, things can work differently.  This tip will explore some of the differences and how best to try and deal with them.

If you grew up with the IBM i OS from the early days, you know that the native file system that is based on libraries and objects within those libraries.  Security can be implemented at the library level and at the object level and the hierarchy is intuitive.  The IFS can be different.

First, remember that the IFS is a global term for a variety of file systems that are available to the IBM i user.  In fact, it includes what we refer to as the “native” file system within the QSYS.LIB file system.  Other file systems include the “Shared Folder System”, also known as the QDLS file system; the “/root’ file system, the QOPT file system, the QopenSys file system, the QFileSvr.400 file system and more.  These other file systems all employ an organization based on nested directories.  Where your files reside will determine your approach to securing them.  If you’re just using the native file system, this tip is not for you.  If you’re using any of the other file system (and most IBM i shops today are in this boat), then read on for some things to watch out for.

The exact security set up that you choose will depend on how the files are stored in the file system in question.  For example, the QOPT file system (for optical drive operations) has no security at all since there is no way to write security information to the file system, it is read-only.

The IFS file system is designed to follow POSIX (Portable Operating System Interface) standards wherever possible and certain unusual behaviors can happen when this is mixed in with the IBM i OS.  Here are some things to watch out for.

When you create a directory, the owner must also appear in the security authorization for the directory.  In the native file system, the owner has clear rights to an object, but not so in the IFS.  The owner’s rights must be defined as a private authority.

For files in the IFS, keep in mind that adopted authority is not honored for most file systems including the root, QDLS and QopenSys file systems.  Your application designs may rely on adopted authority for the native file system, but this approach will not work for most other file systems on the IBM i.

Most file systems will require *RX authority to read an IFS file.  This will apply to every step in the directory path.  If your application needs to read objects in the IFS, make sure that *RX is in place for the entire path structure.  Object management rights (the X character) are needed for some functions that you might not normally think of, so it is best to include it.

When making copies of files in the IFS, be careful which command you use.  The COPY (or CPY) command will duplicate the file including the file’s authority settings.  The CPYTOSTMF command, however, is only intended to copy the data in the file.  The file created by CPYTOSTMF will be owned by the user that runs the command and the owner’s rights from the original file will be dropped.  You will have to reset the authority the way you need it once the copy has completed.

For a complete discussion on these along with other things to watch out for, check out the IBM i Knowledge Center in the Security area for your level of 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.

A Case For Contextual Security

By Rich Loeber

My wife and I live in the Adirondack Mountains of northern New York state.  During most of the year, except for 10 weeks during the summer, we have very few neighbors with the closest being almost a mile away.  On a normal day, we get a handful of cars that drive down our road (unless you count the number of times the snow plow goes by).  In this context, we’re not very concerned about security.  We rarely, if ever, lock our doors.  We know all of the year round residents and they know us.  We all look out for each other and that seems to be all of the security that we need.  Our biggest security consideration is the local bear population, they get into the trash if you’re not careful and make quite a mess.

In the IBM i world, context can define how you handle security.  Security in the OS is not attenuated to context, so you have to think about your requirements and implement contextual considerations as they apply.

What do I mean by contextual security?  Here’s the classic example.

Suppose that you have an order processing application that records credit card information and then processes that information to obtain credit card authorization approvals.  Obviously, the clerk entering the order needs to have access to your customer database in order to enter the credit card information or validate the information that you already have on file.  Within your standard security model, you will need to grant this user access to the information with sufficient authority to add new information, change existing information or even delete current erroneous information.  For their normal order processing tasks, this user can be configured easily to provide for database access and change authority.

But, what about other possible accesses to this data that do not fall within the normal context of their job execution?  The same level of access that they normally require is inappropriate when accessing your customer credit card information via FTP or by using IBM iAccess download functions.  When using these functions, this same profile can make a copy of all the credit card information on their desktop, then copy the information to a flash disk or memory stick and walk out of the office with all of your credit card information in tact and nobody would be the wiser until the story breaks in the NY Times.

Given this reality, obviously the single context approach to database security is not going to work.  The user does need access rights to do their normal job requirements, but they need to be restricted from access for other contexts.

Fortunately, there are several ways to accomplish this on the IBM i and I’ll just mention three of them here so you can start thinking of how to get this taken care of.

First, and possibly easiest although not always cheapest, is to buy and install a good exit point security solution.  There are several such solutions available on the market from reputable software developers.  (I recommend SafeNet/i, the solution from my company.)  The exit point solution lets you define a network access context for your users and restrict network accesses that might otherwise be wide open to them.  You won’t have to change the security setup in the IBM i OS, but the extra layer of security from the exit point solution will add the contextual security you need from network based applications like those already mentioned.  You could write your own exit programs, but exit point programming is not for the feint of heart and the rules periodically change as the OS goes from release to release, so it is better to go with a good solution from a trusted software supplier (like ours!).

There are two other approaches that are similar in nature and can also let you define security on your IBM i based on context.  One is adopted authority, the other is profile swapping.  In both cases, the security in force when you application runs is NOT based on the user profile doing the work but on some other method.  With adopted authority, your program is set to base security decisions on the user profile that owns the program, not on the profile that is running the program.  This way, you can control who gets to use the program, then the program itself can control the resources that it needs access rights to.  With profile swapping, you can let the requesting user profile control things up to the point where different access rights are needed, then under program control, you can call an API in the OS to swap profiles and run under a different profile for a given duration of processing.  Either way, the user profile used to determine access rights is different from the user signed into the application, giving you contextual control over the situation.

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.

Watching Your Super Users

By Rich Loeber

Every IBM i shop has a few super users that you, as security officer, have to be concerned about.  For one reason or another, a few user profiles just have to have full access to your system.  This tip will show you one way to check up on what these users are up to, using the system security journal.

For specific user profiles, you can implement additional security auditing that is over and above what your system is configured to capture.  To make sure that your super users are not over stepping their bounds, you can set up the security journal to capture additional security events for these specific profiles.

To get started, you need to have the security journal active on your system.  If it is not active, you can just run the Change Security Auditing (CHGSECAUD) command.  Running the command with the defaults shipped with the OS will set up the security journal (QAUDJRN).  By setting the default values to *NONE, you will limit what the security journal captures so you can experiment with tracking an individual user profile’s activity.  Of course, if you already have the security journal active and running on your system, you can skip this step and continue on with setting up the individual profile controls.

With the security audit journal active, you are now able to set up specific event controls at the user profile level.  This is done using the Change User Auditing (CHGUSRAUD) command.  Type this command in and use the F4 key to prompt for the parameters.  For this tip, we’ll concentrate on the “User action auditing” (AUDLVL) parameter and what things you can track at the user profile level.  These include the following:


  • *CMD – this setting will record command strings used by the profile in the journal for your review.  With this setting, you can see what specific OS commands the super user is using and make sure that command line abuse is not happening.
  • *CREATE – this setting will let you track all new objects created by the super user.
  • *DELETE – using this setting, you can see when a super user deletes an object.  Since this is a concern for super users, you can track it easily using this method.
  • *OBJMGT – this setting tracks object renames and moves.
  • *SAVRST – this setting lets you track save and restore operations by the super user.
  • *SERVICE – this setting lets you track the super user’s use of system service tools.
  • *SPLFDTA – this setting lets you track actions taken on spool files.
  • *SYSMGT – this setting tracks system management functions.
  • …. more

Different levels of IBM’s i/OS include a number of new/different functions that you mAY want to explore.  The AUDLVL parameter accepts many more options thaN I’ve listed here.  For your installation, you may find some of the other values of particular interest.

A nice side benefit of logging super user activity to the security journal is that it is a good proof for your auditors that super user profiles are being used responsibly.  Every auditor I know of who knows what they are doing is concerned about what super users are up to.  This method goes a long way to satisfy their requirements.

If you have any questions about anything included in this tip you can reach me at rich at,  All email messages will be answered as quickly as possible.