When you upgrade the IBM i OS from one release level to the next, such as moving from 7.2 to 7.3, you should take the following steps to help make sure that iResetMe works correctly:
CRTDUPOBJ OBJ(QZHBCGI) FROMLIB(QHTTPSVR) OBJTYPE(*SRVPGM) TOLIB(IRMLIB)
A best practice for IBM i security when someone leaves your organization is to disable their user profile and then set the password to *NONE. But, that can be overcome using iResetMe if someone tries to do a reset. iResetMe would expect it to be set to *DISABLED and would just go ahead and do a password reset. Since there is an optional new password, then there is a way to get around that.
We recommend that they simply be deleted from iResetMe as a part of your normal process when someone's user profile is deactivated. In fact, it should be the first step in the process.
Note: If you have installed iResetMe release level 3.15 or later, then changing the user profile's password to *NONE will lock the user out of iResetMe for profile reset purposes.
In the same way that you cannot find out someone else's password on the IBM i, iResetMe keeps the challenge response replies secret as well. In fact, to insure that, we strongly recommend that you take the extra step of configuring iResetMe to keep these values encrypted on your system. This is an option on the IRMSET command which is option #9 on the INSTALL menu.
Some systems come from IBM without the Local Certificate Authority in the *SYSTEM store. This needs to be created before you can complete the iResetMe process for creating the digital certificate needed for the application. Here is a link to an IBM procedure for creating the Local Certificate Authority if it is not already on your system:
Some systems come from IBM without the *SYSTEM certificate store. This store needs to be created before you can complete the iResetMe process for creating the digital certificate needed for the application. Here is a link to an IBM procedure for creating the *SYSTEM store if it is not already on your system:
Yes, but we do not recommend this for security reasons. Without the digital certificate, user profiles and passwords will get passed through your network as open text and there is a risk of abuse. If all of your users are coming to iResetMe from within your network which is protected by a firewall, you might want to consider this option, but keep in mind the risk involved.
There are two things that you will need to change on your system after iResetMe has been fully installed. One is a setting in the IRMSET control settings (option #9 on the INSTALL menu). The other is a setting in the Apache HTTP server instance named IRESETME. Before making this change, make sure that all parts of the iResetMe installation process have been completed except for the digital certificate requirement.
The change in the IRMSET is found in the HTTPS parameter (iResetMe Browser Address). The documentation for iResetMe specifies that this entry be coded to start with the value "https". To run without the digital certificate requirement, this parameter must start with "http". See the iResetMe documentation for more details about setting this parameter correctly.
The change to the Apache HTTP server can be done as follows:
At this point, your iResetMe HTTP server instance should work without the requirement for a digital certificate. Your link to the application in your browser should now start with HTTP rather than HTTPS as indicated in the product documentation.
When using mirroring software to keep your DR system current, we recommend that you update the software for iResetMe directly on both systems. For mirroring purposes, your mirroring software should exclude all objects from the iResetMe application library (IRMLIB) with the exception of the following *FILE objects:
You should also add the following specific data areas for replication (*DTAARA objects):
A customer who set this up successfully wisely recommends that you set up the *FILE objects on your target system as "read only" (share *NO) to avoid having direct updates made there. If you need to do a failover, these files can then be changed back to allow direct updates if needed during the failover. You should make that a part of your failover process.
The graphic that is shown at the top of each page in an iResetMe browser session is stored in the IFS. It is named header.gif and you will find it in the IFS path /www/iresetme/htdocs. If you chose to to replace this graphic with one that has your own information and logo, make sure that your graphic is also in GIF format and has the dimensions of 600x50 pixels.
We recommend that you keep a copy of the current header.gif under a different name. Also, make sure that you have a copy of your custom graphic file stored elsewhere. When Kisco Information Systems send out software updated, the header.gif file could easily get replaced with our version of the file. In that case, it is the customer's responsibility to re-install their own custom file.
Yes.... and no.
Kisco does not recommend using iResetMe for the high powered Q profiles from IBM. When you use the automatic batch enrollment command to enroll active profiles, all Q profiles will be skipped, even if they are active. You can, however, manually enroll a Q profile using option #1 on the MASTER menu if absolutely necessary.
Also, keep in mind that iResetMe will only allow you to register user profiles that are active. If a profile has been disabled, it cannot be registered until it has been reactivated with a current valid password.
As of release level 2.06, iResetMe can be user configured to work with any language, including English. The product is shipped with an English implementation, but the customer can customize the text used in the browser panels so that any language can be user implemented.
With changes implemented since release level 2.06, iResetMe comes with built-in support for English, Spanish and French speaking end users.
iResetMe can be ordered for varying levels of user profiles. Licenses are available for up to 25 users, 50 users, 100 users and unlimited users. When doing an estimate of the number of profiles to include, count the number of user profiles on your system excluding any profiles that start with the letter Q. You should also exclude profiles that are showing as *DISABLED. The resulting number should be a good estimate for the size of the license you will need.
As of release 1.06 of iResetMe, there is now an encryption option. For those customers who are concerned about security, the option will cause iResetMe to maintain the challenge question responses in encrypted form on the system.
The software comes with ten standard personal questions that you can get started with. When a user registers, they choose which questions they want to answer from the list of those available. There is also a facility in the software to add more questions. The number of questions that need to be use is variable and set globally in the software. The current range in from 1 to 5 questions.
Passwords are accepted via the encrypted HTTPS server session and processed by iResetMe for validation purposes only. This validation process uses standard IBM i API program calls to perform a one-way password check. As soon as a password has been validated, it is deleted from storage so that even a memory dump would not reveal any password information.
The initial release of iResetMe only worked with 10 character passwords on IBM i. This corresponds to system password levels 0 (zero) and 1 (one) which is how most current IBM i systems are implemented. As of Release level 1.01, all password levels are supported.