SupportConnect - CA-ACF2 Frequently Asked Questions

eTrust CA-ACF2 Security
Frequently Asked Questions

General
Date Question and Answer
06/19/03

Product: CA-ACF2
Version: 6.4, 6.5
OS: z/OS, OS/390

Q: My shop uses TPX to signon to the system. This assigns VTAM ids as the source. How do I find out what the real physical source is?

A: When a user attempts a signon to TPX, even if the signon fails, TPX puts out a message TPXL0101 LOGON TERMINAL: physical source in the TPX log (not the syslog).

06/12/03

Product: CA-ACF2
Version: 6.4, 6.5
OS: z/OS, OS/390

Q: We had a S0C4 abend in another vendor's code and sent them a dump for review. The other vendor came back and said the abend was caused because an ACF2 module, ACF9CADE, freed the storage prior to their attempting to access the storage. Who is at fault here?

A: The ACF9CADE module handles RACROUTE VERIFY DELETE requests to delete a signed on user. The only reason that ACF9CADE would get invoked and therefore any storage released would be caused by the RACROUTE call requesting the freeing of the storage. From the scenario, it appears that the vendor requested the freeing of the storage and afterward attempted to access the storage. You need to go back to vendor and indicate that they need to look at their code to see why it would issue the RACROUTE call and then attempt to access the same storage that they requested to be freed.

04/21/03

Product: CA-ACF2
Version: 6.4, 6.5
OS: z/OS, OS/390

Q: I can no longer end out of the ACF prompt in TSO by only entering the letter E.

A: Correct. To use an abbreviated command, the letter(s) must be unique. When the new command EXPORT was added for use with digital certificates, the letter E was no longer unique. So the shortest abbreviation for END is now EN. But here is a little known secret, QUIT, or the letter Q will also end the session.

04/11/03

Product: CA-ACF2
Version: 6.4, 6.5
OS: z/OS, OS/390

Q: I am a security administrator reviewing an ACFRPTRV Report looking for an entry from a user who was denied access to a SAF resource associated with a RACROUTE FASTAUTH security call. After carefully reviewing the report and verifying that my report used the correct set of SMF files, I was not able to locate the SMF journal in the ACFRPTRV Report. I would like to know why I did not find a security logging for this user in my ACFRPTRV report.

A: The reason that you did not see an entry in the ACFRPTRV report is because the RACROUTE FASTAUTH call is designed to be a ‘fast’ check. To facilitate this quick processing, IBM designed the FASTAUTH call so that it does not issue any messages or journal any SMF records. The best approach to determining why the user did not have access to a resource associated with a RACROUTE FASTAUTH call is to run a eTrust CA-ACF2 SECTRACE. Consult the eTrust CA-ACF2 Security System Programmer’s Guide for information related to this command.

04/07/03

Product: CA-ACF2
Version: 6.4
OS: z/OS, OS/390

Q: My system is running at eTrust CA-ACF2 Security for z/OS and OS/390 Release 6.4 Service pack SP00. I would like to upgrade to SP03. Do I also have to apply SP01 and SP02 in order first?

A: No. The eTrust CA-ACF2 maintenance tapes are always cumulative. Adding the most recent maintenance tape will pick up any intervening maintenance. So in this case, you can just install SP03 and it will include the maintenance included in SP01 and SP02.

03/18/03

Product: CA-ACF2
Version: 6.4, 6.5
OS: z/OS, OS/390

Q: I am an eTrust CA-ACF2 Security Officer reviewing idle time processing for TSO users. I found that the TSOTIME in the logonid record does not cause the TSO user to be timed out.

A: The TSOTIME field of the logonid record and the TIME parameter of the TSO GSO Record are used to build the TIME= field of the JOB statement. This time value represents CPU time needed for the associated batch job. Idle processing in TSO is defined via the JWT field of the system SMF parameters.

02/13/03

Product: CA-ACF2
Version: 6.4, 6.5
OS: z/OS, OS/390

Q: I upgraded to Release 6.4 and my user defined field named "KEY" in the logonid record cannot be changed.

A: eTrust CA-ACF2 Release 6.4 and above now supports inserting and changing user profile information in the ACF command LID mode, just as if it were part of the user logonid record. Coupled with enhancements in prior releases of eTrust CA-ACF2, this new feature lets the security administrator insert, change, display, and delete any user information on a single command line. The ACF command process determines the actual record or records (logonid or user profile) where the information is kept, and performs the appropriate administrative request. For this reason, the field names in the logonid record and the profile records MUST BE UNIQUE. In this case, the OPERPARM profile record contains a field called KEY. So the user defined field "key" needs to be renamed in the ACFFDR, @CFDE macro to a unique name.

02/13/03

Product: CA-ACF2
Version: 6.4, 6.5
OS: z/OS, OS/390

Q: I am a eTrust CA-ACF2 security officer with the task of cleaning up the eTrust CA-ACF2 GSO records. After listing the GSO records, I noticed that the SECVOLS record was defined as a null record. I would like to know if I can delete this record?

A: The SECVOLS record is a required GSO record and can not be deleted.

01/03/03

Product: CA-ACF2
Version: 6.4, 6.5
OS: z/OS, OS/390

Q: How do I determine if our site needs to utilize the RULELONG facility of eTrust CA-ACF2 Security?

