Kisco Systems

IBM i Security Tips

Home : Blog : Watch Out When Restoring User Profiles

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.