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 entitled, Synchronizing RACF Data using IBM Tivoli Directory Integrator, we describe a method for synchronization of RACF user related information, including passwords and password phrases, between any combination of z/VM and z/OS operating system platforms. We provide a sample solution to show how RACF data can be propagated between RACF databases, with focus on synchronizing passwords and password phrases between z/OS and z/VM systems, using IBM Tivoli Directory Integrator. In addition to demonstrate that additional information can be synchronized we propagate changes made to the name field of the USER profile.
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:
- A user’s password, password phrase or USER profile is changed on one of the systems (source) that is part of the synchronization complex.
- ITDI through its changelog connectors polls the changelog and discovers a new changelog record.
- ITDI checks the changelog and determines through further processing that this user‘s password, password phrase or USER profile changes is to be synchronized to the other system or systems (target or targets). This occurs because: ITDI has been set up to listen to this system’s changelog and the changelog record indicates either a password change with *come and get it* or some change in the User profile.
- ITDI queries the source system’s RACF FACILITY class profile to determine which target systems the user is eligible to have its changed data propagated to. For a password or password change, ITDI requests the enveloped password. This is done through an LDAP SDBM bind by ITDI.
- RACF encrypts the user’s password or password phrase with the recipient’s public key (ITDI). The enveloped password or password phrase is returned to ITDI.
- ITDI checks if the userid exits on the target system(s). If the userid does not exist on a target system then no action is taken.
- For target systems where the userid exists, ITDI then updates the USER data, password or password phrase on the target system.
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 Redpaper, Synchronizing RACF Data using IBM Tivoli Directory Integrator. We provide detailed implementation steps and the sample ITDI configuration which you can modify and test for your own use.