About admin

Founder of Kisco Information Systems

Lock Up Your System Values

By Rich Loeber

When you implement your company’s security policy on your IBM i, often the first thing you do is review your system values.  System values define global, system-wide settings on your IBM i platform.  Many of these system values pertain to how you want to implement system security.  This tip will review how to look at these settings and then, how to lock them in place so that they cannot be changed.

So many of these system values are security related that the OS designers provided an easy way for you to review and work with the security settings.  This is by using the “Work with System Values” command (WRKSYSVAL) with the “System value” (SYSVAL) parameter set to the special value of *SEC.  Like this:


Setting the OUTPUT parameter to *PRINT will produce a listing of the security system values for you.  Or, you can just run the command with the OUTPUT parameter blank and the system will bring the security system values up for you to review.  A similar review function is available from iSeries Navigator, but the security functions are spread out over several different selection tabs (at least on my version) and you have to go several places to find everything that is available from the single *SEC review ability of the WRKSYSVAL command.

When working with the values interactively, you can review the current setting using option 5 or you can change the value using option 2.  The list of system values displayed shows the name of the value and a text description.  Often, this is not enough information for you to determine exactly what you’re looking at.  When I find myself in this situation, I put a 5 next to it, then position the cursor over the current value displayed and press the HELP (or F1) key.  The help text that comes with this command is quite comprehensive and very helpful.

Changing any of your security system values should not be done on a whim.  Planning and preparation are the watchwords for this process.  It is all too easy to shoot yourself in the foot by making a security change in the fly and then losing, for example, the ability to log into your system.  All security changes should be researched in advance to determine the exact impact on your system.  If you’re not sure, do the work to find out rather than just trying it out without knowing the impact.

Once you have your security system values set along with the other system values (and there are loads of them), it is a good idea to lock them in place.  On too many systems, there are just too many users with all object (*ALLOBJ) and security administrator (*SECADM) permissions in their user profiles.  By locking the system values, this will prevent casual changes to the system values and thereby preserve the security policies that you’ve designed and implemented.

To lock your security system values in place, you can use the System Service Tools.  To lock the settings, start up the System Service Tools from a display session using the Start System Service Tools (STRSST) command.  You will need to supply your service tools user ID and password to complete the start of the tools.  Once started, choose option #7 from the menu (Work with system security).  Then, from the next screen, use option 2 to lock the security system values in place.

Once these are locked in place, you can only unlock them to make changes by first going back into the System Service Tools and unlocking them from the same screen where you locked them.  The unlock option is done by entering option 1.  These settings can also be manipulated during IPL time by running the Dedicated System Tools (DST).  Once locked, even users with *SECADM or *ALLOBJ cannot make capricious changes to the security system values so your security policy decisions will remain in force without worry.

If you have any questions about this topic you can reach me at (rich at kisco dot com),  I’ll try to answer any questions you may have.  All email messages will be answered.

Watch Your System Values

By Rich Loeber

Since the system values control how your system works, it is important that they be set correctly and that you know what those settings are.

When we installed a new IBM i server in our office, it was an exciting time and we normally rush to get the system set up so we can move operations onto the new hardware as soon as possible.  Since we do this kind of changeover infrequently (this was our 4th system since 1988), we are not really what you consider to be experts in this field.

We got our new system up and running and then unplugged our venerable, now antique, server.  We found that some things seemed to be working differently.  It took us a little while to sort it out, but some of the issues we were having could be traced back to the fact that several system values were now set up differently from our old system.  And, to our dismay, the old server was now on a truck on its way back to the leasing company.  So, we were left to sift through the system value listing and see if we could remember what our old system was configured for and get it reset.  Shame on us, we should have thought about this before releasing our former system.

I’m sure that we are not alone with this problem.  In fact, system values are so critical to how a system behaves, that having a current inventory of their authorized settings should be an  important part of your security plan.

The easy way out of this is to just run a complete listing of the current system values using the Work with System Value (WRKSYSVAL) command.  If you prompt this command, there is an output parameter that will allow you to run a complete listing to a print spool file.  This report will show you all of the system values on your system along with the current value,  the value as it was shipped from the factory and a description of the value.  Then, just print the simple 3 page report and keep it in an active file.  While you’re at it, take a look at those values that are different from the factory defaults on your system and make sure you understand why the changes have been made.  Those system values that are different are identified by a > character on the report between the system value and the current value setting.

If you’re like me, however, it would be nice if you could automate this process, even just a little.  One way to help with this is to keep the report in a physical file on your system.  You could create a separate member for each day when you run the report and then see if system values are changing.  I set this up on my system by creating a simple physical file in library QUSRSYS named QSYSVALUES using the following command:


Then, run the report with the output going to an output queue that will not print right away.  You can do this with the following command:


Lastly, save the report in your database file with the following command:


In this case, the member name gives the year, month and date when the values were stored (May 17, 2013).

If you set this up to run once a month, you can then build up a collection of system value reports that you can check against each other.  This will help you to know that the values are not changing over time and, if they are changing, get you started on back tracking as to when they got changed.  If you’re feeling adventurous, you could even create some database query programming to check for changes from one member to the next.

System values are critical to how your system works.  Keeping them under control will keep your system running smoothly.

If you have any questions about this topic you can reach me at (rich at kisco dot com),  I’ll try to answer any questions you may have.  All email messages will be answered.

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 @ kisco.com.  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 kisco.com).

Checking Up On Your Security Policy

By Rich Loeber

As an IBM i security officer, you’ve spent a lot of time doing two main tasks.  First, establishing a security policy, and second, setting your system up to enforce that policy.  Once you have these two tasks done, then you can sit back and relax …. right?  Not really.  In the real world, you have business changes to assess against your security policy, you have new technology to evaluate and determine changes in policy that might result from their implementation and the list goes on.

But, what about all that hard word you did to get your initial security policy implemented?

I have found during my career that things have a way of changing over time.  A sort of entropy in the digital world.  A security implementation that was perfect once, deteriorates over time unless you give it some attention.  I found this out on my own server recently when going through the process of moving to a new system.  Some of the security setup for specific objects had changed between when they were set up several years ago and when I went to do the migration.  I’ve traced some of it to programmers (ie: me) who updated file descriptions without enforcing the right security settings.  I’m sure there are other ways this happens too, such as file restores that change security authorizations and object ownership.

Ideally, it would be good for you to go over your entire security implementation periodically to make sure that it is still set up the way you initially designed it.  If you recall the process, however, this could be a significant investment in time.

A better solution is to just use existing Security Tools reports to create listings on your system of how the security is currently set up.  Scanning a report for items that stand out as different from the others is a lot easier than going back and examining every object to see how it is set up.

The IBM i has quite a few security reports that you can run from the Security Tools menu (SECTOOLS).  Option #20 will get you to the Security Reports menu (SECBATCH).  Different options on the menu will produce different reports, many of them very useful when scanning for security implementation entropy.  Each of these options prompts for a Submit Job command so that the reports run in batch.  Pressing the F4 key from the Submit Job command line will let you review and change parameters.

In the case of the problem that I found on my system, I ran option #11 and then prompted the command to limit the report to a specific library that I needed to check.  In my case, I found several objects that should have been secured by an authorization list, but they were only being secured by object authority.

When you get some extra time, take a look through these reports and start running them to see what you find.  Chances are very good that you’ll uncover some issues before too long.

If you have any questions about this topic you can reach me at (rich at kisco.com),  I’ll try to answer any questions you may have.  All email messages will be answered.

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 kisco.com),  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 kisco.com) 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 (rich@kisco.com), 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.