The Case For Better User Profile Names

By Rich Loeber

Ever since I started working in an environment where I needed a user profile and password (yes, there was a time when these were foreign concepts), I have always used a simple profile based on my first name.  As I moved from System/34 to System/36 to AS/400 to iSeries to IBM i on PowerServer, I just kept that same simple profile name.

But …. no longer.  I am now a firm believer that first name profiles are a very bad idea.  There are several reasons for this change.

First, recent studies show that people are really bad about picking secure passwords.  Current studies show that, unbelievably, the most commonly used password is “password”!  Check this for a recent list of the most commonly used passwords.

Since people are so bad about choosing passwords, having a user profile that is easy to guess makes a scripted attack very possible.  In a scripted attack, a hacker attempts to gain access to your system by trying a typical user profile in combination with the list of commonly used passwords.  If your system has simple first name profiles, then it could be at risk.  Even if the hacker does not gain access to your system, they could easily end up disabling a lot of your user profiles because of multiple logon failures.

There are two ways that a scripted attack is normally mounted.  The most obvious is via FTP.  In the scripted attack, a series of logon attempts is done using an automated FTP client.  Common profiles are coupled with common passwords and repeatedly tried to see which combination works.  When a match is found, the profile/password is reported back to the hacker so they can explore further at their leisure.

On our IBM i test box, FTP scripted attacks are all stopped before they get to the point where a logon is run.  This is because we use our SafeNet/i exit point security software that only lets FTP connections in from known and trusted IP addresses.  We collect the profiles used, however, so we can report to you on the most commonly used profiles that we are seeing.  From these FTP attempts, the most common user profiles used are:


Since we are protected by SafeNet/i, we were not too worried about the few common user profiles we had until a recent attack resulted in two profiles being disabled.  We quickly turned to our exit point log, but there was no record of the activity.  We also checked the system log (DSPLOG) but nothing reported there shed any light on why the profiles, including my trusted personal profile, got shut down.  As a last attempt to discover what happened, we turned to the system security audit journal.  What we found there was an eye opener.

We run the POP server on our IBM i.  We use it, in combination with the SMTP server, for sending outbound email from the system with our WebReport/i software.  This lets us send email without depending on any other office servers.  What we discovered from the system audit journal was that another form of scripted attack was taking place under the covers on the system with no knowledge on our part.  A little research revealed that we were being subjected to what is known as a “Brute Force POP3 Attack”.  It is like an FTP scripted attack, but broader in scope.

An analysis of the T-PW records recorded in the security audit journal showed that over a one month period, more than 20,000 attempts had been made to log into POP3 accounts.  Fortunately for us, we were protected by quite a few other best practices for IBM i security, not the least of which is that we do not use the POP server on our IBM i for inbound mail, so none of the mailboxes actually exist.  That, however, does not stop the hacker from trying.  And, since people tend to use the same password in all places, a user profile/password combination found at the POP server level could easily be tried to gain access to the system by other means.  From our analysis of these break-in attempts via the POP server, the most common user profiles are:


By looking at these, it is clear that the hacker or hackers are not aware of the type of system that they are trying to access.  None of these profiles are commonly used on the IBM i platform.  But, you can see some profiles that might easily be in existence on a normal system deployment which gives cause for concern.

What can you do?

Here are some simple ideas in brief:

  • Don’t keep the POP server active on your system if you don’t need it.
  • Don’t keep the FTP server active on your system if you don’t need it.  If you do need it, only have it active during hours when you expect it will be used and shut it down during other times.
  • Implement enforced password rotation if it is not already active.
  • Implement the user profile password rules to always require a numeric digit as a component of the password.
  • Review the active profiles on your system for simple first names and get them changed.
  • Check the common profiles used on most IBM i systems and make absolutely certain that their passwords are complex and hard or impossible to guess.
  • Implement exit point controls, check out our SafeNet/i product.
  • Consider disallowing vowels in your passwords.  IBM i system value password controls will let you do this.  At a minimum, rule our the letters E and A.
  • Check your system security audit journal regularly for T-PW records to see if you are getting unexpected password denials.

