1.2 Platform Services Installation Procedure

The general steps for installing Platform Services for z/OS are

  1. Create the Platform object for your z/OS platform. For details, see the Core Driver Administration Guide.

  2. Obtain and set up the distribution files.

  3. Install the Platform Services Process.

  4. Install and configure the System Intercept.

  5. Install the Platform Receiver.

  6. Customize the Receiver scripts.

  7. Integrate Platform Services into your routine operation.

1.2.1 Obtaining and Setting Up the Distribution Files

  1. Obtain the Platform Services for z/OS distribution files.

    For details, see Section 1.3, Obtaining Platform Services for z/OS Files.

  2. Add the Platform Services Load Library to the APF list for your system.

    Use SYS1.PARMLIB member IEAAPF00 or PROG00 as appropriate. If you are using the dynamic APF facility, you can add the Platform Services Load Library to the active APF list immediately and use the console SET PROG command to activate your changes. Otherwise, you must IPL your z/OS system to make the load library APF-authorized. The Platform Services Load Library can be cataloged in any catalog in the normal search order. We recommend that you do not add this library to your linklist.

  3. Add ASCTEST as an APF-authorized TSO command.

    1. Add ASCTEST to the AUTHCMD NAMES(...) statement in member IKJTSOxx of SYS1.PARMLIB or its equivalent.

      Example:

      AUTHCMD NAMES( +
      ...other commands... +
      ASCTEST)
      

      For more information about IKJTSO xx, see the IBM Initialization and Tuning Reference for your system.

    2. Use the TSO PARMLIB command to activate your changes.

      Example:

      PARMLIB CHECK(00)
      PARMLIB UPDATE(00)
      

      For more information about the PARMLIB command, see the IBM TSO/E System Programming Command Reference for your system.

1.2.2 Installing the Platform Services Process

  1. Add the JCL procedure for ASCLIENT to your started task procedure library (SYS1.PROCLIB or its equivalent).

    Use member ASCLIENT in SAMPLIB as a model, and customize it to use your own data set names.

  2. Verify that the ASCLIENT user ID is defined as a UNIX user. For more information, see the IBM UNIX System Services Planning book for your system.

  3. Set up the configuration member for ASCLIENT.

    The ASCLIENT procedure contains ddname ASCPARMS, which must point to an LRECL=80 RECFM=FB PDS. Configuration members in ASCPARMS are named ASCPRM xx, where xx defaults to 00. Use SAMPLIB member ASCPRMXX as a model. For details about platform configuration, see the Platform Services Planning Guide and Reference.

  4. Assign a DES encryption key for the platform.

    Use the KEY statement in the configuration member to set the key for ASCLIENT. For details about the KEY statement, see the Platform Services Planning Guide and Reference.

    Use the Web interface to set the same key in the Platform object for the platform. For details about setting Platform object attributes, see the Core Driver Administration Guide.

    For details about managing DES encryption keys, see Section 2.2, DES Key Management.

  5. Give ASCLIENT performance characteristics appropriate for its role in user logon.

    Review your Workload Manager definitions to ensure that ASCLIENT is assigned to SYSSTC or a similar Service Class.

  6. Start the Platform Services Process.

    At this point, ASCLIENT is running and can accept requests, but no security system exits are in place to call it yet.

  7. Perform preliminary testing using ASCTEST.

    You can use ASCTEST under TSO, or you can use the JCL in SAMPLIB member ASCTEST to send Authentication Services requests through ASCLIENT to a core driver. For information about using ASCTEST, see Section 1.4, The ASCTEST Command.

    NOTE:The core driver treats these requests as real authentications and acts accordingly. For example, a series of consecutive invalid passwords against one user ID can cause intruder detection to be tripped for that user. If you set up test cases in eDirectory, keep in mind that if your replicas exist on multiple servers, it can take a few minutes for a change (resetting a password, disabling a user, etc.) to be communicated to the other replicas. This can cause such updates to appear to be delayed.

  8. Establish Include/Exclude lists for testing Authentication Services.

    Before installing the exits and IPLing with them for the first time, you might want to establish Include/Exclude lists in ASCPRM xx to restrict the users that ASCLIENT handles authentications for. User IDs in the Exclude list are processed by the native security system without calling the driver.

    For details about using the Include/Exclude lists, see the Platform Services Planning Guide and Reference.

