Create the Security File

ctsfz
The security file is encrypted and contains all security-related information about users, profiles, departments, divisions, zones, and resources. The size of the security file does not affect CA Top Secret performance. The security file requires contiguous space on DASD. It is organized for direct access and can be located on a 3390 device.
DFSMS Extended Sequential data sets (multi volume data sets) are not supported. If the security file is extended with the NEWPWBLOCK option, mixed-case passwords, special characters, and long passwords are allowed. Security files initialized with TSSMAINT from the Version 16 libraries are defined with the NEWPWBLOCK format by default.
If you intend to implement MLS, note the following:
  • Allocate new security and backup files with sufficient MLSBLOCKS for your use.
  • Copy your existing lower-release security file into the new format.
Security File Location
Isolate the security file on a device with nothing else on the disk. This device should be high performance DASD. We recommend that no other data reside on this device. Fill the remaining DASD space on the volume with a dummy data set. This action prevents someone with access to the volume from using the free space. Protect this data from access. If isolating the security file is not an option, ensure that any other data placed on the device is not used during prime time business hours.
Determining the Security File Block Size
Select a block size to match your environment. The default block size must be a multiple of 256 and a minimum of 8192. When calculating the optimal block size, remember that the file contains keyed records with a 17 byte key.
The default parameters allow for 5,000 ACIDs and 1000 (DASD) volumes.
The file structure allows in excess of 3 million ACIDs to be defined in the security file.
Use half-track blocking if you specify more than 2,318,336 ACIDs. The best block size for half-track blocking is 27,648. However, any block size greater than 17,920 results in half-track blocking. With half-track blocking, two physical blocks of data reside on a track of the device. The smaller the block size, the fewer the number of ACIDs that can be defined for each block.
If the block size is not specified, TSSMAINT determines a default based on the type of device the file resides on.
Calculate Required Blocks
This procedure determines the number of blocks needed to create the security file.
Follow these steps:
  1. Edit TSSMAIND and SECPARMS to conform to your site's standards.
    • MLSBLOCKS=?????
      (Optional) Each MLS index entry requires one entry with a length of 14 plus the length of the resource name.
  2. Specify the name of the dummy run in the SECDUMMY member referenced in TSSMAIND.
  3. Set the ID=DUMMY parameter to consist of a maximum of eight characters.
  4. Execute a dummy run with the JCL in TSSMAIND.
    The number of blocks required is returned.
Running TSSMAIND causes an SD37 ABEND or U1520. This is normal.
Create the VSAM File
To maintain digital certificates, keyrings, and Kerberos KERBSEGM and KERBLINK records in a VSAM data set, use IDCAMS to allocate the data set. Using the VSAM data set allows heavy use of digital certificates. To assign a name to your users, use the Kerberos KERBNAME for your web users. The VSAM data set increases the amount of records that can be stored by converting the records to VSAM.
We also recommend placing the VSAM file on the following volumes:
  • A volume that other systems do not use heavily
  • A volume that is not subject to extensive I/O
  • A volume separate from the primary security file
The r9 VSAM file structure is no longer supported. CA Top Secret only supports the r12 and later VSAM file structure. If you are using the r9 VSAM file structure, allocate an r12 and later VSAM file structure and run TSSXTEND to copy the security file and r9 VSAM file to the new security file.
References to the
VSAM file
in this content indicate the r12 and later file structure unless noted otherwise.
Follow these steps:
  1. Edit the sample JCL provided in VSAMDEF3 to specify the data set name and volume to be allocated.
    Do not run STEP 2 of VSAMDEF3 if the security file is not shared. The sample includes your site-specific values.
  2. Run VSAMDEF3.
    The VSAM base cluster file is defined. If the security file is shared, the alternate index file and path file are defined.
  3. Specify this data set on the VSAMFILE DD statement in the jobs that execute TSSMAINT.
    The VSAM file is created.