A: RULELONG allows for access and resource rules greater than 4K up to a maximum of 32K. The first thing to determine is do you really need to increase the size of the rules. If you only have 3-6 rules that are over 4k, then you would be better off leaving the rules at 4k, and making these few rules and their NEXTKEYS as resident, either in RESRULES or INFODIR depending on the type. With eTrust CA-ACF2 6.4 there are two REXX EXECs that can be used to determine the size of resource and access rules and sort them from largest to smallest. The REXX EXEC ACFRSCSZ can be used for resource rules and ACFDSNSZ can be used for access rules. Informational solution LI40774 provides details on implementing RULELONG. Note that this Information solution was written at Release 6.2, but applies to all releases of eTrust CA-ACF2.

However, Release 6.5 features a new dynamic compile option for access and resource rule sets and can only be used if the RULELONG option is set in the GSO RULEOPTS record. With this new option, eTrust CA-ACF2 defaults to use of the 4K rule format compiler and will dynamically switch to use the 32K format if the 4K compile fails due to an out-of-buffer condition, for example, the rule set is too large to fit in a 4K buffer. This feature alleviates the need to insert the $RULELONG control card for each rule set that needs to be compiled using the 32K format. Note: If the dynamic compile option (COMPDYN) is set in the GSO RULEOPTS record then the $NORULELNG control statement is not needed to compile rule sets of varying size.

12/09/02

Product: CA-ACF2
Version: 6.3, 6.4, 6.5
OS: Z/OS, OS/390

Q: How do I know which version of CA Common Services I should be running?

A54: The eTrust CA-ACF2 Product Maintenance Letters (PIBs) goes into detail about which CA Common Services Service pack (formerly know as Unicenter TNG Framework for OS/390) to run with. Under the Prerequisites Section, we name a recommended level to install. The recommended level represents the version that Computer Associates Quality Assurance group performed final integration testing with. We also give a required level - this is the minimum Service pack you can run with when installing eTrust CA-ACF2. If you no longer have a hard copy of the PIB - look on the support web site at:http://supportconnectw.ca.com/public/ca-acf2/ca-acf2supp.aspl When we announce a new service pack, the PIB is available for previewing.

12/03/02

Product: CA-ACF2
Version: 6.5
OS: Z/OS, OS/390

Q: Linux Security already has all the functionality presented at the eTrust CA-ACF2 Security Release 6.5 web cast. Why layer more products on top?

A: While it is true that Linux/390 has security functionality, there are a number of reasons to integrate this into eTrust CA-ACF2.

  1. If you use the Linux security, you have to 'pre' create the id/pswd and home directory before a user can logon. With the PAM Server and client from CA, this is not a requirement. As part of the logon, when the id/pswd is authenticated to eTrust CA-ACF2, the users home dir, UID and GID is extracted and returned to the PAM client code running on Linux/390. This code dynamically adds the user to the /etc/password file (if so configured) and then creates the home dir if needed. The user is then allowed on to the Linux node with zero Linux administrative effort.
  2. Standardization - Since eTrust CA-ACF2 is controlling the home, program, UID and GID, you will have consistent values across all nodes.
  3. Source controls - Using eTrust CA-ACF2's built in source controls, not only can you control which Linux nodes a user can logon to, but the days and time of day.
  4. Passwords - Using eTrust CA-ACF2 as a central enterprise security repository, you also get standardized password controls. Min/max length, min # of days before a change, pswd history, etc.
  5. Passwords - Using eTrust CA-ACF2 as a central enterprise security repository, the user has a single password value to remember. The user is not required to 'sync' their passwords.
  6. Security policy - When trying to create a security policy for an enterprise, there are always the differences in the security of each platform that makes it difficult to have a standard policy. Exceptions are always found. Using eTrust CA-ACF2 as a central enterprise security repository this is no longer an issue.
  7. The PAM client will be released as open source from CA. This will allow any client of CA to 'port' the PAM client to any platform that has a PAM framework as part of the operating system. This includes Linux on other platforms such as Intel, Sun Solaris, HP-UX and IBM's AIX. Citing all the reasons above, you can truly start to use eTrust CA-ACF2 as a central enterprise security repository.
  8. Employee's leave the company - When employees leave the company, you don't have to run around trying to delete the user account from every node they every logged on to. Suspending/deleting that account from eTrust CA-ACF2 makes sure that every Linux system using our PAM client is secure and that ID can't be (mis)used.
  9. Scalable - eTrust CA-ACF2 is very scalable. Using it to control the Linux nodes just adds to it's value.
Just to reiterate reason 1, we have a client who is in the process of setting up approximately 1000 Linux/390 LPARs. The administrative effort to maintain user id/pswds in the nodes would require a number of administrators. While your organization might not be looking at this many, I will venture a guess and say that I doubt your administrative staff is growing to service security requirements. This alone should be reason enough to add a very thin layer to enhance and centralize the security in your environment.
11/21/02

Product: CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: How does eTrust CA-ACF2 store passwords?

A: eTrust CA-ACF2 uses the XDES password encryption subroutine (ACSCODEP) which uses a two-step encryption process that transforms the eight-byte password plus a key (TOD clock) into a four- or eight-byte cipher. This encryption process is one-way and irreversible. As a result, the password is never displayed.

