|
|
|
The LPA analysis functions verify that module relationships that are expected in an CA ACF2-protected system are present and functioning. CA Auditor compares various z/OS and CA ACF2 module linkages found in the running system to those that CA ACF2 expects. CA Auditor reports any deviation that it detects in this comparison by displaying the RECOMMENDED FOR REVIEW message.
If a flagged entry is selected and the review recommendation was made because an CA ACF2 validation failed, a message displays on the detail panel. This message identifies CA ACF2 and contains a numeric reason code that describes the specific type of condition encountered. Each reason code is a two-digit number.
CA ACF2 introduces several routines that perform access validations before permitting z/OS to answer a request for certain resources. For example, before a user is permitted to scratch a data set using SVC 29, CA ACF2 first verifies that the user has allocate access to that data set. The validation-before-service sequence is established by routing various z/OS service requests through a corresponding CA ACF2 validation routine. If an CA ACF2 validation routine cannot be located, CA ACF2 assigns reason code 04 to the corresponding z/OS service.
This reason code usually indicates that CA ACF2 was not properly installed on the system. However, it can also occur when CA ACF2 modules or linkages are modified after CA ACF2 is started.
When CA ACF2 performs preliminary validations for a z/OS service, it continues based on the user’s access authority to the designated resource. If the user does not have the appropriate access authority, CA ACF2 denies the request, and the requested service is not performed. However, if the user has the proper access authority, CA ACF2 forwards the request to z/OS by passing control to the z/OS service routine that was in control at the time CA ACF2 was started. CA ACF2 expects that this routine is a standard z/OS module that adheres to IBM naming conventions. If the routine found at the virtual storage address given control by CA ACF2 does not appear to be a copy of the distributed z/OS module, CA ACF2 assigns reason code 08 to the corresponding z/OS service.
This reason code can indicate that another program product or locally developed interface altered or intercepted a z/OS service routine before CA ACF2 startup. Although this does not generally affect the operation of CA ACF2, data center personnel should be aware of the objectives of all local programming that alters the operation of standard z/OS services.)*
In several cases, CA ACF2 provides z/OS with the address of an access validation routine that must be executed before the associated z/OS service routine receives control. For example, the z/OS SCRATCH SVC (29) is updated to point to an access validation routine that ensures that a requester has allocate access to the data set to be deleted. If the address of the first module to receive control in the SCRATCH process is different from the address of the access validation routine, CA ACF2 assigns reason code 12 to the corresponding z/OS service.
This reason code indicates that a program product or locally developed interface removed or preempted the security functions the CA ACF2 validation routine provided. Although the operation of CA ACF2 is not necessarily affected, data center personnel should be aware of the objectives of all local programming that alters the operation of the security system.
When CA ACF2 is started, it locates all of its validation routines using standard system services such as the LOAD SVC. When multiple copies of a given CA ACF2 validation routine are present, the version selected is the one returned using the standard z/OS module search sequence. If at any time a search for the same CA ACF2 validation routine retrieves a different LPA-resident module, that is, a module at a different common storage location, CA ACF2 assigns reason code 16 to the corresponding CA ACF2 or z/OS service.
This reason code indicates that the data center attempted to dynamically install CA ACF2 maintenance using a dynamic LPA update facility such as that provided in various system modification libraries and in some program products. CA ACF2 does not permit maintenance to be introduced in this fashion. In general, CA ACF2 operation should not be affected.
CA ACF2 validation routines reside in PLPA, but the data center can place them into MLPA or FLPA. If an LPA-resident validation routine is found to reside in virtual storage not associated with LPA, CA ACF2 assigns reason code 20 to the corresponding CA ACF2 or z/OS service.
This reason code usually indicates that CA ACF2 was not properly installed. When CA ACF2 detects that its validation routines are not resident in LPA, it dynamically loads and activates them in an alternate common storage area. However, data center personnel should review the CA ACF2 installation job output to determine the validity of the CA ACF2 installation process.
In an unmodified z/OS system, the and z/OS services, for which CA ACF2 provides resource access validation routines, reside in LPA. This includes all combinations of the PLPA, MLPA, and FLPA subsets of LPA. If a z/OS service routine resides in a virtual storage area outside of the LPA boundaries, CA ACF2 assigns reason code 24 to the corresponding z/OS service.
This reason code indicates that a program product or locally developed interface replaced or modified the associated z/OS service before CA ACF2 was started. Although the operation of CA ACF2 is not necessarily affected, data center personnel should be aware of the objectives of all local programming that alters the operation of z/OS services.
| Copyright © 2009 CA. All rights reserved. | Tell Technical Publications how we can improve this information |