Create the Security File

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:
      Specifies the number of physical blocks with the block size you specified that can be placed on a track.
      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.
      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.