Step 6. Security Providers

In this section:

How to:

The default security provider for a new installation is the internal security provider, PTH. The PTH provider implements security using user IDs, passwords, and group memberships stored in the admin.cfg configuration file.

After the initial installation, the Server Administrator that was configured during the installation can start the server and use the Web Console to further customize security settings, for example, to configure alternate or additional security providers, create additional PTH IDs, and register groups and users in a security role. For more information about security providers, see the Server Security chapter in the Server Administration manual.



x
Procedure: How to Satisfy Security Provider OPSYS Requirements

To run a server with security provider OPSYS in IBM i, you must satisfy the following requirements. You must do this once after installing and after each refreshing of the server with fixes.

Certain files must be owned and run under the QSECOFR profile or a QSECOFR-authorized ID (such as iserver) that allows impersonation for the OPSYS security mode. Running with security mode OPSYS requires users to send a password to connect to the server, or to use some other form of verification. Although general installation of the server software is done by iadmin (an ordinary user ID), this step requires QSECOFR authority.

To change ownerships, do the following:

  1. Log on as QSECOFR.
  2. Using the library specified during the installation, change the file ownership by entering the following commands:
    CHGPGM PGM(SRV77/TSCOM300) USRPRF(*OWNER)
    CHGOBJOWN OBJ(SRV77/TSCOM300) OBJTYPE(*PGM) NEWOWN(QSECOFR)

The CHGPGM and CHGOBJOWN steps will need to be repeated after any server upgrade since the tscom300.out file is replaced during upgrade and the attributes are lost.

Note: If this Security Provider OPSYS step has been done and the site later decides to switch to Security OFF, then special steps must be done to ensure the mode remains after a full server shutdown, where edastart -start is used to restart the server.

After the server recycles from the change to OFF, use the Web Console to open the environment configuration file of the server. Select Workspace, Configuration Files, Miscellaneous, and then select Environment -edaenv. Next, double-click to edit, add the variable EDAEXTSEC=OFF, and then save.

After the next full server shutdown, be sure to do an edastart -cleardir before restarting the server. This will clear any root owned files that would prevent a security OFF server from starting.


Top of page

x
Preventing Unsecured Server Starts After Upgrades

If the explicit environment variable EDAEXTSEC is set to OPSYS (or ON) and the server cannot impersonate users because it lacks platform-specific authorization steps, the server start aborts and error messages are written to the edaprint log.

This feature prevents an unsecured server start after a software upgrade if any of the required post-upgrade reauthorization steps are missed on a UNIX, IBM i, or z/OS HFS deployment. This is not applicable to other platforms. The setting may be placed in any normal server start-up shell or profile that a site is using or in the server edaenv.cfg configuration file. The messages vary slightly by platform.

The edaprint messages are:

Configured security is 'ON' as set by EDAEXTSEC variable.
TSCOM300.PGM has no QSECOFR authority.
Workspace initialization aborted.
(EDA13171) UNABLE TO START SERVER

iWay Software