After the VSAM file is created, if you wish to copy in information from an existing security file you must run the TSSXTEND utility. You can copy information from a BDAM only security file or a security file that uses both BDAM and VSAM files.
Create the Security File
You can use the TSSMAINS utility to create the security file for your system. The security file contains all security-related information about users, profiles, departments, divisions, zones, and resources.
Follow these steps:
  1. Use the number of blocks calculated by TSSMAIND to determine the size of the security file in cylinders:
    CYLS = 1 + BLOCKS / (BLKS_PER_TRK * TRKS_PER_CYL)
    • BLKS_PER_TRK
      Specifies the number of physical blocks with the block size you specified that can be placed on a track.
    • TRKS_PER_CYL
      Specifies the number of physical tracks per cylinder.
    The size is determined.
  2. Edit the CAKOJCL0 member TSSMAINS:
    1. Specify the security file parameters, line by line, to satisfy your site standards.
      Note:
      If you are unsure of previous specifications that your site used for ACCESSORS, PIEBLOCKS, RESBLOCKS, SDTBLOCKS, and VOLUMES, run TSSFAR with SFSTATS to find this information.
      • ACCESSORS=
        nnnn
        Specifies the maximum number of user, profile, department, division, and zone ACIDs defined to CA Top Secret. The value that you enter for
        nnnn
        determines the amount of security file space that is allocated to hold ACID-related security information.
        Default:
        5000
        The following formula determines the actual number of allocated ACIDs:
        (((# accessors requested * 16) / blksize(quotient only, no remainder)) +1) * (blksize / 16)) ACCESSORS=7000 BLKSIZE=8192 (((7000 * 16) / 8192) +1) * (8192 / 16)) ((112000 / 8192) +1) * 512 (13 + 1) * 512
        Example:
        The number of allocated accessors would be 7168 (not 7000).
      • AESENCRYPT
        (Optional) Activates 128-bit AES encryption for passwords and password phrases.
        Important!
        This AES encryption option is specific to CA Top Secret r14 and later; this option is not backwards compatible. If you attempt to start a single r12 system with an r14 (or later) security file that has 128-bit AES encryption enabled, CA Top Secret does not initialize.
      • AES256ENCRYPT
        (Optional) Activates 256-bit AES encryption for passwords and password phrases.
        Important!
        This AES encryption option is specific to CA Top Secret version 16 and later; this option is
        not
        backwards-compatible. If you attempt to start a single r15 (or earlier) system with a version 16 (or later) security file that has 256-bit AES encryption enabled, CA Top Secret does not initialize.
      • BLOCKSIZE=
        nnnn
        Overrides the default values for the block size of the security file. The
        nnnn
        value must be a multiple of 256 and a minimum of 8192.
      • EXPCOUNTER
        (Optional) Expands the ACID update counter in the ACID index. This counter tracks updates to ACIDs and keeps them in sync when cache is used and the security file is shared.
      • MAXACIDSIZE=
        nnnn
        (Optional) Specifies the maximum allowed ACID size (in kilobytes).
        Maximum value:
        1024
        Minimum value:
        256
        Default:
        256
      • MLSBLOCKS=
        nnnn
        (Optional) Specifies the number of blocks reserved in the security file to hold the MLS index. This index allows quick access to individual MLS record elements.
        If you do not specify this keyword, TSSMAINT calculates that two MLS entries are needed for each ACID that is requested on the ACCESSORS keyword.
        For more information about MLS security policy support, see the multilevel security documentation.
      • ORGACIDSIZE=
        nnnn
        (Optional) Specifies the maximum allowed department organizational ACID size (in kilobytes).
        Use this parameter only if you must support an department organizational ACID size that is greater than the MAXACIDSIZE value. CA Top Secret ignores any ORGACIDSIZE value that is less than the MAXACIDSIZE value.
        Maximum value:
        1024
        Minimum value:
        513
        Default:
        None
      • PIEBLOCKS=
        nnnn
        (Optional) Specifies the number of blocks reserved in the security file to hold the PIE index. This index allows quick access to owners of prefixed resources.
        If you do not specify this keyword, TSSMAINT calculates that two PIE entries are needed for each ACID that is requested on the ACCESSORS keyword. If you are defining many ACIDs, this calculation significantly increases the number of defined index blocks. The PIEBLOCKS keyword reduces that value, allowing for a smaller security file. Each owned prefix index entry requires one 35-byte entry in the index.
      • RESBLOCKS=
        nnnn
        (Optional) Specifies the number of blocks allocated to hold the general resources index. Each owned general resource prefix requires one 16-byte entry in the index; thus, each index entry points to the owner of the general resource entity.
        Default:
        10
      • SDTBLOCKS=
        nnn
        (Optional) Specifies the number of blocks for holding definitions for Static Data Table (SDT) records. An SDT record is a special system ACID that stores various user-defined static data definitions.
        Valid numbers
        : 2 to 256
      • SCA=
        msca_name
        /
        password
        Supplies the name and password of the Master Central Security Administrator (to be used in the new file).
        msca_name
        Specifies a one- to seven-character name for the Master Central Security Administrator (to be used in the new file).
        password
        Specifies a four- to eight-character password assigned to the MSCA. The password expires upon initial signon.
        Default:
        SCA=TSSSEC/TORONTO
      • VOLUMES=
        nnnn
        Specifies the number of volumes and prefixes defined to CA Top Secret. The value that you enter for
        nnnn
        determines the amount of security file space allocated to hold volume-related security information.
        Default:
        1000
        The following formula determines the actual number of allocated volumes:
        (((# volumes requested * 16) / blksize(quotient only, no remainder)) +1) * (blksize / 16))
    2. Set the VOLSER JCL parameter with the DASD volume serial identifier for your security file.
    3. Set the CYLS parameter.
    4. Set the SECPRIM ID=PRIMARY parameter to identify the name of your security file.
      The ID has a maximum of eight characters. Your entry (or the default, PRIMARY) is placed in the master security file and distinguish the master security file from the backup file. CA suggests ID=PRIMARY for the master file and ID=BACKUP for the backup file.
    5. Set the VSAMFILE DD statement to refer to the VSAM data set that you previously created.
    6. Edit step 2 of the sample JCL by performing
      one
      of the following actions:
      • To use the VSAM/Version 16 data set with a shared security file, set the VSAMAIX DD statement to refer to the alternate index VSAM data set.
      • If the security file is not shared, remove step 2 from the JCL.
        The member is customized.
  3. Run the TSSMAINS utility job.
    When the job finishes running, security file creation is complete.
  4. (Optional) Perform the following steps if you are using more than one CPU:
    1. Place the security file on a shared DASD volume that is accessible to all systems.
    2. Specify the control option SHRFILE(YES) on each CPU.
      This control option setting specifies for files that CA Top Secret uses to be shared among other operating systems, CPUs, or both.