How to set up TPX to work with Passtickets in ACF2
search cancel

How to set up TPX to work with Passtickets in ACF2

book

Article ID: 32751

calendar_today

Updated On:

Products

TPX - Session Management

Issue/Introduction

TPX provides support for Secured Signon using Passticket.
The use of Passtickets eliminates the transmission of passwords across network facilities in clear text. 

A pass ticket is a one-time only password  substitute that is automatically generated by an authentication server, such as CA's Single Signon Option or IBM's Network Security Program or on behalf of a client workstation requesting access to a mainframe application, such as TPX.

Once a user is signed on to TPX, Passtickets may also be generated for applications subsequently accessed through TPX. 

NOTE 1:  This document is specific to ACF2.  For instructions specific to Top Secret or RACF, please refer to the links at the end of this document.

NOTE 2:  If  LU02479 - an enhancement to  SUPPORT ENHANCED PASSTICKETS AND THE IBM MFA AZFPTKT1 FACTOR  -  however, it is in ERR, CORRECTED BY:  LU05160(HIPER) LU09873
                LU09873  (Security or Integrity Problem) must be applied to correct Enhanced passticket support.

Environment

Release:5.4
Component: TPX for Z/OS

Resolution

The implementation of Passticket support requires customization within the security system (ACF2) and TPX.

Required setup in ACF2 : 

Write rules for FASTAUTH calls for CLASS=PTKTDATA, ATTR=UPDATE, and ENTITYX=‘PTKTGEN.applid.userid‘.

Then, 
Create PTKTDATA profile records for example…

SET PROFILE(PTKTDATA) DIVISION(SSIGNON)

INSERT TSOSYS2.USERA SSKEY(F1F2F3F4F5F6F7F8)
INSERT TSOSYS2.GRP1 SSKEY(F1F2F3F4F5F6F7F8)
INSERT TSOSYS2 SSKEY(F1F2F3F4F5F6F7F8)

F ACF2,REBUILD(PTK),CLASS(P)
 

Verify ACF2 PTKTDATA profiles have been built correctly, 

ACF
SET PROFILE(PTKTDATA) DIVISION(SSIGNON)
LIST LIKE(-)

See ACF2 Administration Guide for further details.

TPX Setup requirements.

Within TPX, there are two separate aspects of Pass Ticket support: Users and Applications.  
You can implement one or the other or both depending upon your site requirements. 

TPX facilitates the enforcement of both non-qualified passticket and/or qualified passticket.

When both are specified, TPX attempts to use the most secure form of pass ticket available based on the
settings in CA TPX and the ACF2 Passticket Profile (PTKTDATA) definitions in the external security system.

A.  Logon to TPX with a Passticket < This is used in specific instances and is not used commonly >

  1. Set User Option ' Pass Ticket User: Y ' either in first profile assigned to a user or directly in user level
  2. To use qualified pass tickets, set ' Qualified PTick User : Y ' either in first profile assigned to a user or directly in user level

This parameter does not impact the actual sign on to TPX.  
TPX accepts the userid and password then makes a security call for validation.  
TPX is unaware of whether the password field contains a password or pass ticket at this point.

Once the user is signed on to TPX then this parameter becomes important, and these are outlined in the field level help:

  • If the user is passed to another TPX by the Affinity feature, a pass ticket is generated for the TPX that the user is passed to.
  • If a signoff command (/F) occurs, it is converted to a logoff.  This includes those produced by a timeout.
  • Timeouts that would lock the terminal are converted to logoffs.
  • The user must supply a lock word when locking the terminal.


B. Logon to applications with a Passticket 

The application must be defined in TPX Application Characteristics table (ACT)
Set ' Generate Pass Ticket: Y ' in the ACT , or Profile Session Options, or User Session Options.
To use qualified pass tickets, set ' Gen Qualified Pass Ticket: Y ' in the ACT, or Profile Session Options, or User Session Options.

Set 'Pass Ticket Prof name', if required, in the ACT.  (This parameter is not available at profile or user level.) 
This pass ticket profile name will be supplied to the external security system instead of userid during Passticket generation.

  • When Prof name is NOT specified (field left blank), TPX issues the pass ticket request with the USERID & APPLID.
  • When Prof name is specified, TPX issues the pass ticket request with the USERID & PTKT Prof name.

Create a startup TPX ACL / script, to initiate an auto signon that keys in &userid and &pswd variables for an application to ensure secured signon using Passticket
Session Data may also be used to trigger auto signon and can contain &PSWD or a combination of &userid/&pswd between the ACL and Session Data.

NOTE: TPX sends Session Data for credential validation to security, as one string.

To use Session Data for a TSO signon ...
.....will require that the ACF2 GSO / TSO record have QLOGON turned ON.
If your site uses NOQLOGON in the GSO /TSO record, you must then use an ACL to sign on to TSO rather than Session Data.  
(See Additional Information section below regarding ACF2 & TSO.)


Tracing and debugging options.

Run ACF2 security traces to verify whether or not your application requires a 'Passticket Profile name' to be defined.

Run an ACF2 SECTRACE against the TPX address space (using TPX jobname) to verify the generation of a pass ticket in ACF2.
Repeat the test with a second SECTRACE against the application to verify what entity the application is sending to ACF2 for validation.  

If it is not the VTAM APPLID, define this entity in the TPX ACT 'Passticket Profile name' field so that TPX requests the 
pass ticket for this value instead of the APPLID.  

