The following is a list of frequently asked questions about SafeNet/i. If you have a question thatis not covered here, ask us via E-mail Support and we'll answer your question.
We have examined all Apache based applications from Kisco and determined that they are not affected by this security exposure. For our products, you do not need to make any changes or apply any patches or PTFs that may become available from IBM, Java or Apache.
We encourage you to check other services on your system that are using the Apache web server to make sure that they are not at risk. Here is a good article about it on your IBM i system.
We often hear this question as a result of audit activities. In a word, the answer is No.
All of the objects in the SafeNet/i libraries are owned by this profile and the program objects run under adopted authority tied to the profile. Many of the programs access system functions in different libraries and removing the *ALLOBJ special authority can cause those functions to fail with adverse results for your system and its users.
We recommend that after you get SafeNet/i installed, that you go back to this user profile and change it so that the password is set to *NONE and the status is changed to *DISABLED. Once these changes have been made, then the profile is secure from possible abuse.
When you first install SafeNet/i Release 11.08 or higher, the new Socket exit points will be exlcuded from SafeNet/i processing. This applies if you are a new customer or if you upgraded to SafeNet/i 11.08 or higher from any level of Release 10 or earlier. The socket exit points monitor all TCP/IP socket Accept, Connect and Listen connections. On some customer systems, there are a very high number of these transactions that can adversely affect system overall performance. For this reason, we have chosen to make using these exit points entirely optional on the customer's part.
To activate one or more of the Socket exit points, use the following instructions:
Exit point TCP Accept socket connectionsYou will see that the three points in question already have an X in the Exclude code.
Exit point for sockets connect() API
Exit point for sockets Listen() API
If it becomes necessary to have SafeNet/i exclude the exit point that has been activated, you can do so by following the exact same procedure as above EXCEPT that at step #3, change the Exclude code back to X. When you make this change, the exit point registration will be removed.
When an installation has a user exit program in place that SafeNet/i does not recognize, the exit point will automatically be set to Level 5 (unsupported). To allow SafeNet/i to support this server you must do the following:
Type WRKREGINF and press ENTERYou may have several servers set to Level 5. You must remove each one. Then, using the DSPNETA or CHGNETA command, verify that your IBM i network attributes DDMACC and PCSACC are both set to *OBJAUT. If these attributes are not initially set to *OBJAUT, SafeNet/i will flag several exit points to Level 5.
Locate the exit point and remove your exit program.
Important: Do not remove any program called from PCSECLIB.
CALL PCSECLIB/DELST5CL and press ENTER
Press F3 to exit without making any changes
From the Install Menu select Option 50 - Activate/De-Activate SafeNet/i
Follow the instructions to de-activate the program found in Chapter 13 in this guide, ‘De-activating and Removing SafeNet/i’.
Select Option 50 - Activate/De-Activate SafeNet/i
We recently heard from a customer who had an auditor request to remove *SECADM special authority from the SAFENET user profile. In the SafeNet/i documentation, we have always recommended that the SAFENET profile be set up with all special authorities, including *SECADM. After extensive testing at OS level V5R4, we have determined that *SECADM can be removed.
Keep in mind that the SAFENET profile does not need to be active with a password and can even be set to *DISABLED status. These aspects should appeal to your auditors. Now, if specifically requested, we also believe that you can remove the *SECADM special authority in response to an audit request.
With a recent PTF for SafeNet/i Release 9, you can now use a numeric email address in the Alert Notification list. Prior to Release level 9.09, this was not allowed on the CHGNOTIFY command.
To send a text Altert Notification, you just need to identify the carrier of the target cell phone, then form an email notification address according to the form called for by the carrier. Here are the five most common cell carrier formats available at the time this was written:
Virgin Mobile: email@example.com
As an example, if your carrier is Verizon and your cell phone is 5185551212, then the entry you should use in the CHGNOTIFY command is: firstname.lastname@example.org
A customer who has been using SafeNet/i for a long time on multiple systems recently ran into a performance issue on several of their production servers that were carrying a heavy workload. After exhaustive analysis, they discovered that a fairly simple change to the logical file configuration for several files used in their application software would relieve the performance bottleneck. In the process of their testing, they identified a logical file in SafeNet/i that is frequently used that would also benefit from the change.
If you feel that your installation might benefit from this change, then we recommend that you consider it. The logical file concerned is named PCACCEL2 and resides in the library named PCSECDTA. Since this file is referenced by a lot of servers on your system when SafeNet/i is active, you will probably have to schedule the configuration change so that it takes place when your system is in restricted state.
When the file is available, as when you have brought your system to restricted state, just run the following command from the command line while signed on as a security officer:
CHGLF FILE(PCSECDTA/PCACCEL2) ACCPTHSIZ(*MAX1TB)
Once this change has been made, you can then resume normal processing. You do not have to deactivate SafeNet/i when making this change.
These two libraries are created during version upgrade installation processing. Once you have installed an upgrade and you are happy with how it is working, then these can both be removed. They would only be needed if you had to revert back to the prior release following a version upgrade.
We recommend that you keep these two libraries on your system for a period of at least two weeks following a version upgrade to your SafeNet/i software.
The TRAPOD file is the live transaction history file used daily in SafeNet/400. This file must be kept on the system with an active member.
The correct way to reduce the size of the TRAPOD file is to use the purge option that you will find on the SN2 menu in library PCSECLIB (the STRPRGARC command).
The TRAPARCW file is a multiple member file that contains previously archived transaction history file records. When you run the purge, there is an option to archive the purged records. When you use this option, the archived records are stored in this file in a newly created member. If you want to save these transaction records for historical purposes, you should back the file up off-line. Once you have them saved, then the correct way to reduce the size of the TRAPARCW file is to remove the individual members.
Several customers have asked this question when they want to keep their system-wide implementation of SafeNet/400 at a specific release level that is no longer available from Kisco Information Systems.
You can install SafeNet/400 from a backup from your production system provided that the system is in restricted state and SafeNet/400 is deactivated when the backup is taken. Both libraries, PCSECLIB and PCSECDTA must be saved. If this precaution is not followed, some objects may not be saved correctly on the backup tape. Since this may be a significant inconvenience for a normal backup process, you might consider keeping a copy of SafeNet/400 that has been saved this way available for off-site use. This backup copy should be refreshed whenever a significant number of access rules have been changed or when Kisco PTFs have been installed.
We recommend that you test your backup plan to make sure that all objects are correctly saved to your backup tape. Note: Your backup of the SafeNet/400 libraries (PCSECLIB and PCSECDTA) must be made using the SAVLIB command.
To install SafeNet/400 at your new site, do the following:
You are now in a position to activate SafeNet/400 so that it is current on this new system. Be sure to check with Kisco Information Systems about your license status on this new machine and to arrange for your permanent installation codes.
You must be running a minimum SafeNet/400 Release level of 8.21.
We have tested Nav-Central Version 8.0 with MSVista and it works just fine. We have not tested earlier releases of Nav-Central with MSVista, but we suspect that it will work there as well. We recommend that you do a fresh installation and not rely on copied files from your older MS OS system.
There are three ways to deal with an object access request the references the object's library with the *USRLIBL reference. SafeNet/400 does not check for all libraries in the job's library list as to do so could severely impact processing efficiency for your network application. Please review these three alternatives and choose the one that works best for you. They are presented in the sequence of recommended preference:
We have seen this happen when the SAFELOGING subsystem is shut down and then not restarted in a timely manner. When you shut down SAFELOGING, SafeNet/400 does NOT stop working, it just stops recording the results in the Transaction History log. The results are stored temporarily in a data queue named SAFEQ. The only problem with this is that data queues have a finite size constraint and can fill up. When the SAFEQ data queue fills up, then SafeNet/400 senses it, issues the error message that you saw about the SERIOUS error, and then tries to start the SAFELOGING subsystem and job to relieve the pressure on the SAFEQ data queue. The problem is that on some systems there can be a huge number of transactions that cause it to issue this error. In each instance, a job is sent to the job queue. Sometimes it can take a long time for the job to get started and all those jobs get queued to the job queue.
The first question you need to concern yourself with is how SAFELOGING got shut down. For some customers that we have seen, this can happen when a backup is run that fails before normal completion. We recommend that the SAFELOGING system be stopped during a backup and then restarted as soon as the backup is done. If something happens to the backup, then the restart can get cancelled along with the backup and you're in the soup. Other times, users have shut down SAFELOGING thinking they were turning SafeNet/400 off, but this is not the case.
To recover from this situation, you first need to make sure that the SAFELOGING subsystem is up and running. Use the command "WRKACTJOB SBS(SAFELOGING)" and verify that there is at least one job running in the subsystem. If it is not running, you can start it using option #11 from the SN2 menu in library PCSECLIB. Once it is up and running, then you need to clear the pending jobs in the SAFENET job queue.
During installation processing, the current complete contents of the SafeNet/400 application library named PCSECLIB are saved in a save file object. A backup library is created named PCSECOLD and the name of the save file that contains the entire library contents is SAVF. If you want to restore any of these objects, you can do so with a simple RSTOBJ command.
Warning: We warn you, however, to check with us before arbitrarily restoring any objects from an earlier release of SafeNet/400. Some of these objects could create instability if restored to the new release. Contact Kisco Information Systems support staff for advice on your specific situation.
If you have stored any objects, or modified objects in the SafeNet/400 data objects library named PCSECDTA, this library is also preserved during a release upgrade. The prior version of this library will be found in a backup library named PCSECOLDD. Again, review the previous warning when attempting to restore any objects from this backup library.
If you have only loaded Release 7 in logging mode and have not created any access rules, then this is an option you might want to consider. If you have rules already set up and your servers are locked down, DO NOT CONSIDER THIS OPTION as it will create a lot more work to re-enter all of your rules.
To uninstall SafeNet/400 Release 7, remove it, and then install SafeNet/400 Release 8 as a new installation, please do the following:
In a word - No!
The SAFEQ data queue is used to temorarily hold the results of SafeNet/400 security tests that are on their way to the SafeNet/400 transaction history file. If you have a period of time on your system when there is transaction history and the SAFELOGING subsystem is not active, then the data queue size will continue to build until the SAFELOGING system is started and data is transferred from the data queue over to the history file. The problem is that the way OS/400 and i5/OS deal with data queues, they never shrink in size and will stay at their largest size used.
In SafeNet/400, we provide a procedure for deleting and rebuilding the data queue. This is used when the data queue has become damaged, but it can also be used to force the data queue back to its original size. We recommend that you do this at a time when there is little or no network transaction activity on your system as there could be an error issued if a transaction is processed while the data queue is being rebuilt.
To rebuild the SAFEQ data queue, signon to a terminal session as a Security Officer and then issue the following command:
CALL PGM(PCSECLIB/BLDSAFEQ)When the program runs, the SAFELOGING subsystem will be temporarily ended, the data queue will be deleted and then rebuilt using the correct parameters for your version of SafeNet/400. When the data queue has been rebuilt, then the SAFELOGING system will be restarted.
Based on a customer request, we contacted IBM about this question. It turns out that "environment" FTP commands (BIN, NAMEFMT, TIME, etc.) DO NOT get passed to the OS/400 exit point. Only FTP operations (RCMD, GET PUT CD, etc) get passed and logged. Since these commands are never passed to the exit point by OS/400, SafeNet/400 never sees them and, consequently, cannot log them. Only those commands that have security implications are passed.
If you are using replication or mirroring software, you MUST exclude all objects in libraries PCSECLIB and PCSECJRN from replication processing. Also, you must exclude all objects in library PCSECDTA with the exception of the files listed below.
To duplicate the rules that have been set up on one machine for use on a backup system, you must transfer several physical files from library PCSECDTA. Use the following list of files to set up your replication process:
V5R2 no longer supports the Work Station Gateway (WSG) server. Since you are getting this error spool file, then a record for this server still exists in your version of the SafeNet/400 control files.
The procedure to correct for this manually is to do two file updates. One update will be for the file named SUPREGPF and the other for the active file WRKREGPF. Both files are in library PCSECDTA and you can use the UPDDTA command to do the update.
For the SUPREGPF file, locate the record with the following two key elements:
QIBM_QTMT_WSGWhen the record is displayed, press the F23 key twice to delete the record. To confirm that you have the right record, the display will look as follows before you do the deletion:
WORK WITH DATA IN A FILE Mode . . . . : CHANGE
Format . . . . : SUPRFT File . . . . : SUPREGPFSV
For the WRKREGPF file, the key values for the record update are the same:
QIBM_QTMT_WSGTo confirm that you have the right record for this one, the screen will appear as follows:
WORK WITH DATA IN A FILE Mode . . . . : CHANGE
Format . . . . : WRKRFT File . . . . : WRKREGPF
WMSGTX: WSG Server Sign-On Validation
As with the first file, just press the F23 key twice to delete this record.
To confirm that this corrects the problem, run option #1 on the SN1 menu again at this point and see if you get a fresh copy of the spool file error message.
First, you must contact Kisco Information Systems and advise us that you are transferring your software from one system to another system. We will need to provide you with a new permanent installation code for your new system. We require that you notify us in writing, on your company letterhead or from your company email address, that you are moving the product from one system to a new system. The serial numbers for both your old and new systems must be included. You can fax or email this notification to us at our fax number: 518-897-5003 or by email to email@example.com. When we get your transfer request, we will issue a new installation code for your new system and will note in our records that you are retiring the software from your current system.
To transfer the software, you must first get a clean backup of your installed product. The only way to guarantee a safe backup is to do the following:
To activate the software, bring your new system to a restricted state. Once the system enters restricted state, go to the INSTALL menu in library PCSECLIB and run option #50 (option #6 on the SN2 menu for earlier releases). After the product has been activated, go to the SN1 menu and run option #1. Review the exit point status for points set to level 5. If any are set to level 5, check with your documentation for instructions or contact our technical support specialist for additional information. To resume normal processing, start your controlling subsystem.
To use E-mail alerts, first the AS/400 must be configured for e-mail. (SafeNet/400 is not an Email product, so we will not support setting this up for customers, but IBM has some very good documentation in their TCP/IP quick configuration guides to help you with this.) Remember, for this option to work, your QSNADS subsystem must be active and running. Then you need to create a distribution list.
First, use the WRKDIRE command and check to make sure that the special user profile SAFENET has been enrolled in the system directory. If you don't see it there, add it taking the standard default values.
The distribution list must always be qualified with the system name, for example
CRTDSTL LSTID(SAFE2 KISCO) LSTD('Safenet Alerts')The second part of the distribution list name must be the system name. In the above example, KISCO is our system name. If you are unsure of this value, use the DSPNETA command on your system to display your system name.
Once the distribution list has been created, add all the entries for mail recipients using the ADDDSTLE command. Then, turn on alert notification, (menu option #7 on the SN2 menu or the SafeNet/400 command CHGNOTIFY), turn on the email option and specify the name of the distribution list. Be sure that you only specify your distribution list. Do not mix distribution lists and user profiles. If you want to continue to send notification messages to user profiles, include them in the distribution list. When this is done, the alert notifications will be sent via Email.
If you have this all set up and it does not appear to be working, use the SNDDST command to manually send a message to your distribtution list. This will test your SMTP configuration. If this fails, then the problem lies in your SMTP setup. If this works, but you are still not getting messages from SafeNet/400, check the joblog for the job running in the SAFELOGING subsystem to see if there are additional error messages showing there.
The default settings for the FTP Summary report call for all transactions on the file to be selected. The program defaults to a selection date range of 1/1/1990 to 12/31/2010. These are the date that are displayed on the report in YYMMDD format.
When SafeNet/400 purges records from the transaction history file (TRAPOD), it stores them in a new member in the Archive File. This file is named TRAPARCW. Each purge operation results in a new member being added to this file.
To purge this file, use the SAVOBJ command to save the members from the file to tape. Then, you can delete the members that you have saved from the file. If you so desire, all members can be deleted from this file but the file itself should not be deleted.
Use the install media received from Kisco to load the library named PCSECINST to your local system. Check the upgrade instructions that you received. Using "Method B", choose one of the restore instructions documented at step 3 (steps 4, 5 or 6 if you are using the on-line instructions found at http://www.kisco.com/safenet/support/snrelupg.htm). Using SNADS, or any other method that you have for moving libraries to another system, transfer the PCSECINST library to the remote system where you want to perform the SafeNet/400 release upgrade.
Once the library is on your remote system, resume the instructions for "Method B" at step number 4 (or step 7 if you are referring to the on-line instructions). Once those instructions are complete, the upgrade will install automatically the next time the remote system is IPL'd.
When you install PTF's to SafeNet/400, the replaced objects are moved to this newly created library. The library is assigned the same name as the PTF package name. These objects could be used to restore your system to it's pre-PTF state if that becomes necessary. Under normal conditions, you should be able to delete these libraries once the PTF has been installed and tested to your satisfaction.
SafeNet/400 only allows maintenance on IBM user profiles (those starting with the letter Q) when you are signed on using the QSECOFR user profile. Sign off under your current profile, then sign back on using the QSECOFR profile. If your installation has strict control over the use of QSECOFR, you may have to arrange for your installation security officer to handle this task.
Since SafeNet/400 uses IBM's exit point technology to protect your system, it is integrated into OS/400 and in normal operation it regularly has files and programs in use. This can create a problem when trying to take a backup of the library. To overcome this problem, we recommend that you keep a separate backup of the library named PCSECLIB and only save it when product PTFs or updates have been installed. To get a safe backup of PCSECLIB, your system should be in restricted state. For the data library named PCSECDTA, we recommend the following sequence. (Note, all commands referred to in this procedure are with OS/400 commands or can be found in the SafeNet/400 library.)
You may install SafeNet/400 from a backup from your production system provided that SafeNet/400 the SAFELOGING subsystem is ended when the backup is taken. Both libraries, PCSECLIB and PCSECDTA must be saved. If this precaution is not followed, some objects may not be saved correctly on the backup tape. Since this may be a significant inconvenience for a normal backup process, you might consider keeping a copy of SafeNet/400 that has been saved this way available for off-site use. This backup copy should be refreshed whenever a significant number of access rules have been changed or when Kisco PTFs have been installed.
We recommend that you test your backup plan to make sure that all objects are correctly saved to your backup tape. You should not rely on an untested recovery plan. Note: Your backup of the SafeNet/400 libraries (PCSECLIB and PCSECDTA) must be made using the SAVLIB command.
To install SafeNet/400 at your recovery site, do the following:
Remember that SafeNet/400 registers exit points in OS/400. Before leaving your backup site, you should deactivate SafeNet/400 and remove the library.
SafeNet/400 is integrated into OS/400 via IBM's exit point technology. Because of this, you must take some special steps with SafeNet/400 when upgrading your level of OS/400.
Repeated appearance of this message indicates that your trial of SafeNet/400 has expired. If you have already paid for SafeNet/400, all you need to do is apply the permanent installation password provided to you by Kisco Information Systems and the messages will stop appearing. If you have not paid, you have two options:
The install tape that you have contains observable code and can be installed on either a CISC or a RISC system. With that in mind, here is our recommendation for moving SafeNet/400 from CISC to RISC.
At this point, SafeNet/400 will be successfully installed on your new RISC system.
SafeNet/400 can be installed on any computer using the original installation tape. When you do the install, SafeNet/400 will be activated for a normal 30 day trial period. During this period, you must contact Kisco Information Systems to work out the licensing arrangements for your backup system.
Once the software is installed, you will want to bring your custom configuration rules forward from your normal production system. You can do this by transferring the library named PCSECDTA from your system. Before saving this library on your production system, you should shut down the logging function (option #12 on the SN2 menu). When the library has been saved, remember to resume logging (option #11 on the SN2 menu). This library should now be restored to your test system. This will preserve the settings and rules.
Finally, if your system license covers more than 25 users, you will have to contact us for a trial installation password that will support your level of users. We will gladly issue a temporary code immediately and work out the licensing arrangements at a later time. If you have the basic system installed, this is not an issue.
This can be done using the following steps:
RSTLIB SAVLIB(PCSECINST) DEV(xxxx)
RNMOBJ OBJ(QSYS/PCSECINST) OBJTYPE(*LIB) NEWOBJ(PCSECLIB)
RSTLIB SAVLIB(PCSECDTAIN) DEV(*SAVF) +
SAVF(PCSECLIB/PCSECDTA) MBROPT(*ALL) +
Yes. Since its initial introduction, SafeNet/400 has always been Year-2000 Compliant.
Kisco will give you permission to make as many copies of SafeNet/400 for installation on other systems as you need. Each of these installable tapes can then be installed on a trial basis on whatever machines you want to use.
Here are the steps you need to take to create an installable tape for SafeNet/400.
CRTDUPOBJ OBJ(QINSTAPP) FROMLIB(PCSECLIB) +
SAVOBJ OBJ(QINSTAPP) LIB(QTEMP) DEV(xxxx) +
Where xxxx=tape device name and youroption=the lowest target level that the tape will be used for installation purposes.
SAVLIB LIB(PCSECINST) DEV(xxxx) ENDOPT(*UNLOAD) +
At this point, you will have an installable tape that you can use on any of your systems. To do the install, you can use the installation procedure from the SafeNet/400 user's guide. When you are all done, you can delete the PCSECINST library from your system.
Note: This answer only applies to SafeNet/400 Release 2 and earlier.
SafeNet/400 records log information in a file named TRAPOD in our application library named PCSECLIB. Option#4 on the Special Jobs menu (menu name SN2) can be used to purge these records.
You can also embed a call to the purge program from within your own CL program. The program is named TRAPDL1CL and requires two parameters. Use the following call example as a guide:
CALL PGM(PCSECLIB/TRAPDL1CL) PARM("0" "19980115")
The first parameter must always be zero. The second parameter must be the purge day in form YYYYMMDD. In the example shown here, all records on the file prior to January 15, 1998 will be purged from the file.
Note: This answer only applies to SafeNet/400 Release 2 and earlier.
The SafeNet/400 Security Report by user will print all requests logged by SafeNet/400. Selecting menu option 6 from the Reports menu (menu SN3) will produce this report.
You can also call the reports program directly. The program is named TRAPOD1CL and it has 8 parameters. The parameters are defined as follows:
The following is an example of a CL call to this program:
CALL PGM(PCSECLIB/TRAPOD1CL) PARM("0" "D" "*ALL" "01011998" "01151998" "08150000" "N" " ")
In this example, entries will be listed by user within date for all users starting at 8:15am on January 1, 1998 through January 15, 1998.
Note: This answer only applies to SafeNet/400 Release 2 and earlier.
SafeNet/400 provides protection from ODBC users when you use the IBM ODBC driver that is included in OS/400. There are other ODBC drivers on the market and SafeNet/400 will not give you protection when these are used. These other drivers do not conform to the exit point requirement that is found with the IBM ODBC driver. If you need protection, you must use the IBM provided ODBC driver.
Non-IBM ODBC drivers can easily be excluded on your system. All of these drivers require that you load a software component onto your AS/400. You can prevent use of non-IBM ODBC drivers by simply not loading their AS/400 software component. This will force your users to conform to the standard ODBC driver from IBM.
SafeNet/400 requires an IPL of your AS/400 just prior to installation. You may also need to obtain PTFs from IBM (see link on customer support page) for your current level of OS/400. The PTF process also requires an IPL. For installations that are running critical operations on a 24 hours per day/seven days a week basis, this can be difficult. If this is your situation, you can eliminate one of these two IPLs by using the following installation sequence: