Hitachi ID Identity Manager includes an auto-discovery engine, used to extract a list of accounts, groups, group memberships and more from every integrated system. The discovery process is scheduled to run regularly -- usually every 24 hours.
- Every Identity Manager connector supports list operations.
- By default, auto-discovery is scheduled to run every night. Some organizations choose to schedule it more frequently.
- When connecting to each managed system, an inventory of all login IDs (accounts) and all available security groups or roles is normally extracted.
- On systems that support this, incremental listing is used to reduce runtime -- i.e., list only IDs that have been added, changed or moved since the last list.
- The membership in those security groups or application roles which have been marked as 'Managed' in Identity Manager is extracted.
- Connections to target systems are made in a massively multi-threaded fashion, to minimize runtime.
The list operation in all Identity Manager connectors writes list files to the filesystem of the relevant Identity Manager server. Once list files are generated, a separate process determines what changed in each list file and loads appropriate updates into the Identity Manager database. This includes:
- Updating group, account, group membership, attribute and related data in the database, to reflect current state on target systems.
- Creating new or disabling existing Identity Manager user profiles, where new accounts were discovered on systems marked as 'source of profile' or existing profile accounts were disabled or disappeared.
- Triggering automated processes, such as provisioning network access in response to newly discovered HR records.
- Detecting out of band administrative changes, such as placing a user into an Administrators group and responding with e-mail alerts, workflow requests to undo or approve the change, etc.
The entire process can take from a few minutes (in smaller deployments) to 2--3 hours to run (in enterprises with tens of thousands of users and hundreds of integrated systems).
User objects that are not intended to be managed by Identity Manager can be excluded from the auto-discovery process. This is useful to exclude administrator IDs, machine IDs, service accounts, test users and user profiles for out-of-scope human users. Several methods are available to exclude such users:
- By identifying them individually:
Identity Manager administrators can add users IDs to a table which enumerates users who, should they appear on target systems, should not be included in Identity Manager.
- Using exclude and include files:
Identity Manager administrators can create files in the Identity Manager staging directory which either specify lists of users to include or exclude.
These files are treated as filters when processing lists of users extracted from each target system.
- Using group memberships and organizational units:
Identity Manager can be configured to integrate with target systems such as LDAP or Active Directory in a manner that specifies OUs or groups to include. This allows Identity Manager to be used to manage users in one part of a directory and not another.
- Using scripts:
Identity Manager administrators can write short scripts to post-process lists of users extracted from target systems, for example to exclude users based on string pattern matching (regular expressions).
Detecting Unauthorized Changes
Identity Manager can detect all administrative changes made to users and entitlements on target systems as a normal part of the auto-discovery process. This includes new users, terminated users, attribute changes and group membership changes.
Normally such changes are simply loaded into the Identity Manager identity cache, so that the various Identity Manager processes can act on correct current state data.
Such changes can also be fed into alarm systems (such as e-mail or SMS), can be reported on and can be fed as input to the auto-provisioning component of Identity Manager.
The auto-provisioning module (ID-Track) applies business logic to decide what to do about detected changes -- (disable unauthorized new accounts, revoke group membership changes and so on). Changes are submitted to the workflow engine, where they may be automatically approved or require human authorization before being executed.
Automated removal of detected changes is not normally recommended,
however, as it is difficult to predict a-priori what kinds of changes
might be legitimately required by systems administrators. It is
normally safer to report on changes than to blindly revoke them.
Human beings can then decide whether to retain or back out changes
made outside of Identity Manager.