It is important to not run each SECTRACE at the same time so that the trace data remains specific to either TPX or the application.
Also ensure the entity identified in the trace on the application (the one that you are specifying in 'Pass Ticket Prof name') 
is defined within ACF2 PTKTDATA. 

To verify if the profile name has been set up for pass tickets:

ACF
SET PROFILE (PTKTDATA) DIVISION(SSIGNON)
LIST profname

END

If it does not exist, insert the definition. 

ACF
SET PROFILE(PTKTDATA) DIVISION(SSIGNON)
INSERT profname SSKEY(ENCRYPTION DATA)

F ACF2,REBUILD(PTK),CLASS(P)

'Pass Ticket Prof name' is usually required for TSO and VM systems, where this parameter will have the value "TSOsmfid" or "VMcpuid".

  • TSO - TSOsmfid
  • VM – Vmcpuid

Other applications requiring Pass Ticket prof name, as provided to us by TPX customers:  (Please verify for your environment.)

MVSxxxx system default

    • CA7
    • CADISP 
    • NETVIEW 
    • EXIGENCE 
    • IMPLEX

 

  • ABENDAID  - As per the vendor (Compuware) :
    On page 102 of the Installation and Configuration Guide, see section entitled
    "If You Have Restricted Application Security",

    "If you have restricted application security (Resource Class=APPL), be aware that
    the Abend-AID Viewer uses the 'viewing server name', and not the LU 2 or LU 6.2 'APPLID'
    associated with the viewing server, when issuing the RACROUTE verification at user logon time.
    The viewing server name is specified on the execute statement in the server JCL.

    Check your JCL, If you have SAMPLE1 in this parm in your viewing server - PARM='SAMPLE1,VIEWER,SZS',
    This will be considered for correct passticket generation for Abend-aid.       

 

  • SYSVIEW

Review the APPL statement assigned in VTAM for the 'primary' SYSVIEW. 

The following primary applid's have been observed at some site's, for SYSVIEW
 
      >>  SYSVUSA / SYSVUSB / SYSVUSC
            but a secondary of SYSVIEWD for all 3 above. 

 (check your site on what is used for SYSVIEW applID) 
 
Using the Passticket Profile Name of SYSVIEWD works in the above case.

  • OMEGAMON

A logon to the OMEGAMON Classic will work today using Passtickets.
Make sure that the PTKTDATA Profile is set up for the 'CANDLE' application.
That is because the exit, KOMRACFX, uses 'CANDLE' as the application name on the RACROUTE calls.

Likewise, a logon to the OMEGAMON II (CUA) will work using Passtickets, as long as you
have a valid PTKTDATA profile set up for the CUA applid.

However, problems arise when the CUA attempts an internal logon to the Classic applid.
That fails because it attempts to re-use the same passticket on that internal logon.
The same passticket can not be reused with a different application.

In order to get around this, there are 2 things to do:

1. Modify the sample Omegamon exit KOMRACFX for RACF and Top Secret or KOMACF2X for ACF2 so that the Classic logon will use the same CUA application on the security calls.
    In the exit, look for this line:
M$APPL DC CL8'CANDLE'

    This defines 'CANDLE' as the application being used. Change the 'CANDLE' to be your CUA Applid.
    Then the internal Classic logon will use the same application, and will be able to reuse the Passticket.

2.  In order to be able to 're-use' the passticket, you need to specify 'MULT-USE' on the PTKTDATA resource.
    That allows the same passticket to be reused for up to 10 minutes.

There may be other applications that may require a non-standard RACROUTE verification, other than the application name.
This should be determined in conjunction with that application vendor and your security administrator.


Additional TPX Setup Requirements:

  1. SMRT Optional Parameters: Set both of these to Y:
    • SMRT Option 030 - This option will cause users defined as Pass Ticket Users to return to the TPX logo if a signoff command is entered or generated.  Pass Ticket users normally would not see the TPX logo because all signoffs are normally converted to logoffs.  If a user returns to the CA TPX logo then subsequently signs on with their real password, the signon will not be secured using the Pass Ticket technique.
    • SMRT Option 031 - This option will display "Pass Ticket" on the TPX menu in the location where "Check Messages" might appear (the W3 variable), if a user is defined as a Pass Ticket User.  The "Check Messages"indication temporarily overrides the "Pass Ticket" indication.  This option will cause the letters "PTIX" or the words "Pass Ticket" to appear on the menu in the "Status" column, for any application defined as a "Pass Ticket Application".  These are the UENTWSTS and UENTWSTL variables, respectively.  Other status indicator will temporarily override the Pass Ticket indication.
  2. SMRT Reserved Options:
     
    Access the SMRT Reserved Options by entering command “OPTIONS” on the SMRT Optional Parameters panel, then scroll down to set these options:
  • RsvOpt 041 -  When using pass ticket instead of password/phrase to access applications, set RsvOpt 41 to Y to ensure the user-id has been validated through the external security manager (Top Secret/ACF2/RACF) to gain access to TPX.  This will handle the case where certain user-ids are set to SECURITY=NONE and should not have a pass ticket generated for them to access an application.
  • RsvOpt 042 - (Optional)  Set RsvOpt 042 to Y if you need pass ticket generation messages in the TPX log for audit or other site requirements (TPXL0920, TPXL0921, TPXL0922, TPXL0923).  These messages are useful during implementation and testing of pass tickets.

To ensure that all changes have been implemented, cycle TPX or use TPXOPER RELOAD for each change. 

Additional Information

Powered by Wolken Software