eTrust CA-ACF2 also uses the ACSCODEP subroutine in its processing. You can substitute your own subroutines in place of the one used by eTrust CA-ACF2.

11/21/02

Product: CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: What is XDES password encryption?

A: XDES takes the DES encryption method and applies a proprietary algorithm to generate a unique one-way encrypted value/password.

11/21/02

Product: CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: What is XAPPLVLD support? How and why would a site use this option?

A: XAPPLVLD support was added to eTrust CA-ACF2 6.3 and 6.4. The new GSO OPTS parameter XAPPLVLD|NOXAPPLVLD is used to control this option. Sites that do "APPL" resource validation to control a user's authority to access an application during system entry processing would find this option useful in situations where there is no "APPL" provided on the SAF VERIFY/VERIFYX call or when there is no "APPL" passed on a NON-SAF caller. In these situations, with the GSO OPTS XAPPLVLD set ACF2 will assign an "APPL" as follows:

  • On a SAF VERIFY/VERIFYX request if no APPL is passed by the caller, ACF2 will assign an APPL of 'MVS' followed by the 4 character SMFID of the system.
  • On a NON-SAF signon request if no APPL is passed by the caller, ACF2 will assign an APPL of 'TSO' followed by the 4 character SMFID of the system for TSO signon or 'MVS' followed by the 4 character SMFID of the system.
Once the APPL has been determined a resource validation will be issued with the APPL value.
10/02/02

Product: CA-ACF2
Version: 6.4
OS: Z/OS, OS/390

Q: My company is planning to install the new z/800 processors, management wants to know if eTrust CA-ACF2 Security needs to be upgraded to support these new machines?

A: The eTrust CA-ACF2 Security family of products is not hardware dependent and does not require any modifications to support new hardware.

09/23/02

Product: CA-ACF2
Version: 6.4
OS: Z/OS, OS/390

Q: Do I need user defined SAFDEF records?

A: In most cases, no. 99% of the time a user defined SAFDEF record that is set to MODE=IGNORE should not be used and may be a security exposure. Also, having too many SAFDEF records, most of them being redundant can add to system overhead. eTrust CA-ACF2 will validate most SAF calls by default. Some of the internal eTrust CA-ACF2 records are set to IGNORE, such as program validation. This was done since most of the user community does not need to validate all programs on the system so the IGNORE was set for performance reasons. In these few instances, a user SAFDEF set to MODE=GLOBAL is fine. eTrust CA-ACF2 support would be more then glad to review your SAFDEF records with you. List your user SAFDEF records and open an issue with support.

09/16/02

Product: CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: Are you still running with a generic 39 *'s resource rule under a type code of SAF or FAC?

A: You should not be. That is a security exposure and was only meant to be used for migration purposes when CA-ACF2 6.0 was released. CA recommends that you change the rule to LOG for a short time, write the appropriate rules needed, and the REMOVE the rule.

07/24/02

Product: CA-ACF2
Version: 6.5
OS: Z/OS, OS/390

Q: We have UNIX based LDAP servers and would like to synchronize password changes with eTrust CA-ACF2. I do not believe this is available in Release 6.3 or 6.4. Will this be available in a future release of eTrust CA-ACF2?

A: Yes, in Release 6.5, which is currently in beta, there is a new feature called LDAP Directory Services (LDS) which adds outbound propagation of logonid changes to LDAP directory servers. The connected LDAP directory servers can be any directory including an eTrust Admin user directory, an eTrust CA-Top Secret Security for z/OS and OS/390 system, or another eTrust CA-ACF2 system, giving you the capability to automatically update and synchronize user fields and password on all eTrust controlled systems in your enterprise from eTrust CA-ACF2. All of this is accomplished from eTrust CA-ACF2 without requiring the eTrust LDAP Server.

5/20/02

Product: eTrust CA-ACF2
Version: 6.4
OS: Z/OS, OS/390

Q: I am an eTrust CA-ACF2 security administrator who has been updating rules using the TSO ACFNRULE command. I noticed in the Release 6.4 eTrust CA-ACF2 Security for z/OS and OS/390 Release Guide that there is a new command for writing rules using the RECKEY. Can you explain this new command for me?

A: With eTrust CA-ACF2 Release 6.4, there is a new subcommand for updating access and resource rules. This subcommand is called RECKEY and is not a replacement for the TSO ACFNRULE command, but an enhancement to rule writing that allows the security officer to add an individual rule using the interactive ACF command. If your site is using CPF, the rule update is also propagated to all the nodes defined in the CPF environment. For more information on this easy to use enhancement, consult the Release 6.4 eTrust CA-ACF2 Security for z/OS and OS/390 Administrator Guide.

5/02/02

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: I have implemented external security for SDSF, written rules for JESSPOOL, but users are still able to read and delete output that is not theirs.

A: When a user enters SDSF (i.e. before he/she goes to any SDSF panels like H/O/I...etc), an SDSF initialization routine checks if this is a destination operator, i.e., does the user have access to resource 'ISFOPER.DEST.jesx', class=SDSF? If yes, SDSF sets a bit ON. When it comes to issue a RACROUTE against the JESSPOOL class, SDSF sets RECVR to the userid. Destination Operator is a group of special users who can see all jobs. For more details on Destination Operator, see "SDSF Installation and Customization", sub-topic "Destination Operator Authority". RECVR as defined in "OS/390 VxRn.0 Security Server RACROUTE Macro References" topic "RACROUTE REQUEST=AUTH Macro" says:

