Digital learning: from DVDs to artificial intelligence

After the initial configuration of a service, we can invoke a reconciliation for that service. Reconciliation is the process of synchronizing user account information, along with its attributes, stored in Tivoli Identity Manager Server and account information stored on the remote system (resource). Reconciliation is required when accounts and supporting data can be changed on the managed resource so that Tivoli Identity Manager Server data is consistent and up-to-date with the remote resource. During the reconciliation process, Tivoli Identity Manager communicates with the adapter on the remote system, compares data, and takes appropriate action.

If there is a match between a user login ID and an account, Tivoli Identity Manager creates the ownership relationship between the account and the person. If there is no match, Tivoli Identity Manager marks the unmatched account as an orphan account.

There are two types of reconciliation processes:

򐂰 Load access information into the Tivoli Identity Manager

When a service is first brought into Tivoli Identity Manager for management of the managed resource’s accounts, there needs to be an initial load of the accounts and accompanying data associated with the service. This is performed by an initial reconciliation.

Chapter 4. Implementation 111

򐂰 Monitor accesses granted outside of Tivoli Identity Manager administration Periodically, reconciliations need to be run to monitor the state of accounts and note if they have changed and no longer meet the policies defined within Tivoli Identity Manager. Accounts that are not owned by people (orphan accounts) are also monitored through these means.

Let us now take a closer look at the reconciliation process. If an entry for a managed account already exists within Tivoli Identity Manager, reconciliation simply updates the account’s details within Tivoli Identity Manager, if necessary, or performs the corrections in the actual account on the managed endpoint. The decision about what needs to be done is made based on the Tivoli Identity Manager provisioning policy and the service definition.

For example, if a person’s Microsoft Windows account has been modified since the last reconciliation by a source external to Tivoli Identity Manager and if that account has been made a member of a group called HR, the account record within the Tivoli Identity Manager directory can then be updated in the account record within the Tivoli Identity Manager directory accordingly. If the relevant policy states, however, that the person should not be a member of any groups within Windows, Tivoli Identity Manager will either mark the account as

non-compliant, suspend the person’s Windows account, alert the relevant person that the account is non-compliant and route an activity to their to-do list, or correct the Windows account to no longer be a member of the HR group within Windows.

An account created outside of Tivoli Identity Manager, for example, a local UNIX root administrator creates a new ID with root access rights, might not be

acceptable according to defined provisioning policies. Enabling policy checking during reconciliation enables you to identify areas in your organization that are not compliant with security policies and to take appropriate actions defined through policy enforcement.

Reconciliation is defined per service and can be scheduled, or initiated a immediately. Reconciliations are resource-intensive operations that require a lot of server memory (Java Virtual Machine, JVM™ memory) and can take a while for services with a large account population. Because any change to the account will trigger the policy evaluation for that account regardless if the change would invalidate the policy, you should consider limiting the number of attributes returned by the adapter and processed by Tivoli Identity Manager for performance reason. To help with that, LDAP filters can be setup on some adapters when configuring the reconciliation.

To optimize reconciliation, you can also separate reconciliation of accounts from the supporting data reconciliation. Supporting data includes group configuration information, which contains key information about access privileges on the

resource. Bringing back the group data ahead of time allows policies to be configured promptly before accounts are reconciled, so that the policies can be enforced.

Large reconciliations can also exceed the default Max Duration and if so, the value can be increased.

Adoption policy

The reconciliation process can generate what is known as orphan accounts.

These are accounts to which Tivoli Identity Manager cannot assign owners.

An adoption policy is used during reconciliation to determine the owner of an account by using adoption rules. An adoption policy can be created either globally, per service type, or per service to specify how to adopt orphan accounts during a reconciliation. Service instances of different types cannot be defined in the same adoption policy. An adoption policy does not alter the ownership for accounts that already have an owner assigned within Tivoli Identity Manager.

Adoption policies are defined through the use of JavaScript. By default, a global script is supplied that adopts accounts by preferred user ID attribute of the person (uid LDAP attribute). This approach differs from the default policy in Tivoli Identity Manager 4.6. The comparison there was against aliases (eraliases LDAP attribute).

You need to reconcile your data on a scheduled basis for your organization’s ongoing security audits.

The action to be triggered during policy enforcement is configured on the Service Policy Enforcement page. This page is accessible through the Policy

Enforcement link in the Service menu.

If the Check Policy during Reconciliation check box is selected for your reconciliation process, the system takes different actions on accounts depending on what provisioning policy actions are specified in the Service configuration:

򐂰 Correct non-compliance: Correct the non-compliances for the account.

Looking back at our previous example, this would result in the account being removed from the “HR” group within Windows.

򐂰 Suspend non-compliance: Suspend the account.

򐂰 Mark non-compliance: Mark (flag) the account as non-compliant in Tivoli Identity Manager.

Note: All services except the DSML identity feed services have policy enforcement available.

Chapter 4. Implementation 113

򐂰 Alert: Same as mark with the addition of sending a compliance alert to a desired participant (e-mail, to-do item, or both).

򐂰 Global Setting: Use the global Policy Enforcement Action setting. This enables you to specify the actual enforcement action (and associated customizing) in one place and have the services use whatever is specified there.