If you have any questions about this, or you need help with implementing any of these recommendations, feel free to contact me by email at rich @  All email inquiries will be answered.

Watch Out When Restoring User Profiles

By Rich Loeber

I was recently confronted with an issue on one of our test IBM i boxes.  The box is implemented as a “warm” backup site for one of our customers.  Every night, a simple FTP of changed objects takes place from their server to our test box.  The theory is that the customer can afford to loose one day’s worth of processed transactions for the ease and relatively low expense of maintaining this sort of backup site.

The problem posed to me concerned their security configuration.  While their program base and data files were all being properly synced night after night, their passwords were growing woefully out of date on the backup site.  If they had an emergency, nobody would remember their older passwords.

I thought that the solution would be simple.  Just run a SAVSECDTA (Save Security Data) on their system, then restore it on our test box.  Before doing this, I compared the user profile base on both systems and found some areas for concern where the same user profile existed in both places.  Fortunately, the RSTUSRPRF (Restore User Profiles) command lets you either restore specific profiles or restore all profiles with an exclusion list.  I wanted to exclude all Q* profiles plus a handful of common profiles that exist on both systems.  My list ended up being fairly short.

I was all set to bring these profiles current, but when I tried the RSTUSRPRF, I was gently reminded that this command can only be run when the system is in restricted state.  Our test box hosts several websites including one that runs in secure HTTPS mode.  Thinking this would be a quick process, I shut down the system after notifying a few people that there would be a short interruption in service.  When the system came to restricted state, I ran the user profile restore which ran quickly and without any issues.

I then restarted the system, and here is where it got interesting.  At first, it looked like everything was fine, but I soon found that the web server instance that was using HTTPS was not restarting correctly.  After poking around for a few minutes, I found that it was objecting to the digital certificate that was specified for the site.  I fired up the Digital Certificate Manager (DCM) to see what was going on and the certificate looked just fine.  I decided to delete the certificate and re-add it, and here is where the train wreck was revealed.

When I tried to re-issue the certificate, I was advised that my password for the certificate store was invalid and that I would have to change the password before I could issue the new certificate.  I dutifully changed the password, but the same error kept coming back up.

After a long investigation period, I finally determined (with help from on-line friends) that the root of the problem was the RSTUSRPRF.  It turns out that the restore user profile process restores critical data and keys for the digital certificate store while restoring your profiles.  I now had this information from our client’s box, not ours.  None of the certificates on our system were valid any longer and additional applications on the test box were also failing because of this.

The solution was fairly simple.  You just have to restore the Digital Certificate Manager objects from a security backup from your system on top of the restore just done from the foreign system.  The RSTUSRPRF has the following format for this process:


It took me a while to find a current backup of our system’s security data (another story for another time).  As soon as I did this, then DCM would work correctly and the invalid digital certificates could all be re-created.  While our system was not technically down for this time period, several applications were knocked out for almost 6 hours.

Who would ever guess that restoring user profiles would end up hosing your digital certificate files?  A friend blames this all on IBM for such a kludgey implementation of DCM.  I have to say that I agree.  The save and restore of this certificate information should not be hidden along with the user profile save/restore.  The fix should be a new command from IBM for RSTSECDTA.  Let the user profile restore do just that and move other operations to a different command process.

Hacking Report For Our IBM i – 1st Qtr 2013

By Rich Loeber

For years, Kisco Information Systems has kept a lone test IBM i server hanging out directly on the Internet.  No firewall, no security appliances, just a direct connection with a dedicated IP address.

Not a very good idea you say?  Well, Kisco sells a network security software solution called SafeNet/i and what better environment to test and prove that the software works.  Using a combination of the best IBM i OS security practices along with a full implementation of SafeNet/i, Kisco is happy to report that their server has never been hacked successfully ever since this test server was first placed on the web more than 15 years ago.

That’s a good record!

But, that is not the purpose of this report.

To help IBM i shops understand the reality of network threats, we are now reporting some results of what we see on this test box.  We hope that it will help IBM i users to better prepare for the very real threats that exist.