,RECV=recvr addr
specifies the address of the user ID that has the authority to
access the resource regardless of whether there is a resource
profile to protect it...

So, if you don't want SDSF to plug the userid in the RECVR parm of the RACROUTE REQUEST=AUTH macro, ensure the 'ISFOPER.DEST.jesx' rule does not allow it. The described RACROUTE requests can be seen in the output of a SECTRACE set to trace the activity from the time the user enters SDSF until he/she access the file in JESSPOOL.

3/12/02

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: Did you know what the easiest way is to obtain a list of all solutions beyond a service pack?

A: Visit our support page under Solutions and Patches and just point and click on the desired service pack. The support page has also been enhanced to provide you with a list of all HYPER solutions for a particular release. Visit: http://supportconnectw.ca.com/public/ca-acf2/ca-acf2supp.asp

3/12/02

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: I have a generic 40 * 's resource rule. Do I still need that?

A: A generic or 40 * 's resource rule is intended as a migration tool to help identify what SAF resources are being used and then write the appropriate rules. This generic rule should never be a permanent rule as it is considered a security exposure. If you still have a generic rule in place, you should take steps to remove it. To do this, first set it to LOG to determine if any resources are being validated through it. If you find validation being done, write specific rules for the resources in question. After a given time period (four to six weeks), delete the generic rule and rely on the specific rules from that point onward.

3/12/02

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: I am a systems programmer who made several updates to an eTrust CA-ACF2 exit, do I need to IPL in order for the updated exit to become active?

A: To activate an eTrust CA-ACF2 exit without an IPL you will need to issue an OS/390 dynamic reload of the module, then issue an ACF2 REFRESH command of the EXITS record (F ACF2,REFRESH(EXITS).

2/26/02

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: I don't know if it was stated in any of the manuals, but how does validation know how much iteration it has to go through to process a UID with multi-value fields? Not MVMAX is it? Does it know how many of the fields have something defined in them? Does the first blank or zero-filled field stop the validation process?

A: The first blank or ZERO filled field stops the validation process. MVMAX specifies how many fields can be defined.

2/26/02

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: When writing rules; if the UID is masked prior to the beginning of the multi-value field location does the additional substitution take place or is the software smart enough to know that that portion of the UID string is not involved in the validation process?

eg. UID(ABCDEFmultivalueGHI)
rule: UID(ABC)would this only require the single validation or would it cycle through all of the values in the multi-value field?

A: The masked portion of a UID string is involved in the validation process. Since it is masked it will always match and the same multi-value field process takes place. eTrust CA-ACF2 Security will validate the access using the first value. If access was not allowed eTrust CA-ACF2 then validates using the second value and so on until the access is allowed or all values in the multi-value field have been used.

2/26/02

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: What does the REPONLY flag imply in the MVFLAGS field of the @CFDE macro? What other options are there when updating a multi-value field? Does it mean that if there are currently 3 values assigned to a multi-value field that all three must be processed to make a change even if you only want to change the first value? How would you delete the last one or two values?

A: MVFLAGS=REPONLY specifies that the multi-valued field must be entirely replaced. You cannot add or delete values from within the list.

If a multi-value field has MULTFLD(AAAA,BBBB,CCCC) and you do not specify REPONLY then the command to add or delete a field is:

CHA MULTFLD(DDDD) ADD>
MULTFLD(AAAA,BBBB,CCCC,DDDD)

CHA MULTFLD(BBBB) DEL
MULTFLD(AAAA,CCCC,DDDD)

With REPONLY specified the fields are automatically replaced:

CHA MULTFLD(AAAA,BBBB,CCCC,DDDD)
2/26/02

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: The eTrust CA-ACF2 Security Getting Started, page A-42 states: '.... you may need to convert the UID string to allow for the multi-value field. If enough room exists for the multi-value field, add the field to the UID string. .... If there is not enough room within the current UID string for one value of the multi-value field, convert the UID structure to accommodate it'.

Am I reading too much into this? They are not implying that a multi-value field takes up more room that the defined length of the field are they? There is NO overhead involved. If you define 10 7-byte multi-value fields the UID only needs to have the 7 bytes available, not part of the 12-byte header?

A: You are not altering the length or layout of the UID string; the UID only needs to have the 7 bytes available.

12/19/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: Can I share eTrust CA-ACF2 databases between eTrust CA-ACF2 Releases 6.4, 6.3 and 6.2?

A: Yes.

12/19/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: Can eTrust CA-ACF2 protect who submits specific jobs?

A: Yes, with a JES2 validation call under the JESJOBS class. A SAFDEF may be needed to turn on the validation, and the resource name is in the format of:

'SUBMIT.node name.jobname.userid' SUBMIT is the only hard fast name and the other 3 fields are variable. A sample rule would look like this:

$KEY(SUBMIT) TYPE(SAF)
PRODNODE.PRODJOB.PRODID UID(your uid string) ALLOW *** This rule allows you to submit the production job ***
PRODNODE.PRODJOB.PRODID UID(-) PREVENT             *** This rule does not allow anyone else to submit production ***  
- UID(-) ALLOW 					    	   *** This rule line allows all other jobs
12/19/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: How do I find out about hyper APARs for my eTrust CA-ACF2 product?

A: Go to http://supportconnectw.ca.com/index.html?StarTcc and select Hyper Solution Delivery and select which product(s) you are interested in. You may only select products which are licensed under your site id. Setting up this feature requires a STARTCC signon which you can request if you have a site id.

NOTE: STARTCC signons are not immediately assigned, but require turnaround time of up to a day or more.

When a hyper solution is published for your product, you will receive an email. Hyper solutions include all PTF's that are marked hyper, and also include all Product Maintenance Letters, Product Documentation Changes and Product Error Alerts. This includes announcements of product releases, which are published as PML's.

12/14/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: How to I find what service pack level of eTrust CA-ACF2 Security I'm currently running?

A: To find the current eTrust CA-ACF2 service pack level, do the following:

1) From TSO, type "TSO ACF" and press enter.
2) At the prompt, type "SHOW STATE" and press enter.
3) The following information will be displayed on the first line:

RUNNING ACF2 6.4 SP01 /MVS SP6.1.0; WITH MODE = ABORT
...

4) Type "END" and press enter to exit command processor

12/14/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: I maintain resource rules in a PDS. How can I have members that have the same resource name, but different type codes? If I decompile each rule into the PDS, they would have the same member name and one would replace the other.

A: You can supply a unique member name via the $MEMBER keyword in the rule, then when the rule is decompiled, it will go into the specified member in the PDS. In this way you could have members named BPXS and BPXF, each for a $KEY(BPX), but in BPXS the type is SAF, and in BPXF the type is FAC.

 
The format of the rule is:
   $KEY(BPX) TYPE(FAC)
   $MEMBER(BPXF)
     -.-  UID(uidstring) ...

10/31/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: When some of my TSO users connect to FTP from their TSO session, they are not able to enter their password when they attempt to logon to FTP. FTP seems to fly right by the prompt. They see the password request but don't have time to enter their password in response to the prompt.

A: When connecting to FTP from TSO, FTP uses the users TSO Profile. If that profile is set with NOPROMPT, then there will not be any prompting when using FTP. The solution is to change the eTrust CA-ACF2 logonid record and specify PROMPT. The default setting for this option is NOPROMPT.

10/31/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: I am currently using the eTrust CA-ACF2 Security for IMS interface to protect IMS transactions. I also use native IMS transaction security via the SMU Tables. What happens when transactions are secured via the eTrust CA-ACF2 IMS interface and the same transactions are secured via the IMS SMU Table?

A: If your site is using IMS SMU for terminal transaction security and the SMU definitions deny the access then IMS will issue message DFS067I. If the IMS SMU definitions allow the access and the requested transaction is also protected by the eTrust CA-ACF2 IMS interface, then the interface will validate access to the resource. If the user does not have access then the eTrust CA-ACF2 IMS interface will issue a DFSU security violation message and the user will be denied access to the transaction.

10/31/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: Should eTrust CA-ACF2 Security logonids ever have both the STC and the RESTRICT privilege?

A: No, STC is only meant for started tasks. RESTRICT is for production BATCH logonids. Either way, a user cannot signon with a logonid containing the STC or RESTRICT attribute.

10/31/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: How do I find information on what is required for OS/390 or the zseries machines?

A: In StarTCC select "Search CA Knowledge Base", select the product UPGRAD - General Upgrade using the keywords of the operating system and product you are inquiring on. For example, keywords of zOS and 1.1 and ACF2 would yield the informational solution for zOS 1.1 and the product of ACF2. To view this solution now, logon to StarTCC at: http://webtrack.ca.com/cgi-bin/ks02?action=Display&Graphics=Full

10/31/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: Where can I find a list of the latest releases and service pack status for eTrust CA-ACF2 Security?

A: A quick and easy way to find the latest release and service pack information for eTrust CA-ACF2 Security is to "Search CA Knowledge Base" in StarTCC. Select the Product " UPGRAD - General Upgrade", Keyword " ACF2MS". There you can download solution LI99396, "eTrust CA-ACF2 Security Upgrade Information - Release and Service Pack Status." This informational solution also provides you with. To view this solution now, logon to StarTCC at: http://webtrack.ca.com/cgi-bin/ks02?action=Display&Graphics=Full

09/12/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: In using CPF, I issued a CHANGE command using the abbreviation CH on eTrust CA-ACF2 6.3 system that was targeted to eTrust CA-ACF2 6.3 and 6.4 systems. I noticed that the requested changes did not take effect on eTrust CA-ACF2 6.4 system. Why?

A: eTrust CA-ACF2 recognizes the smallest set of uniques letters as an abbreviation for a command. In eTrust CA-ACF2 6.3 CH fulfills this requirement but, in eTrust CA-ACF2 6.4 due to enhancements to the product, CHA is now required as the abbreviation for the change command. The use of CH on a 6.4 system results in an error. When using CPF to propragate commands among systems at different eTrust CA-ACF2 release levels, you must ensure that any abbreviations used are acceptable to all the targeted systems.

