You can edit the parameters in the DGASECUR macro to select the appropriate parameters.
The parameters are described in each source module and summarized in the following table. The parameters related to functional authority levels are listed separately in IBM® Connect:Direct® Functional Authority.
|TYPE=[SAF]||Identifies the type of exit.|
|STAGE1=[YES,NO]||Identifies whether the stage 1 signon exit is implemented.|
|NOPASS=[YES,NO]||Specifies if data set validity calls to the security subsystem are to be made without using passwords.|
|SECSYS=[ACF,TSS,RACF]||Identifies the security system package installed on your z/OS system.|
|APPLID=[NOMFA | applid]||NOMFA is the default and indicates a Multi-Factor Authentication environment is not present. When Multi-Factor Authentication is present and active in your External Security system, you must supply an application id (aaplid) that is defined to that security system to allow IBM Connect:Direct to bypass Multi-Factor Authentication. Refer to Multi-Factor Authentication section below this table.|
|AUTHENTRY=[YES | NO | EXTERNAL]||
NO specifies to have the exit work like it always has or disabled this feature;
YES specifies to require an AUTH file entry for all UIDs using a DUMMY-PWD
EXTERNAL specifies to only require it from external PNODEs.
Note: If an AUTH file entry is required but not defined, message RACF018* is issued (see AUTHMSG).
|AUTHXLAT=[YES | NO]||
NO specifies that the AUTH file entry does not have to have a Security UID/PWD and if it doesn't, the logic works like it does today - only the submitter UID is checked by the security product.
YES specifies that the AUTH file entry must have a valid Security UID/PWD. If a valid Security UID/PWD is required but not defined in the AUTH file entry, new message RACF019* is issued (see AUTHMSG).
|AUTHMSG=[WARN | FAIL]||FAIL indicates that if:
|AUTHWTO=[YES | NO]||Specifies that if any of the above new MSGIDs is set, the message ID only appears in the completion message, if present, and the PT STAT record. YES also causes the message to be filled in with the submitter node and user ID and issued via WTO, so that it appears in the JOB LOG and the WT STAT record.|
|NEWPASS=[YES,NO]||Specifies whether the security system password of a user can be changed at signon time.|
|PNODEID=[YES,NO]||Specifies if this exit enables security override of a PNODE user ID if one is used in a Process statement.|
|SNODEID=[YES,NO]||Specifies if this exit enables an incoming node to use a SNODEID.|
|RESTRICT=[YES,NO]||(ACF2 only) Indicates if a user can specify a restricted ID (an ID with no ACF2
password) to access IBM Connect:Direct.
When running a stage 1 signon exit, this parameter has no meaning. The stage 1 exit inserts a dummy password into the user security record. In an environment with a stage 1 exit, all data set validity calls to the security subsystem are made with a NOPASS option. Therefore, the security subsystem does not differentiate between a restricted ID and an ID with a valid password.
|PROTECTD=[NO,YES, AUTH]||(IBM RACF only) Indicates if a user can specify a protected ID (an ID with no
IBM RACF password) to access IBM Connect:Direct. The User IDs are defined to
IBM RACF with the NOPASSWORD and NOIDCARD parameters. A protected ID cannot be used in situations
requiring a password.
Specifying SECSYS=RACF, PROTECTD=YES, allows users to access Connect:Direct using User IDs without passwords when the Connect:Direct DTF is started with a protected User ID. Therefore, Processes may specify PNODEID=|SNODEID without specifying a password..
Specifying SECSYS=RACF, PROTECTD=AUTH, works like specifying PROTECTD=YES, except that the RACF protected ID must be specified as the SEC ID in an AUTH file entry for the USERID/NODE being verified. Also, the initialization parameter INVOKE.SPOE.ON.SNODEID must be YES
Note: For PNODEID protected id processing, specifying PROTECTD=AUTH is the same as specifying PROTECTD=YES and no entry needs to be in the AUTH file as no SPOE processing is performed for PNODEID overrides.
Specifying SECSYS=RACF, PROTECTD=NO generates no support for IBM RACF Protected User IDs.
|NPFAIL=[YES,NO]||Specifies whether to refuse a request to copy a file that is not protected. This parameter is only valid for IBM RACF and CA-TOP SECRET users.|
Specifies whether tracing will be turned on for this security exit.
TRACE=DEBUG turns control of tracing over to the DEBUG bit settings and/or the existence of the SECURITY DD statement. You can direct the SECURITY DD to SYSOUT or a disk file with attributes of RECFM=VBA, LRECL=121, and BLKSIZE=125 or greater.
For more information about starting a security trace, see Security Traces.
|CICSID=name||Specifies the dummy USERID name for establishing the initial session between the CICS Interface and a IBM Connect:Direct DTF. Use this parameter for security when using the CICS interface.|
|PASSTK=[YES|NO]||Results in the generation of a routine in the Stage 2 exit. This routine generates an IBM RACF PassTicket for PNODE processing and receives a PassTicket for SNODE processing. If PASSTK=NO is coded, no IBM RACF PassTicket processing is done. For more information, see Generating IBM RACF PassTickets.|
|PROCEXIT=[DGAXPRCT,NO]||Specifies if the DGAXPRCT exit (Process Exit for testing) is to be used or not. To invoke the exit, specify DGAXPRCT. To prevent the DGAXPRCT exit from being invoked, specify NO. For more information, see Setting Up and Using the DGAXPRCT Exit.|
|UID=local ID||Specifies the local identifier which appears in NDMLOG output along with the PTF maintenance listing.|
|CLASS=DATASET | FACILITY||Provides ability to use the IBM RACF DATASET or FACILITY class to define user authorization profiles within IBM Connect:Direct. For more information, see IBM Connect:Direct Functional Authority.|
|PPHRASE=[YES | NO ]||Provides the ability to force password / passphrase truncation at 8 characters for those environments that do not support passphrases. This is to allow compatibility with legacy environments. Default is YES which supports all environments. NO will truncate password / passphrase fields at 8 characters.|
Currently, IBM Connect:Direct cannot use Multi-Factor Authentication and if a short lived token is attempted with a process, the most likely outcome is a "RACF002I Invalid Password" as an error. The IBM Connect:Direct application must be excluded from MFA and the users must use their normal password or passphrase when using IBM Connect:Direct.
In RACF, this is accomplished by defining a profile in the MFADEF class.
RDEF MFADEF MFABYPASS.APPL.applid OWNER(ssadmin) UACC(NONE)
Where applid is the application name supplied with the APPLID parameter.
Then permitting users access to the profile.
PE MFABYPASS.APPL.applid CL(MFADEF) ID(cduser) ACC(READ)
Where cduser is the userid being granted read access to this profile. The userid that runs IBM Connect:Direct will need this access as well as each userid that accesses IBM Connect:Direct.
After using these commands, the profiles in the MFADEF class may need to be refreshed.
SETR RACLIST(MFADEF) REFRESH