When user profile objects (*USRPRF) are identified by a data group object entry which specifies *ALL or *USRPRF for the Object type parameter, MIMIX replicates the objects using system journal replication processes.
User profile status. For the user profiles to be replicated, decide how their status will be set on the target system. The replicated profiles can always use their status from the source system, always be enabled, always be disabled, or be enabled for new profiles on the target system and remain as is when existing profiles change. The value for user profile status can be specified for the data group or overridden in individual data group object entries. Also, depending on your choice, you may need to change the configuration values following a switch so that users can sign on to the new production system.
User profile passwords. The user profile password rules defined in system values which begin with the characters QPWD are enforced on each system. Ideally, these system values should be set to the same values on each system. If the values are more restrictive on the target system than on the source system, replication failures can occur for user profiles with replicated passwords.
Private authorities of associated message queue objects. When MIMIX replicates user profiles, the message queue (*MSGQ) objects associated with the *USRPRF objects may also be created automatically on the target system as a result of replication. If the *MSGQ objects are not also configured for replication, the private authorities for the *MSGQ objects may not be the same between the source and target systems. If it is necessary for the private authorities for the *MSGQ objects be identical between the source and target systems, it is recommended that *MSGQ objects associated with *USRPRF objects be configured for replication.
For example, Table 15 shows the data group object entries required to replicate user profiles beginning with the letter A and maintain identical private authorities on associated message queues. In this example, the user profile ABC and its associated message queue are excluded from replication.
|
Entry |
Source Library |
Object Type |
Object Name |
Process Type |
|---|---|---|---|---|
|
1 |
QSYS |
*USRPRF |
A* |
*INCLD |
|
2 |
QUSRSYS |
*MSGQ |
A* |
*INCLD |
|
3 |
QSYS |
*USRPRF |
ABC |
*EXCLD |
|
4 |
QUSRSYS |
*MSGQ |
ABC |
*EXCLD |
Last used date attribute. MIMIX supports replication of the Last used date attribute of user profile (*USRPRF) objects. This capability is not enabled by default. Configuring replication of the last used date attribute can be specified for a data group or overridden in individual data group object entries.
When replication of the Last used date is configured, the MXCHKUSRP job periodically checks for a change to the Last used date attribute of user profiles on the source node that are configured for replication. The check is performed at least once per day and when the object send (OBJSND) process is started. The job checks for values of today’s date and yesterday’s date, and when a date match is found, it generates a U-MX journal entry of subtype US in the system journal. When MIMIX processes the journal entry on the target node, if the last used date of the source node user profile is more recent than the last used date of the target node user profile, the target object’s last used date is changed to the target node’s current date. (This is the only change allowed by the operating system.)
Notes:
-
Replicating this attribute can reduce problems with other tools, such as Enforcive or the Analyze Profile Activity (ANZPRFACT) command within IBM’s security tools, that disable or delete user profiles based on this attribute.
-
Replicating the Last Used Date is not recommended if you use programs that specifically check the Last Used Date attribute to determine whether a user profile has actually been accessed on the target node.
-
When configured, there is a window of time during which customer tools may not identify the same list of user profiles on the source and target nodes. This can occur between when the MXCHKUSRP job runs and when customer tools are run on the target node. This is due to how the operating system restricts changing the last used date attribute and whether the Last used date was changed on the target due to replication, an audit, or a synchronize request.
When replication of the Last used date is configured, results of requests to synchronize replicated user profile objects using the Synchronize Objects (SYNCOBJ) command are dependent whether a data group is specified on the command:
-
If a data group is specified, the request will synchronize the user profiles and will process the Last used date attribute so that when the last used date of the source node object is more recent than its date on the target node object, the target object’s last used date is changed to the target node’s current date.
-
If a data group is not specified, the request will synchronize the user profiles but it will not update the Last used date on the target node.
When replication of the Last used date is configured, auditing does not identify the attribute as different until there are at least two days difference between the source and target dates. The Libraries (#OBJATR) audit returns the following difference indicator values for the *LASTUSED attribute:
-
A value of *EQ is reported when the Last used dates are the same or when the target date is more recent than the source date.
-
A value of *EC is reported when source date is the day before the date the audit ran and is more recent than the target date.
-
A value of *NE is reported for all other differences, because the Last used date of the source is more recent than that of the target, but the source day is not the day before the date the audit ran. Audit recoveries will synchronize the user profile and use an IBM API to update the Last used date of the object on the target node to the current date on the target. This is the only possible update to the Last used date allowed by IBM APIs.
When replication of the Last used date is not configured, the Libraries (#OBJATR) audit returns the value *NS for the *LASTUSED attribute.
Delete pending distributions. You can configure a data group to automatically delete any pending distributions for user profile (*USRPRF) objects that are being deleted on the target system by replication processes. This capability is not enabled by default.
Default behavior is that when an object apply job processes an object activity for a transaction that deletes a user profile from the target system, any pending distributions attached to the profile are not deleted and the activity will fail. Manual intervention is required to remove the user profile and its pending distributions from the target system. When manually removing the user profile and its associated distributions, you must respond to the inquiry message CPA9001 (Distributions pending for User ID <usrprf> <system>). If you only retry or remove the failed activity entry without also removing the user profile and its pending distributions from the target system, audits will report and attempt to correct the object-only-on-target condition and the resulting new activity entry will also fail.
To avoid this manual error recovery, you can configure MIMIX to automatically delete associated pending distributions using the Delete pending distributions field on the Objects tab of dialogs to create or change resource group or data group configuration. When you specify Yes in this field, any pending distributions associated with user profiles being deleted from the target system by replication are also deleted.