08/14/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: I've been getting email notifications for solutions that are referred to as PEA. What is a PEA and why am I being notified?

A: A Product Error Alerts (PEA) is a StarTCC Informational APAR that is used to alert clients of a HIPER (also referred to as HYPER) problem that does not yet have an available solution. Because a solution is not available, it is important that we notify our clients on how to avoid the problem and how to handle the situation should it occur. Clients that have registered for HIPER notification in StarTCC will receive email whenever a PEA is issued.

In general, a HIPER Solution that delivers a PTF fix will follow a PEA. There may be times when a follow up solution is not needed. For example, this may occur if the PEA is an alert for a problem impacting our products that is actually resolved by another vendor.

07/19/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: I am setting up an IBM application with external security requirements. These requirements are stated as RACF commands. How do I translate these to eTrust CA-ACF2 Security for z/OS & OS/390?

A: There is a translation guide in Appendix A of the OS/390 Cookbook, which offers pointers on what you need to do with RACF set-up in an eTrust CA-ACF2 environment. As an added check, you can open a support issue so that eTrust CA-ACF2 Technical Support can review this and confirm what you need to do in eTrust CA-ACF2. Another way to review this is to use StarTCC to see if an informational solution has been created for this application.

06/27/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: I have been reviewing the CA-ACF2 6.4 documentation and I notice there is no Other Products Guide. Is one available?

A: As of the 6.4 release of CA-ACF2, the Other Products Guide has been replaced by STAR TCC informational solutions in order to provide more dynamic, timely documentation on the interface between CA-ACF2 and other products. Many of the products previously documented in the guide are now using SAF. These SAF requests are handled by the CA-ACF2 SAF interface and most do not require any special documentation. Where additional documentation is required, an informational solution will be added to STAR TCC.

06/25/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: We are in the process of web-enabling our CICS applications. How do we secure them?

A: This is a good question, but unfortunately we can't answer it with the background information that has been provided. In order to help you identify the security facilities that are available, we have to have more information on the specific CICS functionality that is being used.

CICS provides many methods of providing web connectivity. Examples are CICS Web Services (CWS, formerly known as the CICS Web Interface, or CWI), 3270 Bridge, External CICS (EXCI) Interface, MQSeries Bridge, Sockets Interface, Java/IIOP interface, and others.

There are many factors that go into choosing a web-enabling method, among them being:

- Functionality
- Installation familiarity with the method
- Ease of use/implementation
- Security
- … and others

Each method has its advantages and disadvantages. Which method your installation chooses can hinge on any number of factors, and security should be one of the selection criteria because not all methods provide the same level of security functionality.

Security can be viewed as a combination of two elements: user identification and/or authentication, and resource security. The primary security difference between web-enabling methods is in the area of user identification/authentication.

05/17/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: When inserting the OMVS default user LOGONID, I received the message ACF02037 - KEYWORD PASSWORD IS REQUIRED. Why did I get this message and how can I insert the LOGONID?

A: All logonids that do not have the RESTRICT or STC attributes are required to have a password when PSWDREQ is specified in the GSO PSWD record. Inserting this logonid with the RESTRICT attribute, as recommended for other ACF2 default logonids, will avoid the ACF02037 message.

03/26/01

Product: eTrust CA-ACF2
Version: 6.3, 6.4
OS: Z/OS, OS/390

Q: I recently upgraded to CA-ACF2 6.4 SP00 and found that I can no longer use CH as an abbreviation for the ACF CHANGE command. Why can't I use this as an abbreviation?

A: The ACF command has been enhanced to include several new commands. Because of these enhancements, the abbreviation of some commonly used commands like CH or CO conflict with commands related to some of these new commands such CHKCERT or CONNECT. Beginning with ACF2 6.4 SP00, the common abbreviations like CH for CHANGE or CO for COMPILE will no longer work as they are no longer unique. To abbreviate this commands, you would need to specify CHA or COM.

03/02/01

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: I am getting a violation for a UNIXPRIV class call that says I have no record or NO-REC on the ACFRPTRV report. I view my rules and I see the record key needed. Why am I getting a NO-REC violation?

A: UNIXPRIV class calls are RACROUTE FASTAUTH calls. A FASTAUTH calls requires the rules be Globally resident. You need to add an INFODIR directory for R-RUNI.

02/23/01

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: I do a SHOW RESIDENT command and I see more directories being resident then I have in my INFODIR or RESDIR. Why is that?

A: If a SAF RACROUTE=LIST call with the parameters of either GLOBAL=YES or SUBPOOL=241 is made by an application or address space, CA-ACF2 will create a resident directory for that type code as if it was coded in the INFODIR record. CA-ACF2 will also load the rules related to that type code into storage when the call is made. Furthermore, this directory cannot be deleted and will remain on the system till the next IPL.

02/23/01

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: I am setting up a pass ticket environment to avoid sending clear text password from a workstation connecting to the mainframe. I have generated the ticket using the supplied IBM utility. What do I need to do to set this up with CA-ACF2?

A: A pass ticket is generated using a security key. You need to define this security key using the PKTDATA profile record so CA-ACF2 will recognize it. This record has the SSKEY operand which will contain the 8 byte security key as a 16 character hexadecimal value. Another point that is important is to ensure that the clocks between the work station and the mainframe are synchronized as a pass ticket expires after approximately ten minutes and are, therefore, time sensitive.