This report shows what we’ve seen on our server during the first three months of 2013.

During this time, our test box reported 211,346 network transactions that passed through the various exit points registered to SafeNet/i.  Out of this total, 1,603 (0.75%) were identified as illegal access attempts and were denied.  That represents about 18 times each day when someone tried to gain access to our system, but was not authorized for that network activity.

Of these 1,603 access denials, all of them fell into just two categories during this test period.  FTP access connections accounted for 1,025 and the other 593 are Telnet connection attempts.  All of these connection attempts were refused by SafeNet/i before the requests even reached IBM’s OS.

A further look at these access denials shows that 1,015 of them came from user profiles that do not exist on the server.  The most popular profile, by far, was “ADMINSTRA” which accounted for 700 failed attempts.  The next most popular was “ALAN” with 37 followed by “TEST”, “ADMIN” and “ALBERTO”.  All of these were FTP connection attempts.  These all appear to be FTP script connection attempts, probably cycling through a series of popular password combinations.  It argues strongly for user profiles on the IBM i that are not based on people’s first names or job functions.

Looking at the access denials from a different perspective, we see that all 1,603 during this test period were denied access because they originated from IP addresses not recognized by SafeNet/i.  For FTP and Telnet connection, SafeNet/i only allows a connection to be established when the IP address is recognized.  By carefully maintaining the table of legitimate connectors to the system, illegal connection attempts are controlled.

Of these illegal connection attempts, 49 source addresses tried to connect multiple times.  The most persistent tried to connect 367 times in succession, all of which were denied.  There were others from different source IP addresses who attempted to connect 271 times, 195 times and 118 times.  Some only tried twice.

Are these illegal connection attempts really something to be concerned about?  To check this, we did a reverse lookup on the most common IP addresses that were denied.  Two of the addresses checked back to an ISP in Brisbane, Australia.  Two others were tied to ISPs in Scranton, PA and Galloway, NJ neither of which are associated with any known developers that we normally work with on this server.  The obvious conclusion was that these access attempts were malevolent which is all the more troubling since the IP address of our server is not generally known to the public.

During this study period, 18 valid source IP addresses connected over and over again to get their legitimate network work completed.

For those attempting Telnet connections, the pattern is a little different.  Within the IBM i OS, all of these failed attempts are logged under the common user profile of QSYS.  Telnet attempts, however, do not follow the brute force attempts that FTP users try.  They tend to be solo connection attempts or just two in a row.

