Synchronizing RACF data using IBM Tivoli Directory Integrator
KaranITSO 120000AGEF Visits (2032)
Automated synchronization of Resource Access Control Facility (RACF) data between systems can reduce the amount of time administrators spend manually keeping data synchronized between RACF databases. The RACF remote sharing facility (RRSF) can be used to synchronize RACF data between z/OS RACF databases but not between z/OS and z/VM RACF databases. Furthermore, RRSF is not available on z/VM to allow synchronization between z/VM RACF databases.
In our just published draft IBM Redpaper enti
In broad terms, RACF through LDAP provides change notifications to ITDI which then executes tasks (known as assembly lines) to drive corresponding RACF changes via LDAP on the target systems to synchronize user information.The method employed on z/OS and z/VM exploit the RACF and LDAP (GDBM) event notification capability which creates user, group and connection change log records (notifications that a change has occurred), along with password and password phrase enveloping to enable extraction of encrypted password data by authorized LDAP clients.
ITDI extraction of user information and modification is achieved using the LDAP (SDBM) interface to RACF. Furthermore, we configure ITDI to use the RACF remote authorization and audit services, by enabling the IBM Tivoli Directory Server ICTX extended operations component, to perform authorization checks against RACF general resource profiles.
The following image shows, in a condensed and simplified form, the general logic of the solution:
As mentioned previously, we used IBM Tivoli Directory Integrator to retrieve and push the RACF data between systems. The logic encapsulating the solution and which is executed by ITDI is called a configuration (config). The configuration is composed of assembly lines, connectors, scripts and other logical resources.
The information that ITDI requires to start the synchronization process is gathered from two sources. Either as properties defined in the configuration or from entries in an LDAP directory tree. The LDAP directory entries contain entries that describe the systems involved in the synchronization scenario and data required by ITDI (such as connection data).
The following image shows the assembly lines that comprise the solution.
In our LDAP directory tree we have SC58 defined as a source system and VMLINUX5 and VMLINUX7 defined as target systems. As shown in the graphic, the startPutAndGetALs AL will parse the directory tree and create a putEntryToTarget AL for each system defined as a target system; in this example, ALs are created for VMLINUX5 and VMLINUX7.
The startPutAndGetALs AL will parse the directory tree and create a getEntryFromSource AL for each system defined as a source; in this example an AL is created for SC58.
The startPutAndGetALs AL will then terminate but all getEntryFromSource ALs and putEntryToTarget ALs will remain active.
The main purpose of the getEntryFromSouce AL is to read changelog records from the source system, determine if this is a change to be propagated, verify that the user is authorized to have this data propagated, and if the change is to be propagated this AL will push the change, as a message, to an MQSeries queue (one message for each system defined as target for this source system).
The purpose of putEntryToTarget AL is to read messages from an MQSeries queue and if the message header matches the system for which this AL was instantiated for, then it will process that message. This is the AL that will push the password, password phrase and USER data changes to a target system.
If this brief summary piques your interest you can find much more detailed information on the solution in the IBM Redp