02/23/01

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: I recently upgraded to OS/390 2.10. When I installed CA-ACF2 6.3 on top of this version of OS/390, I received several ASMA041E assembly errors in ACFJ2ITF (JES2 interface). The error message referenced the expanded $WTO macro in ACFJ2ITF. What do I do?

A: The errors are caused by High Level Assembler Release 4.0 incorrectly calculating the length for the DC instruction in the $MPRINT macro included in the expanded $WTO macro. IBM has published solution UQ48242 to correct this problem. This solution can be downloaded from the IBM web site.

11/10/00

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: We had a power outage that brought our system down. When we came back up, we had lost some of the devices and started receiving a JCL error in ACF2 PROC during System IPL. What can we do to get CA-ACF2 stated?

A: A JCL error in the ACF2 PROC may occur if there is an actual JCL error in the PROC such as a bad JCL statement or missing comma or parenthesis; or it may occur due to problems with the SYSUT1 DD specification because a UNIT or VOLUME is not available at IPL time. The backup work files, such as SYSUT1, can be specified in the CA-ACF2 PROC to be allocated at CA-ACF2 startup, or, they can be dynamically allocated when BACKUP commences using the PRISPACE, SECSPACE, and WORKVOL/WORKUNIT fields of the BACKUP record. If the work files are dynamically allocated, their storage is released as soon as backup completes. Otherwise, the allocated storage is retained until CA-ACF2 terminates.

In the above situation a site may need to IPL the system without CA-ACF2 in order to correct the problem. There are two methods that a site can implement to insure that the system can be IPLed with CA-ACF2 in an inactive state:

  1. CA-ACF2 can be started with the CAISEC00 method and utilize a secondary or backup CAISECxx member that will cause CA-ACF2 to not start. This method can be setup by adding a prompt to the CAISEC00 member that is contained in SYS1.PARMLIB which will cause CA-ACF2 to prompt the operator console for specification of the CAISEC initialization parameters. During CA SAF initialization, a WTOR message CAS2070I is issued to allow the operator to specify the CA SAF initialization parameters. The operator can respond with SEC=xx to indicate that an alternate SYS1.PARMLIB member ‘CAISECxx’ should be processed. In this ‘CAISECxx’ member ACF2(xx NOSTART) would be specified to cause CA-ACF2 to not start. See 3.13 Step 11: CA-ACF2 System Initialization of the CA-ACF2 Installation Guide for details.


  2. Another method would be to set up a special IEASYSxx member that is set up to use LPA and LINKLST members that do not include the CA-ACF2 LPA and linklist datasets.
The site should be sure that TSO UADS are defined for those systems programmers that will be able to logon on to TSO when CA-ACF2 is not active.

11/10/00

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: The documentation for external security for a product or application is specified in RACF terminology. How do I translate this to determine what I need to do in CA-ACF2?

A: There is a section in the CA-ACF2 Security Cookbook for OS/390 that explains the relationship between a RACF command and CA-ACF2 commands. For example, it indicates that a RACF PERMIT is the equivalent of writing an access or resource rule. In addition, the Cookbook already has the setup information for the USS environment for many of the components. If it is not in the Cookbook, there may be an informational solution available on StarTCC for a product such as SDSF, MQSeries, WLM and so forth.

11/10/00

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: CA-ACF2 Tech Support has seen questions of the following nature: We changed CICS PROC names; why won’t the CA-ACF2 CICS interface to initialize? Or we moved CICS from a batch job to a started task; why won’t the CA-ACF2 CICS interface to initialize?

A: With the CA-ACF2 interface for CICS 4.1 and above the initialization process requires that the logonid associated with a CICS region have the ACF2CICS attribute turned on. When sites are making changes to a region, this requirement can be overlooked. In addition, the CA-ACF2 Support Guide has a section on troubleshooting that lists the areas for review when a region will not initialize with CA-ACF2.

11/10/00

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: Why is there no ‘install.exe’ file on the current documentation CD (August SP12) to install Library Reader for Windows (the tool to view the books and the book shelves from the CD)?

A: In the ‘Readme.txt’ file on the documentation CD is the instructions for downloading the most current version of the IBM Bookmanager viewer and Adobe documentation viewer from the Internet. Both free of charge.

11/10/00

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: Where can I obtain manuals for CA-ACF2?

A: You can obtain manuals for CA-ACF2 from a number of sources. The CA-ACF2 product tape contains a complete documentation set available in IBM BookManager format and PDF format. The BookManager and PDF files are also available on the CA Systems Library for OS/390 CD. You can also get the PDF files through the CA-ACF2 Support/eSupport web sites at http://supportconnectw.ca.com.

11/10/00

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: I am running various release levels of CICS. Am I required to do separate installs and create separate loadlibs for each separate release of CICS?

A: For Release 6.3 of CA-ACF2 for OS/390, the CA-ACF2 CICS interface provided is compatible with CICS 4.1, CTS 1.1, CTS 1.2, and CTS 1.3, so CA-ACF2 CICS needs to be installed only once under a single FMID. With Release 6.2 of CA-ACF2 for OS/390, there are two FMIDs, one for CICS 4.1, CTS 1.1, and CTS 1.2 and another for CTS 1.3.