Kisco Information Systems will keep an eye on these connections attempts and will periodically issue updates on the results by quarter.  Feel free to check back to our IBM i Security Blog for future reports.  If you have questions about details of the report, feel free to contact me directly by email (rich at

Tracking User Profile Signon

By Rich Loeber

I recently received email from a reader asking me how they could track sign-on activity for their security officer user profiles.  The objective was to have a record of every time someone started a terminal session from one of these very powerful user profiles.  Since these profiles have so much power to update and change your system, having a record of when and where these sessions are started is a good idea.  Fortunately, there is a fairly easy way to do this within the operation system on your IBM i.

With each user profile on your system, there is an “Initial program to call” (INLPGM) parameter.  Whenever someone signs onto your system, the operating system checks this parameter and, if there is a valid program present, calls it.  You can take this feature and use it to create your log of user profile sign-on activity for selected user profiles.

The first step is to create a simple CL program.  When the operating system calls the initial program, no parameters are passed, making your task quite easy.  In your CL program, you will need to retrieve the user profile using the Retrieve Job Attributes (RTVJOBA) command.  Armed with the current user profile, then just send a message using the Send Program Message (SNDPGMMSG) command to a pre-defined message queue indicating that the user profile has performed a sign-on operation.  When I was testing this, I used the QSYSMSG message queue since it gets used by the operating system for security related events.  But, you can use any message queue that works for you.

Problems may arise, however, in a couple of areas that you need to be prepared for.  I have created this CL program on my system and have accommodated these issues.  See the end of this tip if you’d like a copy of my source.

For starters, your system may already have an initial program set up for the user profile.  If that’s the case, then you will need to create a data area and store those values before you change the initial program setting.  In my sample program, I’ve created a data area with the same name as the user profile in a special library.  The data area is 20 characters long and contains the initial program and library associated with the user profile before my tracking program is set up for the profile.  Since you want this to work for any user profile, the CL should check for the data area and, if it is not there, just assume that no initial program processing will be needed.  After you have logged your activity message, just end your CL program by calling the program stored in the data area.

You will have to remember that every user profile will have to be able to run your program.  To make sure this is not an issue, you should have the profile adopt the permissions of a security officer profile.  This is done when you compile the CL program by setting the USRPRF parameter to *OWNER and running the compile under the profile of a security officer.

When everything is set but before you actually change the initial program setting on any profile, test your CL program to make sure it doesn’t fail.  This is one of those areas where it would be very easy to shoot yourself in the foot by implementing without testing.  In the worst case, you might get locked out of your system.  So test, test, test before you run with it.

Once implemented, then all you need to do is monitor the message queue.  As users that you are tracking sign on, a message will show up in the message queue.  Using the HELP or F1 key will also give you a date and time stamp of when the activity happened.  If you want, you can also expand the information captured and reported by including other information from the Retrieve Job Attributes command such as job name, job number, etc.

If you have any questions about this topic, or if you would like a copy of my sample CL program, you can reach me at (rich at,  I’ll send the CL along and try to answer any questions you may have.  All email messages will be answered.

In this day and age, security officers can also access your system by means other than using a terminal session.  To capture this activity, you will have to implement exit point solutions.  This can be a daunting exercise, but our SafeNet/i software in it’s Lite version, is a very affordable solution to this problem.  It is available for a free 30 day trial if you’re interested.

Making Sense of the IBM i Security Audit Journals

By Rich Loeber

To track security events on your IBM i, the i/OS has quite nicely provided an extensive security audit journal function to help you.  When you have security auditing active on your system, all sorts of relevant security information is regularly stored in your system security audit journal that will help you to know what’s going on with your system.  This is a great feature for the IBM i OS, but capturing the audit information and then using it in a meaningful way are two different things.

This tip will just scratch the surface of how you can start to make some sense out of all the information that is stored with your system security audit journal.

The secret that starts the process of unlocking the system audit journal is the Display Journal (DSPJRN) command.  To work with the system audit journal, run this command for the journal named QAUDJRN.

The command defaults to displaying information to your terminal screen.  This is a hard way to wade through the information, although there are any number of filters that you can use to limit the information displayed.

A better way to work with this information is to run the Display Journal command using one of the options that transfers the journal information into a normalized database file.  This is done by selecting the option OUTPUT(*OUTFILE).  When you do this, you will have to specify the format for the output file.  There are five different formats offered, from *TYPE1 through *TYPE5.  You can use the HELP function to see the difference.  Each higher number format builds on the information in the base *TYPE1 format.  If you’re just starting, the *TYPE1 format should be sufficient.

Once you have your database built, then it is time to start analyzing it to see just what you have recorded in your security audit journal.  For starters, I recommend that you run summary reports on fields like the Entry Type, Job Name, User Profile and so on to see how many records you have in your current journal with various values.  On our test system here, I do this with the old “Query Two Step” of summarizing the information to a file and then reporting that file.  I have some Query definitions that I’ve created for this purpose that I would be happy to share with you in a save file that you can restore to your system.  If you’d like a copy, just let me know by email (rich at and I’ll send them to you.

As you work with the databases that you’ve created and the various analysis reports that you work with, you will also need to have a copy of the IBM i Security Manual handy.  There are at least 100 pages in the Appendix (on ours, it is Appendix F) that describe all of the information in the various database formats, not to mention the codes that can be contained and what they mean.  On our system, I’ve even found codes in the security audit journal that are not documented in the Security Manual.  In that case, the next stop is IBM support.

If the tasks seems too daunting for you, I’m certain that you will not be the first security officer who has thrown in the towel on analyzing this audit journal.  There are a number of third party software solutions that have taken the time to do all of the necessary investigation and one of them might just fill the bill for you, not to mention lowering your blood pressure.

Auditing Power User Activity

By Rich Loeber

I regularly hear from IBM i shops where users, especially programmers, claim that they absolutely must have access to all objects to get through a normal work day.  There are also many shops where certain users claim that they need to be defined to the system as security officers to get their jobs done.  Now, we all know that this is just not true, but some shops cave in and provide these authority levels as a form of appeasement.  So, if you’re the security officer in one of these shops, it is really incumbent on you to know two things:

  1. What profiles have these special authorities
  2. What those profiles are up to on your system

Fortunately, in the IBM i world, you can give someone the keys to the kingdom, but also have the system watch over their shoulder.

The first step is to identify the users that need watching.  To do this, run a Display User Profile (DSPUSRPRF) command for all profiles using the *OUTFILE option to create a database that you can analyze.  The basic information option is sufficient for your purposes.  Using the new file just created, write a Query report (or any similar database reporting tool you may have) to select all profiles with the user class field set to *SECOFR or that have the values *ALLOBJ and *SECADM in the list of special authorities.  This will give you your list of profiles that need watching.

The rest of this tip assumes that you have security auditing active on your system.  If you don’t, drop me a line and I’ll let you know how to get this active on your system.

Your next step is to check the system value QAUDLVL and make a note of the specific audit values that are already being logged on your system.  For those profiles that you specifically now want to track all security activity, you will then need to use the Change User Auditing (CHGUSRAUD) command to add all of the audit values that are not currently listed in the QAUDLVL system value.  This will ensure that all actions by these users will be included in the security journal.

Now, for those users that are particularly savvy, you will want to remove their ability to change the system auditing that you have just imposed on their profiles.  You can do this by removing the *AUDIT special authority on their profile.  Chances are excellent that they will never notice that this is gone, and by removing it, they will not be able to undo what you’ve just set up.  A note of caution, you will not be able to remove this from the QSECOFR profile.  Make sure that the password for this profile is not generally known as that could also defeat your objectives.

Lastly, check the system value QAUDCTL and make sure that it is set to the special value *AUDLVL.  If it is not already set to this value, check around before making the change to make sure that you will not end up shooting yourself in the foot by making this change.

Now that you have all the pieces in place, you will find all of the information you need to do to track these users in the system security journal.  Use the Display Journal (DSPJRN) command to display the information or move it into a database file on a regular basis for reporting and analysis purposes.  You will find information in the iSeries Security Manual on how to process information from the security journal and how to interpret the codes and other information available there.

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

Restoring Your Security Configuration

By Rich Loeber

I recently wrote about saving your security configuration.  Once you’ve got your system backed up including all of the security information, what’s the best way to make sure that all of that security information is restored correctly when you have to do a full system restore.  Missing something or getting things in the wrong sequence could result in your objects being restored without the security configuration that you want.

First, you will need to plan the sequence of events in your restore operation.  For security to come out right, you should always restore your saved user profiles first.  The second task is then to restore the objects to your system.  Lastly, once the profiles and objects have all been restored, you should restore the private authorities to objects.

Let’s take a look at how to accomplish each of these steps in a way the makes certain that your security settings are all preserved.  As a safeguard, make sure you have access to the password for the QSECOFR profile on the system being restored.  You should have access to the current password and the password being restored.  If you have any serious security issues during the restore, you may have to logon as QSECOFR as a recovery option, so having access to these passwords may become critical.

To restore your saved user profiles, use the Restore User Profiles (RSTUSRPRF) command.  If you are restoring all user profiles, you should be aware that all settings for each profile will be based on the saved version of that profile.  If any changes have been made to a profile and you are restoring to the same system, those changes will be lost.  Also, make sure that the user profile being used to do the restore has both all object (*ALLOBJ) and security administrator (*SECADM) special authorities.  Otherwise, any profiles being restored with *ALLOBJ special authority could have that authority stripped during the profile restore operation.  This will not affect critical IBM Q profiles, in case you’re worried.

Once your user profiles are successfully restored, the next step is to get your objects restored.  You can use any of the following commands to restore objects on your system:

•    Restore Library (RSTLIB)
•    Restore Object (RSTOBJ)
•    Restore Configuration (RSTCFG)
•    Restore Object (RST) – for objects in the IFS
•    Restore Document Lib Object (RSTDLO) – for objects in shared folders (QDLS)

When restoring objects, be careful how you use the “Allow object differences” (ALWOBJDIF) parameter.  If you attempt to restore an object that already exists on the system and the object being restored is owned by a different profile than that being restored, the allow object differences command setting of *NONE will result in the object not being restored.  If you use a value of *ALL, then the object will be restored and the system owner will be preserved.

Also, you need to be aware that there are special considerations for public authority and authorization list values during object restores.  Generally, if an object is being restored that already exists on the system, the current object settings are preserved rather than applying those from the saved object.  For objects secured by authorization lists, the ALWOBJDIF parameter can result in objects not being restored when there is a difference between the current value and that being restored.  There is a thorough discussion of what is restored and not restored in the Security Reference Manual, Chapter 8.  Check on the issues of private authorities, object auditing, authority holders and more for these considerations.

To restore authorities, it is recommended that you run the Restore Authority (RSTAUT) command after all objects have been restored.  This will rebuild the object authorities in the user profiles.  Your restore will not be complete until this step is done.

Saving Your Security Configuration

By Rich Loeber

As your IBM i shop’s security officer, you’ve developed a security policy; analyzed the user base; classified the various points of information access and implemented your policy to protect the data assets on your system. You have a current user profile base that you’re maintaining on a regular basis. When new applications come along, you review the security requirements and make sure that they can fit within your established policies. You probably even have a plan in place for offsite backup storage for your shop with a regular schedule of backups and tape rotations.

But, have you given thought to how your security policies are stored on your system and how they figure into your backup process? If not, you might be in for a rude awakening when you need to restore your system following a catastrophic system loss. This tip will take a look at how the various pieces of your security implementation are stored on your IBM i processor. A future tip will then look at how your can make sure that your security setup can be restored successfully.

Your security configuration is stored in three different places on your IBM i server. You should be familiar with these storage locations and how they relate to your security implementation.

Some security information is stored with individual objects. These include things like public authority settings, who owns the object, what the owner’s authority to the object is, group authorities to the object, the name of any authorization list that applies to the object along with private authority information.

In addition to the security information stored with each individual object, there is also a wealth of security information stored with your user profiles. This information includes user profile attributes, the profile’s UID (User Identification Number) and GID (Group Identification Number), private authority information to objects, object ownership information, group profile information, profile auditing information and information about registered functions for the profile.

Lastly, there is security information stored with existing authorization lists on your system. This includes a list of objects secured by the list along with other normal authority information to be considered for objects secured by the list.

When you save the objects on your system, only part of the security information is getting backed up to tape. In order to get a complete backup of your system, including all of the current security information, you must not only save the objects, you must also save the security information. This requires using the Save Security Data (SAVSECDTA) command. This command will backup the user profiles, authorization lists and any authority holders that you have in your security configuration. Only when both the objects and the associated security data for your system are saved will you get a full backup of your security implementation.

There are some restrictions on the use of the SAVSECDTA command, so if you introduce it into your save/restore plan now, make sure that you understand those restrictions and accommodate them. Of special concern is the PRECHK parameter and the possibility that it could abnormally terminate your backup operation. See the HELP text associated with the SAVSECDTA command for more information.

IBM i Security New Year’s Resolutions

By Rich Loeber

Many people, self included, take this time of year for a little introspection.  We try to see where we have problems or weaknesses and then contemplate methods and strategies to make changes.  If we’re serious, we’ll sit down and make a list of things to do in the New Year.  As the security officer for your IBM i shop, this is a good opportunity to do just that for your installation and here’s my list of some items you should consider.

  • Finally take the plunge and move the security level of your system up at least one level.  If you’re running at level 20 (shame on you!), move to level 30.  If you’re at level 30, move to level 40.  Take the time to plan the move and use system security auditing to check results before you make the change.
  • Check your system for user profiles with permanent passwords; then change them all.  This will, at least, enforce an annual change in these passwords.  And, this means your personal password too!
  • Review the user profiles on your system and look for people who have left the company.  Make sure those profiles are disabled and their passwords have been changed to *NONE.  If you can do so easily, remove the profiles.
  • Review all user profiles with the *ALLOBJ special authority or *SECADM/*SECOFR user class.  Verify that each profile has a valid business reason for these high level access permissions.
  • Do a full audit of all of the security related system values on your box and make sure they are set up to enforce your company’s security policies correctly.
  • Audit your system backup plan and make sure that the tapes are being properly labeled and stored for quick and accurate recovery if needed.
  • Check on the way your backup tapes are transported to and from your off-site storage facility to make sure they are secure in transit.
  • Dust off your Disaster Recovery plan and make sure it still works.  Bring it up to date, then schedule an actual test.
  • Review physical security arrangements for your computer room and for all devices attached to your system.  Do a walk thru and actually look at the various work locations.  Check for things like passwords on post-it notes and lists of system resources.  Spank a few hands (not literally) for violators.  Your physical presence in the end-user’s environment will go a long way towards reinforcing the importance of security.
  • Resolve to review your system security audit journal on a regular basis.  If you don’t have it active, turn it on.  If you have it turned on but never look at it, develop a review process to check for problem issues.
  • If you don’t have network security implemented at the exit point level on your system, commit to getting this done in the new year.  Either write your own exit routines or take a look at one of the many packages available for this important area of system security.  If you’re new to this, take a good look at Kisco’s SafeNet/i Exit Point solution.

If you have other items to add to the list, let me know by email.  I’d love to hear about your new year’s resolutions.

For me, I’m going to just resolve to loose 20 pounds this year.  But then, that was my resolution last year and I’m weighing in at the same rate this year.  At least things didn’t get worse.  Let’s hope that your system security resolutions fare better.

Blocking Object Access

By Rich Loeber

I am often asked specific questions by readers about a situation in their shop. I enjoy hearing from readers about their real-life situations. One of the most frequent questions I hear is “How do I keep a specific user from accessing certain data files on my system?”.

The answer depends a many variables. First of all, if the user you want to block has been set up with all object authority at the user profile level (SPCAUT containing the *ALLOBJ setting), then there is really nothing you can do at the operating system level to block access. This is a frequent song that I sing, but there should be precious few user profiles on your system with this level of access. And, you should have some pretty good business reasons for granting it to those profiles where this level is supported.

Assuming that this is not an issue, then the easiest way to block access to a specific file is to edit the authority for that object using the Edit Object Authority (EDTOBJAUT) command. Add an entry for the user profile you want to block and set it to *EXCLUDE. If you want to block everyone except certain users, then set the *PUBLIC access to the object to *EXCLUDE and specifically authorize the profiles where access needs to be granted.

If your object is secured by an authorization list, then you should to make these changes to the associated authorization list. The list in force is shown when you edit the object authority. Having your object authority controlled by an authorization list is a good idea as it lets you make security changes at any time, not just when the object is not in use. Also, you can secure multiple objects with the same authorization list thereby simplifying your security administration task.

If you decide that you want to block access to all the files in a given library, then you can edit the object authority for the library. Adding public *EXCLUDE access authority at the library level will extend to all objects within the library. Remember, this will extend to all objects in the library, not just data file objects. This could be a concern for you depending on how your applications are implemented.

You can also exclude users from accessing objects that are stored in the Integrated File System (IFS). In the IFS, you can specify *EXCLUDE authority for any object for a given user profile. From the command line, you can work with IFS security from the WRKLNK command. From iSeries Access, the security functions are also available and may be easier to work with for you.

Lastly, if you have a whole group of people where you want to block access, consider placing them all into a group on your system. If you are already using group profiles and your blocking scheme does not match up with your current group implementation, then you can set up the users to be blocked in a supplemental group. The IBM i/OS provides for up to 14 supplemental groups for each user profile on the system giving you a lot of flexibility. Remember, doing things at the group level reduces your security administration overhead.