Auto-Discovery System - Hitachi ID Identity Manager
(1) Hitachi ID Identity Manager includes an auto-discovery engine, which typically extracts information about users and groups from target systems nightly.
- An auto-discovery engine extracts a full inventory of login IDs,
from each target system, nightly.
- The auto-discovery engine extracts a list of all available groups
from each target system, nightly.
- For groups that have been designated as "managed," the
auto-discovery engine also extracts full group membership
from the target systems.
- The auto-discovery engine automatically creates, updates and removes
user profiles in the internal Identity Manager database, based on
the appearance of user accounts on systems that are considered
authoritative sources of Identity Manager IDs.
- Information such as last-login-date is used to identify dormant
- Identity attributes configured as "managed" in Identity Manager are read from each target system, into the Identity Manager identity cache.
Auto-discovery is incremental on systems that support this -- such as Active Directory and most other LDAP directories. A full extract is produced on systems where incremental listing is not supported, and a delta is calculated on the Identity Manager server before being loaded into the Identity Manager database.
Building User Profiles
Identity Manager extracts a list of login IDs from each target system, nightly. This process is fail-safe; where user lists extracted from a target system fail to return sufficient data, they are discarded and the previously-harvested user list is retained.
Every user ID that appears in one or another of a set of systems designated as source of Identity Manager IDs, triggers automatic creation of a user profile in Identity Manager, if one did not already exist. Old Identity Manager users that no longer appear on any of the authoritative systems are automatically deactivated.
Login IDs on systems that are identified as having a consistent naming scheme are automatically attached to Identity Manager user profiles.
Login IDs on systems that are identified as using non-standard login IDs are stored in inventory, but may not be automatically attached to user profiles, unless there is some other, consistent and reliable attribute that can be used to match local login IDs to global user profiles.
A set of rules is used to decide whether any given user must enroll to complete their profile. Users may be invited to enroll in order to provide personal information, such as a mailing address, to set up security questions, to attach non-standard login IDs to their profiles or to register a biometric voice print sample.
Users who are flagged as in need of enrollment are notified -- either by e-mail or by automatically opening a web browser during their network login script. A deployment management facility is used to ensure that an individual user is not asked to register too frequently and that the number of users asked to register in any given nightly run is bounded. The former limit eliminates nuisance to users, while the latter reduces load on the mail delivery system and sets a maximum to the potential call volume that confused users might cause by calling the help desk.
To register, users either click on a URL in a registration-request e-mail or use a web browser window opened during their network login sequence. Users authenticate with a current network or directory login ID and password and are walked through the registration process (fill in the blanks) one screen at a time.
User profile data is stored by default in the Identity Manager database, which is replicated among Identity Manager servers. The schema for this database is well documented and available to Hitachi ID Systems customers.
User profile data can also be reflected into an external directory -- most often an LDAP directory, where other applications can consume it.
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 on Target Systems
Identity Manager can detect all administrative changes made to users and entitlements on target systems as a normal part of the nightly 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.