11/10/00

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: After upgrading to a new release of OS/390, I am seeing ACF99913 and ACF04056 violation messages that did not occur in the previous release. What changed and how do I correct this?

A: Normally, each release of OS/390 adds new features and enhancements. These new features and enhancements represent new resources that were not present in earlier releases of the system. To protect these resources, OS/390 makes external security calls. CA-ACF2 processes these external security calls automatically, requiring additional access and resource rules to allow access. You can obtain details concerning the requested access by running the various CA-ACF2 violation reports such as the ACFRPTDS or ACFRPTRV.

11/10/00

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: After upgrading CA-ACF2 to Release 6.2 9906 or higher and OS/390 2.5 or higher, when executing PGM=FTP, I am getting error message CEE5101C BPX1MSS FAILED 4093 Return Code=156, Reason=0B0C00FC or REASON=0B0C00FD. This FTP program worked fine previously before the upgrade?

A: With Release 6.2 of CA-ACF2 for OS/390 Genlevel 9906 and higher running on OS/390 2.5 or higher, the default OMVS user that is defined in the Release 6.2 GSO OPTS DFTOMVSU or in the Release 6.3 GSO UNIXOPTS DFTUSER is required to be defined in the Logonid database. This logonid does not require any special privileges and can be inserted in the Logonid database with just the NAME parameter as follows:

ACF
INSERT xxxxxxxx (OMVS Default user)

Where xxxxxxxx is the logonid specified in the CA-ACF2 GSO OPTS (6.2) or the GSO UNIXOPTS (6.3). Please note that CA-ACF2 6.2 9906 level also requires APAR LO57216.

11/10/00

Product eTrust CA-ACF2
Version: 6.1, 6.2, 6.3, 6.4
OS: z/OS, OS/390

Q: Can the CA-ACF2 databases be shared between systems running with different versions of CA-ACF2?

A: Yes, the CA-ACF2 databases can be shared in a mixed environment (6.1, 6.2, and/or 6.3) as long as any downward incompatible enhancements are not used. For example, sharing among 6.1 and 6.2 or 6.3 systems means that you could not employ the rule long feature until the 6.1 system had migrated upward. For information regarding incompatible features with earlier releases of CA-ACF2, refer to the Release Guides.

11/10/00

Product eTrust CA-ACF2
Version: 6.3
OS: z/OS, OS/390

Q: I still have a CICS 2.1.2 region running with the Release 6.1 CA-ACF2 CICS interface. I am planning to migrate to Release 6.3 and understand that there is no CICS 2.1.2 interface at the CA-ACF2 Release 6.3 level. Can I still run the CA-ACF2 CICS 2.1.2 interface from Release 6.1 when I migrate to Release 6.3?

A: The CICS 2.1.2 release is no longer supported by IBM or CA. However, you may be able to run the Release 6.1 CA-ACF2 CICS interface under a Release 6.3 of CA-ACF2 for OS/390 base. This has not been QA tested. There are no guarantees that this will function and you do so at your risk.

11/19/01

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: How can I get a more current copy of the CA-ACF2 for OS/390 Security Cookbook?

A: The CA-ACF2 for OS/390 Security Cookbook is now provided on the CA Systems Library for OS/390 CD-ROM. It can also be downloaded from the following Internet address: http://supportconnectw.ca.com/public/ca-acf2/infodocs/ACF6XOZ.pdf.

11/10/00

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: Can we run Release 6.3 CA-ACF2 CICS interface under Release 6.4 CA-ACF2 for OS/390 base?

A: Yes, but you must run the job CXCM6241 that will apply levelset PTF TT63624. This job is found in the SAMPJCL library provided with the product.

11/10/00

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: Can we run the Release 6.3 of CA-ACF2 IMS interface under Release 6.4 of CA-ACF2 for OS/390 base?

A: Yes.

11/10/00

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: What service pack should I run with my version of OS/390?

A: We provide informational solutions on StarTCC under the UPGRAD product for each release of OS/390, which list the current releases of the CA-ACF2 as well as the required service level plus any additional maintenance required to run with that OS/390 release.

11/10/00

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: I am setting up external security for a new product and the documentation for external security uses RACF terms. Is there a CA-ACF2 document that translates from RACF terminology to CA-ACF2 terminology?

A: Appendix A of the CA-ACF2 for OS/390 Security Cookbook relates a RACF command to its CA-ACF2 counterpart. In many cases, there is no CA-ACF2 counterpart. For example, RACF uses the RDEFINE command to define a resource class to RACF so that protection is activated. CA-ACF2 protects all resources by default so this command is unnecessary in CA-ACF2.

11/10/00

Product eTrust CA-ACF2
Version: 6.3, 6.4
OS: z/OS, OS/390

Q: Are the CA-ACF2 manuals available on the Internet?

A: Manuals are available from several sites on the Internet. http://esupport.ca.com has CA-ACF2 for OS/390 manuals in PDF format available to view or download. ftp://ftp.ca.com has manuals for all versions of CA-ACF2 available for download in BookManager format and PDF format. The CA-ACF2 for OS/390 Security Cookbook is available to view or download at http://supportconnectw.ca.com/public/ca-topsecret/manuals/TSSCookB.pdf.