1.2.3 Installing and Configuring the System Intercept

  1. Install the security system exits and update security system options.

    For details, see Section 1.5, RACF Exit Installation, Section 1.6, CA-ACF2 Exit Installation, or Section 1.7, CA-Top Secret Exit Installation as appropriate.

  2. IPL with the CLPA option.

    After the security system exits are installed, you need to IPL the system that they were installed on. Authentication requests that include a password (for users that are not excluded) cause message ASC0071I Userid userid will be authenticated locally to be issued if ASCLIENT is not running.

    When ASCLIENT is started, requests that it processes are logged to ddname ASCLOG. (Requests for excluded users do not appear in ASCLOG.) You can review these with any spool-viewing product (IOF*, SDSF, or equivalent). Note, however, that the last message is buffered and is not written until another message is issued.

1.2.4 Installing the Platform Receiver

  1. Customize and run job PAXRST0A from SAMPLIB.

    This job creates and populates the ASAM directory in the HFS.

  2. Add the JCL procedure for PLATRCVR to your started task procedure library (SYS1.PROCLIB or its equivalent).

    Use member PLATRCVR in SAMPLIB as a model, and customize it to use your own data set names. If your Receiver scripts call programs or other scripts that write to other than standard TSO output, add the appropriate DD statements to your PLATRCVR procedure.

  3. Verify that the PLATRCVR user ID is defined as a UNIX user. For more information, see the IBM UNIX System Services Planning book for your system.

  4. Assign PLATRCVR the appropriate security system authority (such as RACF SPECIAL) to manage users and groups.

  5. Set up the platform configuration file for PLATRCVR.

    The PLATRCVR procedure contains ddname ASAMCONF, which must point to a sequential file containing the configuration statements. Use SAMPLIB member ASAMCONF as a model. Specify the FilePath value of the ASAMDIR statement to be the same as the value you used for the ASAM directory in the PAXRST0A job run in Step 1. For details about the platform configuration file, see the Platform Services Planning Guide and Reference.

  6. Obtain a security certificate for the platform.

    Run the Platform Receiver interactively with the -s parameter to obtain a security certificate. You can use the SETCERT script in the exec library to do this. Customize the script to set the ASAMLOAD and ASAMHOME variables to the names of your Platform Services Load Library and your ASAM directory respectively. If you are using a PDS member instead of an HFS file for your ASAMCONF file, set the PDS variable to TRUE and set the ASAMHOME variable to point to your ASAMCONF PDS member.

    Respond to the prompts.

    • Common name of the Platform object (specified in the Web interface when the object was created)

    • Fully distinguished name and password of an eDirectory user with Read and Create object rights to the ASAM System container

  7. Establish Include/Exclude lists for testing Identity Provisioning.

    Before you run PLATRCVR to process provisioning events, you might want to establish an Include/Exclude list in ASAMCONF to restrict the users and groups that Identity Provisioning manages. Users and groups in the Exclude list are not managed by Identity Provisioning.

    For details about using the Include/Exclude lists, see the Platform Services Planning Guide and Reference.

1.2.5 Customizing the Receiver Scripts

Extend the base Receiver scripts in accordance with your installation plan. For more information, see z/OS Scripts and Executables.

1.2.6 Integrating Platform Services into Your Routine Operation

At this point, Platform Services is installed and running on one system. If you have multiple systems sharing a security system database, users on the systems that you have installed Platform Services on might be affected if they try to use other systems. In addition, if you disable the password syntax rules and history from one system, this affects all systems that share the same security system database. As a result, you might decide not to disable password restrictions until Platform Services is deployed on all systems in your complex.

Systematically introduce Platform Services into your routine production environment.

  1. When you're satisfied that Platform Services is installed and running correctly, install Platform Services on all remaining systems in your complex.

  2. Add ASCLIENT and PLATRCVR operation into routine system startup and shutdown scheduling procedures.

    When Platform Services is fully deployed, ASCLIENT must be active on every z/OS image in the complex. PLATRCVR must be active on only one system in the complex that is sharing the security database.

    Unlike ASCLIENT, whose outages should be kept to a minimum, PLATRCVR can be inactive for a reasonable period without adverse effects. When PLATRCVR is started, it receives backlogged provisioning events.

  3. After testing to your satisfaction, change the Include/Exclude lists to match your production environment.